Agentic AI Example
This example shows how the AI Control Architecture can be applied to an AI agent that can use tools and perform bounded workflow actions.
This is a filled example, not a blank template.
1. Use Case Summary
Use Case Name
IT Service Desk Ticket Triage Agent
Description
The enterprise is piloting an AI agent that reviews incoming IT service desk tickets, classifies issue type, suggests priority, retrieves relevant knowledge articles, drafts a response, and routes the ticket to the correct support queue.
The agent can read tickets, retrieve knowledge articles, recommend routing, and prepare draft updates. In the pilot phase, the agent cannot close tickets or send responses without human approval.
Business Purpose
Reduce manual triage effort, improve ticket routing consistency, and help service desk analysts respond faster to common IT support issues.
AI Pattern
[ ] Copilot
[x] Internal LLM application
[x] RAG system
[ ] AI-enabled SaaS
[ ] Embedded vendor AI
[x] Agent
[x] AI-enabled workflow automation
[ ] Customer-facing AI
[x] Employee-facing AI
[ ] Developer AI tool
[ ] Security operations AI
[x] Decision-supporting AI
[x] Action-capable AI
Lifecycle Status
Pilot design
2. Ownership
Business Owner
Name: Head of IT Service Management
Function: IT Operations
Responsibility: Owns service desk process, triage outcomes, analyst adoption, and business risk.
Technical Owner
Name: IT Automation Platform Owner
Function: IT Engineering
Responsibility: Owns agent configuration, workflow integration, tool permissions, logs, and technical remediation.
Data Owner
Name: ITSM Platform Owner
Function: IT Operations
Responsibility: Owns ticket data, knowledge base data, routing rules, and access permissions.
Security Owner
Name: Security Architecture Lead
Function: Cybersecurity
Responsibility: Reviews identity, delegated authority, tool/action controls, and incident containment.
Incident Contact
Name: IT Major Incident Manager
Function: IT Operations
Responsibility: Coordinates containment and recovery if the agent routes, updates, exposes, or escalates tickets incorrectly.
3. Initial Risk Tier
Assigned Tier
Tier 4: Action-capable AI
Tier Rationale
The agent can use tools and affect workflow routing by classifying and assigning tickets.
Although the pilot restricts the agent from closing tickets or sending final responses without human approval, the agent can influence operational queues and ticket handling.
Risk may increase to Tier 5 if the agent is allowed to perform privileged IT actions, modify access, close security incidents, change production systems, or operate without human approval.
Risk Drivers
[x] Internal enterprise data
[x] Employee support data
[x] Workflow routing
[x] Tool/action capability
[x] Agentic planning
[x] Decision support
[x] Operational impact
[ ] Customer-facing exposure
[ ] Financial action
[ ] Production system change
[ ] Privileged access change
4. Agent Scope
Approved Agent Goals
Classify incoming IT tickets
Suggest priority
Retrieve relevant knowledge articles
Suggest routing queue
Draft analyst response
Identify tickets requiring human escalation
Prohibited Agent Goals
Close tickets automatically
Send final employee communications without approval
Modify user access
Reset passwords
Disable accounts
Change production systems
Run scripts on endpoints
Approve exceptions
Override human analyst decisions
Autonomy Level
Level 3: AI can request or prepare actions, but approval is required before execution.
5. What Can AI See?
The agent can see:
Incoming IT tickets
Ticket metadata
Requester department
Issue category
Ticket history for current ticket
Approved IT knowledge base articles
Approved routing rules
Tool responses from ITSM platform
Analyst feedback on draft responses
The agent must not see:
HR case data
Legal privileged data
Security incident details outside approved queue
Privileged access credentials
Admin passwords
Secrets
Personal files
Unrelated employee records
Customer records
Production system credentials
6. Data Boundary
Approved Data Sources
Data Boundary Controls
[x] Approved source allowlist
[x] Restricted source denylist
[x] Ticket-level access limited to ITSM scope
[x] Knowledge base retrieval limited to approved articles
[x] No credential source access
[x] Tool responses treated as context, not authority
[ ] Data leakage testing completed
[ ] Retrieval boundary testing completed
7. What Can AI Decide?
The agent may recommend:
Ticket category
Ticket priority
Routing queue
Suggested response
Relevant knowledge article
Need for escalation
The agent must not make final decisions on:
Ticket closure
Access approval
Security severity
Disciplinary or HR matters
Production changes
Exception approvals
Major incident declaration
Decision Boundary
The agent may recommend routing and draft responses.
A human analyst remains accountable for approving ticket updates, final responses, closure, escalation, and any high-impact operational decision.
8. What Can AI Do?
Approved Capabilities
Read incoming ticket
Retrieve relevant knowledge article
Classify ticket
Recommend priority
Recommend queue
Draft response
Add internal draft note
Request human approval for routing
Not Approved
Close ticket
Send response to requester without approval
Change ticket owner without approval
Modify access
Reset password
Run script
Disable endpoint
Change production configuration
Trigger major incident workflow
Tool Inventory
9. Tool and Action Controls
Action Classification
Approval Gates
Routing update requires analyst approval.
Internal draft note requires analyst approval.
Any high-priority escalation requires analyst approval.
Ticket closure is disabled.
Access changes are disabled.
Production actions are disabled.
Blast-Radius Limits
Maximum tickets processed per hour: 50 during pilot
Maximum routing updates per hour: 10, approval required
Maximum queues in scope: 3 pilot queues
User group: IT service desk pilot team only
Systems in scope: ITSM and approved knowledge base only
10. Prompt and Input Controls
Allowed Inputs
IT support ticket text
Approved knowledge base articles
Approved routing rules
Analyst comments
Tool responses from approved ITSM tools
Prohibited Inputs
Passwords
API keys
Private keys
Access tokens
Security incident details outside scope
HR case information
Legal privileged content
Customer data
Production secrets
Prompt injection instructions
Prompt Injection Risk
High
Prompt Injection Controls
[x] Ticket text treated as untrusted user input
[x] Knowledge base content treated as retrieved context
[x] Tool responses not treated as instructions
[x] Agent cannot execute actions directly from ticket text
[x] High-risk actions require approval
[ ] Prompt injection test completed
[ ] Tool-use injection test completed
11. Output Controls
Output Types
Ticket category recommendation
Priority recommendation
Routing recommendation
Draft internal note
Draft requester response
Knowledge article citation
Escalation recommendation
Output Rules
Agent recommendations must be labeled as recommendations.
Draft responses must be reviewed by an analyst before sending.
The agent must show supporting knowledge article references where possible.
The agent must escalate when confidence is low, issue is ambiguous, or ticket appears security-sensitive, HR-sensitive, legal-sensitive, or access-related.
Output Risks
Incorrect routing
Incorrect priority
Unsafe draft response
Hallucinated knowledge reference
Ticket closure based on wrong assumption
Sensitive information included in draft
12. Human Accountability
Accountability Statement
The agent supports IT service desk triage but does not own the ticket outcome.
Human analysts remain accountable for final routing, response, escalation, and closure.
The business owner remains accountable for service desk process impact.
The technical owner remains accountable for agent configuration, tool permissions, and containment.
Human Review Model
Human-in-the-loop for routing changes and internal draft notes.
Human-in-the-loop for all requester communications.
Human-in-the-loop for all ticket closures.
Human-on-the-loop for read-only classification suggestions during pilot monitoring.
13. Monitoring and Evidence
Required Evidence
Inventory record
Risk assessment
Architecture decision record
Agent control record
Tool inventory
Action classification
Tool permission approval
Approval gate configuration
Pilot queue list
Prompt injection test results
Tool/action test results
Logging configuration
Kill switch test
Rollback or correction process
Incident containment plan
Required Logs
Agent identity
Initiating ticket
Ticket read event
Knowledge retrieval event
Recommendation generated
Tool requested
Approval requested
Approval decision
Routing update executed
Draft note added
Denied action attempt
Error or exception
Timestamp
Analyst reviewer
Evidence Requirement
The enterprise must be able to reconstruct for each pilot ticket:
What ticket the agent reviewed
What knowledge articles it retrieved
What recommendation it made
What action it requested
Who approved or rejected the action
What final routing or update occurred
14. Assurance Tests
Required Tests Before Pilot
[ ] Agent identity test
[ ] Ticket access boundary test
[ ] Knowledge retrieval boundary test
[ ] Prompt injection through ticket text test
[ ] Prompt injection through knowledge article test
[ ] Unauthorized tool call test
[ ] Approval gate test
[ ] Approval bypass test
[ ] Denied action logging test
[ ] Tool/action logging test
[ ] Kill switch test
[ ] Routing rollback/correction test
[ ] Evidence reconstruction test
Example Test Cases
15. Incident Containment
Potential Incident Scenarios
Agent routes tickets incorrectly
Agent writes incorrect internal note
Agent exposes sensitive ticket information
Agent follows prompt injection in ticket text
Agent attempts unauthorized tool call
Approval gate fails
Agent processes tickets outside pilot queue
Agent cannot be stopped
Logs are insufficient to reconstruct ticket action
Containment Actions
Suspend agent
Disable agent identity
Disable routing tool
Disable draft note writer
Stop pilot queue processing
Revert incorrect routing
Amend incorrect ticket notes
Preserve ticket and agent logs
Notify business owner
Notify security/privacy/legal where required
Retest before restart
Kill Switch
Kill switch level: Agent and tool access
Owner: IT Automation Platform Owner
Expected disablement time: Immediate to 30 minutes
Restart requires:
- root cause review
- control fix
- assurance retest
- business owner approval
- security approval if security control failed
16. Open Issues
17. Decision
Pilot Decision
Conditionally approved for limited pilot.
Conditions
1. Agent may operate only on approved pilot queues.
2. Agent may not close tickets.
3. Agent may not send requester responses without analyst approval.
4. Agent may not perform access changes.
5. Agent may not call production or endpoint tools.
6. Prompt injection and tool/action tests must be completed before pilot launch.
7. Kill switch must be tested before pilot launch.
8. Evidence reconstruction must be tested before production rollout.
18. Summary
Use case: IT Service Desk Ticket Triage Agent
Pattern: Agent / Internal LLM application / RAG / Workflow automation
Risk tier: Tier 4
Business owner: Head of IT Service Management
Technical owner: IT Automation Platform Owner
Data owner: ITSM Platform Owner
Autonomy level: Level 3
Data boundary: ITSM pilot tickets and approved knowledge base only
Decision impact: Ticket classification, priority, and routing recommendation
Tool/action capability: Read, retrieve, classify, draft, request routing
Key risks: Prompt injection, approval bypass, incorrect routing, unauthorized tool use, weak containment
Key controls: Agent identity, tool inventory, action classification, approval gates, blast-radius limits, logs, kill switch, evidence reconstruction
Pilot decision: Conditionally approved