Build a Conversational Access Request & Approval Agent — a chat-based interface where employees and contractors can request network access (VLAN, VPN, guest Wi-Fi, or segmented network access) in natural language. The agent gathers required context conversationally, evaluates the request against policy, and either auto-approves low-risk requests or routes sensitive requests to a human approver. ## Interface Requirements Build a chat interface (Tines chatbot / conversational Page) as the primary entry point. It should: - Greet the requester and ask what kind of network access they need - Support natural language input (e.g., "I need VPN access to the finance network for the next two weeks" or "Can I get on the guest Wi-Fi for a vendor visiting tomorrow?") - Progressively gather any missing required fields rather than presenting a rigid form up front — this should feel like a conversation, not an interrogation - Confirm the full request back to the user in plain language before submitting ("Just to confirm: you're requesting VPN access to the Finance VLAN for yourself, starting today, for 14 days. Is that correct?") ## Required Context to Gather (via conversation, not a static form) - Requester identity (auto-pull from SSO session if available; otherwise ask and verify against Okta/Entra ID) - Requester type: employee or contractor - Access type requested: VLAN, VPN, guest Wi-Fi, or specific segment - Target network/segment name or description - Business justification (why they need it) - Device details: device type, OS, whether it's company-managed or BYOD, and MAC address/hostname if available - Role/department (pull from HRIS/Okta profile where possible instead of asking) - Location (office, remote, specific site) - Requested duration (start date/time and end date/time, or "ongoing" if standard for their role) ## Core Workflow Logic 1. **Session & Identity Handling** - Authenticate the requester via SSO where possible - If the requester is a contractor, verify they have an active contractor record and a designated employee sponsor on file (query HRIS/IAM); if no sponsor exists, prompt the agent to ask "who is your Tines employee sponsor?" and validate that person is active 2. **Policy Lookup & Risk Classification** - Query a policy reference (Tines Record, database, or config file) that maps network segments/access types to a risk tier: Low, Medium, High - Low: e.g., guest Wi-Fi, general VPN with no internal segment access - Medium: e.g., department-specific VLAN, standard VPN to internal but non-sensitive systems - High: e.g., finance/HR/engineering production segments, anything touching regulated data, or contractor requests for any internal segment - Cross-check requester's role/department against the requested segment for a mismatch flag (e.g., a marketing employee requesting access to the engineering production VLAN should be flagged even if that segment is normally "Medium" risk) - Check requested duration against policy max for the given risk tier; flag if it exceeds the max (e.g., Medium max = 30 days, High max = 7 days without additional sign-off) 3. **Decision Routing** - **Low risk + no flags** → Auto-approve immediately - Provision access directly via NAC/IPAM platform API (e.g., Cisco ISE, Aruba ClearPass, Infoblox) - Confirm to the requester in chat with access details and expiration - **Medium risk, no flags** → Auto-approve but notify the requester's manager asynchronously (visibility, not blocking) - **Medium risk with flags, or any High risk** → Pause and route to a human approver: - Determine the correct approver (requester's manager for role mismatches; network security team for High-risk segments; sponsor for contractor requests) - Send an approval request via Slack or email with full context: requester, justification, segment, duration, device info, and the specific risk flag(s) raised - Support approve/deny actions directly from Slack/email without needing to open another tool - If denied, notify the requester in the chat interface with the reason (if provided) and next steps (e.g., "contact your manager for an exception") - If not actioned within a defined SLA (e.g., 4 business hours), escalate to a backup approver or the network security team lead 4. **Provisioning** - On approval (auto or human), call the appropriate NAC/IPAM API to: - Assign the device/user to the correct VLAN/segment/VPN group - Generate any required credentials, certificates, or registration codes - Set an explicit expiration timestamp based on requested/approved duration - Log the full record: requester, approver (or "auto-approved" + policy rule matched), segment granted, device, duration, risk tier, and timestamp 5. **Expiration & Cleanup** - Run a scheduled check (e.g., hourly) for any access grants past their expiration timestamp - Automatically revoke expired access via the NAC/IPAM API - Notify the requester in advance (24 hours before expiration) with the option to request an extension through the same chat interface — this re-triggers policy/risk evaluation rather than blindly renewing 6. **Conversational Edge Cases** - If the requester asks a status question ("what's the status of my VPN request?"), the agent should look up the record and respond conversationally - If the requester's input is ambiguous or missing required detail, the agent should ask a clarifying follow-up rather than failing or guessing - If the requester asks for something outside policy entirely (e.g., permanent unrestricted access), the agent should explain policy limits and offer the closest compliant alternative ## Data & Audit Requirements - Every request, decision (auto or human), and provisioning/revocation action must be logged to a queryable record store with full audit trail: who requested, what was requested, risk tier assigned, who approved (or which policy rule auto-approved), what was granted, and when it was revoked - This log must support compliance reporting and be searchable by requester, approver, segment, or time range ## Integrations Needed (adjust based on actual stack) - Identity: Okta or Entra ID (SSO, role/department lookup, contractor sponsor validation) - NAC/Network: Cisco ISE, Aruba ClearPass, Forescout, or Infoblox IPAM - Notification/Approval: Slack and/or email with interactive approve/deny actions - Policy reference: Tines Record or connected database mapping segments to risk tiers and duration limits ## Success Criteria - Requesters can get access through natural conversation without needing to know exact segment names or fill out rigid forms - Low-risk requests are resolved in seconds with no human bottleneck - Sensitive/high-risk requests always have a human-in-the-loop checkpoint with full context provided to the approver - No access persists past its approved expiration - Full audit trail exists for every decision, whether made by policy logic or a human approver