The review is a different exam than the one you studied for
A team builds an agent, demos it, gets a budget, and books thirty days for the security review. The review takes four months, or it ends in a no. The postmortem usually blames the reviewers for not understanding AI. That is almost never what happened. What happened is that the team optimized for capability and the reviewer is grading containment, and those are different exams. The reviewer is not asking whether the agent is smart. They are asking what it can reach, whose authority it uses to reach it, what happens when a document it reads tells it to do something else, and whether anyone can reconstruct a specific action six months from now during a customer audit.
Those questions have architectural answers. They do not have policy answers. A team that arrives with a written acceptable-use policy and a system prompt that says "never delete anything" is handing the reviewer a promise, and the reviewer's job is to not accept promises. A team that arrives with a permission layer where the delete capability is not issued to the agent's credential at all has handed over a fact. The difference between those two postures is roughly the difference between a four-month review and a three-week one, and it is decided months earlier, in code.
You are probably here because
- A working agent has been sitting in security review long enough that the sponsor has stopped asking
- The reviewer asked what the agent can access and the honest answer was "everything the service account can"
- A customer sent a vendor questionnaire with an AI section and nobody owns the answers
- Legal wants to know what happens if the agent acts on text a third party put in a document
These are four faces of one gap: the system's guarantees live in prose rather than in the identity and permission layers, so nothing about it can be verified without trusting the builder.
Question one: whose identity is it using?
This is the first question and it disqualifies more agent projects than the other four combined. Most agents are built with a service account, because a service account is what makes the prototype work on a Friday afternoon. It has broad read access, it never expires, and it does not prompt anyone for consent. It is also the single fact that will end the review.
The reason is not bureaucratic. If the agent reads a ticket, a wiki page, a PDF or an email using a credential that can see all of them, then the union of everything the agent can reach is now reachable through a text box, by whoever can get text in front of it. Every access control the company spent a decade building has been routed around by one integration. A reviewer sees that in about ninety seconds.
The architecture that passes acts as the initiating user. The agent receives a delegated, short-lived token scoped to the person who asked, and every downstream call carries it. If Dana cannot open the finance folder, then the agent working on Dana's request cannot open it either, and the failure is a normal authorization error rather than an incident. This costs real engineering time. Token exchange, on-behalf-of flows, propagating principal through an async job queue, and handling the case where a long-running task outlives the token that started it are all genuine work. Budget two to five weeks for a system that has several downstream integrations, and treat it as the foundation rather than a hardening pass, because retrofitting it means touching every tool call in the system.
Question two: what is the blast radius, and who decided?
The second question is about capability, and the useful framing is not "what can the agent do" but "what can the agent do that cannot be undone." Reversible actions are cheap to approve. Reading, drafting, searching, generating a proposed change, writing to a scratch space that nobody else consumes. These can run freely and the review will spend almost no time on them.
Two structural choices make this section of the review short. The first is that the gated tier stays small. Approval fatigue is a measured phenomenon and a user who has clicked through nine confirmations is not reading the tenth, so a design that gates forty actions has effectively gated none. Gate the handful that matter and let the rest run. The second is that confirmations show the diff rather than the intent. "The agent would like to update customer records" is not a decision a person can make. "Update 1,247 records: set status from active to archived; undo available for 30 days" is.
Bounds belong in the same layer. A per-run ceiling on spend, on the number of write operations, on the count of external messages, enforced by the runtime rather than requested in the prompt. A reviewer who has seen agent incidents knows that the interesting failures are not one dramatic wrong action but the same small action taken four thousand times in nine minutes, and a numeric ceiling is the only control that stops it.
What stalls an enterprise agent security review — our observed ordering
Our ordering of what reviewers raise first, drawn from the agent architectures we have been asked to assess. An ordering of frequency, not a survey.
Question three: what happens when the input is hostile?
Prompt injection sits at the top of the OWASP Top 10 for LLM Applications for a reason, and an agent makes it materially worse than a chatbot does, because a chatbot that is fooled says something wrong and an agent that is fooled does something wrong. The mechanism is simple. An agent reads a support ticket, a webpage, a résumé, a vendor invoice, an internal wiki page edited by a contractor. Any of that text can contain instructions aimed at the agent rather than at the human reader.
Teams reliably answer this question the wrong way. The wrong answer is a paragraph in the system prompt telling the model to ignore instructions found in documents, plus a classifier that flags suspicious inputs. Both are worth having and neither is a control, because both are probabilistic and the reviewer is looking for something that holds when the model is wrong. Say the classifier catches 98 percent of attempts. At a thousand documents a day that is twenty successful injections a day against a system whose only remaining defense is the model's judgment.
The answer that survives is containment. Untrusted content enters through a channel structurally marked as data and never as instruction, and the agent's authority is scoped so that following a malicious instruction produces an authorization failure instead of an action. If the agent processing external email holds no send capability, no amount of persuasive text in an email causes it to send one. The guarantee lives in the token, not in the wording. MITRE ATLAS is the useful reference here because it catalogs the adversary techniques by name, and a review goes faster when your threat model uses the same vocabulary the reviewer reads in.
Three practices carry most of the weight. Separate the trust tiers so that content retrieved from outside the organization never occupies the same structural position as the operator's instructions. Re-check authorization at the tool boundary on every call rather than once at session start, because a long-running agent's context at step forty is not the context that was authorized at step one. And test it adversarially before the reviewer does. A red-team pass against your own agent, with the findings written down and the fixes shipped, changes the tenor of the entire review, because you have arrived with evidence rather than with confidence.
Question four: can you reconstruct what happened?
A reviewer will eventually ask a question shaped like this: on March 14, this agent updated a customer record. Show me why. If the answer is a chat transcript, the answer is insufficient. If the answer is "we log the requests," it is insufficient, because the request is not the decision.
What satisfies it is a per-step record written before the step executes, holding the model and snapshot version, the fully rendered prompt as sent, the tool called with its arguments, the response, the authorization principal, the decision on any gate, the token count, the latency and the timestamp. Store the rendered prompt rather than the template plus variables. Reconstruction from a template is close and not identical, and the difference is usually exactly where the bug is.
Question five: where does the data go, and under what terms?
Every prompt is an egress event. The reviewer wants a data flow diagram showing which categories of data reach which model provider, under which contract, with what retention and what training terms. This is a one-page artifact and its absence stalls reviews for weeks while someone hunts down a signed agreement.
The specifics that matter: the enterprise agreement rather than the consumer terms, an explicit no-training-on-inputs commitment, the retention window for prompts and completions on the provider side, the processing region if data residency is in play, and the subprocessor list. If regulated categories are involved, the analysis has to run at the category level. Protected health information, cardholder data, controlled unclassified information and personal data of European residents each carry their own regime, and "we send some customer data" is not an answer to any of them.
Two architectural decisions reduce the surface before the paperwork starts. Redact or tokenize at the boundary so that identifiers are replaced before the prompt is assembled and restored afterward, which shrinks what is in scope. And route by sensitivity, so that the most sensitive classes go to a model deployed inside your own tenant or network boundary while the rest use the general path. Both are ordinary engineering, and both convert a hard conversation into a diagram.
The frameworks the reviewer is actually reading from
Reviewers do not invent their questions. They inherit them from a small set of documents, and knowing which ones lets you write your materials in the reviewer's own vocabulary.
| Framework | What it governs | What it means for your build |
|---|---|---|
| NIST AI RMF | Voluntary risk framework: Govern, Map, Measure, Manage | The common structure for AI risk documentation. Mapping your design decisions to its subcategories makes your package legible on sight. |
| ISO/IEC 42001 | Certifiable AI management system standard | Increasingly named in enterprise vendor questionnaires. Your artifacts feed your customer's certification even when you hold none. |
| OWASP Top 10 for LLM Applications | Application-layer AI risks, injection first among them | The reviewer's checklist in practice. Answer it item by item and most of the security section writes itself. |
| MITRE ATLAS | Adversary tactics and techniques against AI systems | The vocabulary for your threat model. Naming techniques from it makes an adversarial testing claim checkable. |
| SR 11-7 | Federal Reserve guidance on model risk management | Governs at banks and insurers. Independent validation and ongoing monitoring are expected, not optional. |
| NIST SP 800-53 / 800-171 | Federal control catalogs for systems and for CUI on non-federal systems | If a government thread runs through the work, controls come from here. Access enforcement and audit are where agents meet them. |
| FedRAMP | Authorization program for cloud services sold to federal agencies | Constrains which model endpoints are usable on federal-facing work. Decide this before choosing a provider, not after. |
The design pattern that passes on the first attempt
The systems that clear review quickly share a shape. A gateway sits between the agent runtime and every downstream system, and it is the only path out. It holds the delegated user token, enforces the permission set, applies the numeric bounds, writes the trace record, and applies redaction on the way to the model. The agent runtime never talks to a database, an API or a mail server directly.
That single structural choice answers four of the five questions at one point in the code. Identity is enforced there. Blast radius is defined there as the list of capabilities the gateway will issue. The trace is written there, so it cannot be forgotten in a new tool. Data flow is inspectable there, because everything leaving the boundary passes through one function. A reviewer can read the gateway and know what the system can do, which is a different experience from reading forty tool implementations and hoping. Beside it sit a capability registry listing every tool with its reversibility class, required authorization and bound, and a kill switch that propagates, aborting in-flight model calls rather than flipping a status field while the bill accrues.
How far each control moves a review, relative to its build cost
Editorial ranking of review impact per unit of engineering effort. The last row is low not because classifiers are useless but because a probabilistic filter cannot be the control a reviewer relies on.
What this costs and how long it takes
Doing this from the start, on a system with three to six downstream integrations, adds roughly six to ten weeks of engineering across identity plumbing, the gateway, the trace store and the capability registry. On a typical blended commercial rate that lands somewhere between 120,000 and 250,000 dollars, and it buys a security review measured in weeks instead of quarters.
Retrofitting the same properties onto a shipped agent runs two to three times higher, because identity propagation is not a module you add but a parameter threaded through every tool signature, queue message and stored job. The number that usually decides the argument is neither figure. It is the cost of the delay. An agent that saves a 200-person operations team fifteen minutes a day is worth on the order of a million dollars a year, so a four-month review that could have been a five-week review is roughly a quarter of a million dollars of unrealized benefit, before counting the engineers holding a finished system in maintenance while they wait.
The packet that ends the review
Reviews also stall for a non-technical reason: the reviewer cannot find the answers even when they exist. A short, deliberate package fixes that, and it is a week of writing at most.
Six documents. An architecture description that names every trust boundary and the gateway. A data flow diagram at the level of data category, showing what reaches the model provider and under which agreement. The capability registry, printed, with reversibility class and bound per tool. A threat model in ATLAS vocabulary, with the injection scenarios worked and the containment named. The results of your own adversarial test pass, including what failed and what you changed. And an operations page naming the owner, the monitoring, the alert thresholds, the kill switch and the incident path.
Hand a reviewer that packet and the conversation changes character. They are no longer investigating a system built by people who did not think about them. They are checking work done by people who did. That shift is worth more than any single control on the list, and it is the reason a well-built agent clears in three weeks while an equally capable one sits for four months.
Bottom line
Security review is not a tax on agent projects. It is the exam that decides whether the thing you built gets used, and it grades containment rather than capability. Identity delegation, a single gateway, an enumerated capability registry with numeric bounds, per-step traces with the rendered prompt, and a data flow you can draw are the five answers. Build them first and they cost weeks. Add them later and they cost quarters, plus the value of every month the finished system spent waiting.
Frequently asked questions
Yes, for scheduled work with no human initiator. The requirement is that it is a purpose-built principal with a short enumerated permission set and its own audit stream, not a reuse of an existing broad integration account. If you cannot print its permissions on one page, it is the wrong principal.
Not as a detection problem. It is manageable as a containment problem. Assume some malicious instruction will be followed, and scope the agent's authority so that following it produces an authorization failure rather than an action. Filters reduce volume; permissions decide consequence.
Usually not. What buyers ask for is evidence that your system produces the artifacts their own program needs: documented risk decisions, data flow, monitoring and incident response. Mapping your design to NIST AI RMF and ISO 42001 structure gives them that without a certificate.
Long enough to cover your customers' audit windows, commonly one to two years for the metadata. Rendered prompts inherit the sensitivity of whatever the agent read, so they often warrant a shorter window and stricter access than the rest of the record. Make it an explicit decision rather than a default.
The five questions stay the same and the control catalog becomes specific. Access enforcement and audit requirements come from NIST SP 800-53, CUI handling from 800-171, and FedRAMP constrains which model endpoints are usable. Choosing the endpoint before the architecture is the mistake that costs the most to undo.