Bring them in at design, not at the end, and answer their questions before they ask. Security wants to know what the agent can reach, under whose identity, what happens when content tries to manipulate it, where data goes, and how to stop it. A short pack with a threat model, access design and injection tests usually decides it.
Why do agent approvals stall with security?
Because security is asked to approve something that behaves unlike other software. A normal application does what its code says. An agent decides what to do based on what it reads, and what it reads can include text written by an attacker. Security teams know this, and an approval request that does not address it will be sent back.
The other common cause is timing. If security first sees the agent a week before go-live, with credentials already wired and data already flowing, every finding becomes a delay.
What will security ask, and what answers them?
| Concern | Control | Evidence |
|---|---|---|
| What can the agent reach? | Narrow tools, one per task; read and write separated | Tool list with access per tool |
| Under whose identity? | The agent's own identity, brokered short-lived credentials | Identity design; secrets handling |
| Prompt injection from emails, documents, web pages | Content treated as data; actions checked outside the model; external facts cannot authorise payments | Injection test results |
| Excessive agency | Certified depth and the depth each action needs; limits enforced at the moment of action | Role description; enforcement design |
| Data leaving the environment | Data flow map; what reaches the model provider and under what terms | Data flow diagram; contract terms |
| Sensitive data in outputs | Output checks; minimum data access | Test results on disclosure cases |
| Logging and forensics | Append-only record of every action and verdict | Sample records |
| Third-party risk | Vendor assessment; attestation reports such as SOC 2 or ISO/IEC 27001 certification | Due diligence file |
| Incident response | Stop switch; runbook; contacts | Runbook and a tested stop |
Prompt injection and excessive agency both appear in the OWASP Top 10 for LLM Applications. Using that list as the frame for your threat model tells security you are speaking their language.
What are the steps, and who does each?
- Process owner: invite security at design. Share the job description and intended systems. Evidence: the meeting note and security's initial questions.
- Technology lead and security: threat model together. Walk through what an attacker could feed the agent and what it could then do. Evidence: the threat model.
- Technology lead: write the access design. Identity, tools, read and write split, credential handling. Evidence: the design, reviewed by security.
- Security or a tester: run injection tests. Feed the agent hostile content through every channel it reads. Evidence: test cases and results.
- Third-party risk: assess the vendor. Evidence: the due diligence file.
- Operations: write and test the incident runbook, including stopping the agent. Evidence: runbook and test record.
- Security: approve, with conditions if needed. Evidence: the approval and any conditions with dates.
Security's approval is one input to the overall production decision; see how to approve a new AI agent for production.
What does this look like in practice?
Take an insurer's security team reviewing an agent that reads incoming broker emails and creates draft quotes. Their first concern: a broker email could contain hidden instructions.
The project team shows three things. The agent has no tool to send email or change records; it can only create drafts in a queue. Every fact from an email is marked external, and external facts cannot authorise anything. And injection tests, with instructions hidden in email bodies, attachments and file names, all ended with the agent creating ordinary drafts or flagging the email as suspicious.
Security asks for one more control: drafts created from emails with unusual attachments should be flagged for the underwriter. That becomes a condition, added before go-live.
Which controls matter most to security?
- Controls outside the model, so manipulation of the model cannot widen what it does.
- The agent's own identity, never a person's.
- Narrow tools, no general-purpose access.
- A full record for investigation.
- A tested stop switch.
Risk and compliance will have their own questions; see getting risk and compliance to approve an AI agent. Both approvals sit inside the sequence in deploying an AI agent: train, shadow, certify, widen.
Questions people ask
Should security own the agent?
No. Security approves the design and controls; the process owner owns the agent's decisions.
Does every agent need a full security review?
New patterns do. Agents reusing an approved pattern, same tools, same identity design, can go through a lighter review.
What if security says no?
Ask for the specific concern and the control that would answer it. A refusal with reasons usually turns into conditions.