Getting the CISO to yes
The five questions security will ask about an AI agent, the four proofs that answer them, and a rollout security can approve.
In shortSecurity reviews fail AI agents because agents act rather than answer, and the model can be persuaded by anything it reads. Bring the five questions security will ask, answer them with four demonstrable proofs (custody, agency, continuity, exit) instead of vendor assurances, and roll out through value gates, a sandbox, and one governed platform. A yes is a scope with proofs on file, not a blanket approval.
Most AI agent projects do not die in a demo. They die in a security review that was never designed for them, and the failure is symmetric: the review either rejects an agent that would have been fine, or approves one on criteria that do not cover what agents actually do.
The old review evaluates software that answers questions. An agent acts. It reads records across systems, calls tools, and changes state in sequences nobody scripted, under an identity that is sometimes a person's, sometimes its own, and sometimes a service account nobody has looked at in a year. The OWASP Top 10 for Agentic Applications, published for 2026, catalogs what goes wrong: goal hijack through content the agent reads, tool misuse, over-privileged and long-lived credentials, poisoned memory, cascading failures across connected agents, and agents that drift outside policy while looking legitimate. Surveys this year put the share of organizations that have already seen an agent act outside its intended scope at four in five.
This kit is for the person who has to bring an agent to their CISO. It gives you the questions you will be asked, the evidence that answers each one, and a rollout pattern that lets security say yes to a scope rather than no to an idea.
Why the old checklist fails
A conventional application review asks about authentication, data classification, encryption, vulnerability management, and vendor attestations. All of that still applies to an agent, and none of it addresses the new part.
The new part is that the model is a persuadable component. It will follow instructions that arrive inside a document, an email, or a tool result, because from the model's point of view those are just more text. Better system prompts reduce the rate; they do not remove the class. Every serious treatment of agent security this year lands in the same place: treat the model as persuadable by design and put the real controls in the layer where a call either has permission or it does not.
That single fact reorganizes the review. The question is no longer "is the model safe" but "what can the system around the model be made to do, by anyone who can get text in front of it."
The five questions
Every serious security review of an agent comes down to five questions, whether or not they are phrased this way.
- Who is acting? A person, an agent on that person's behalf, or an agent on its own schedule, and under which identity. Agents should be governed as non-human identities with an owner, a scoped privilege set, and a lifecycle, not as a shared API key.
- What can it see? Which records, on whose permissions, and whether those permissions follow the source systems or get flattened into one broad grant on the way in. Flattening is the most common way an agent ends up seeing more than the person operating it could.
- What keeps it in scope? What stops the agent from doing the one thing nobody wanted, even when the model has been persuaded to try it. If the answer is "the prompt," the answer is no.
- What happens when risk escalates? Who approves an irreversible step, how the agent is stopped, and what state it leaves behind when it is stopped mid-task.
- Can we trace it afterward? Whether every action, input, model call, and record touched is written to an append-only log an auditor can replay, in a form your own tools can query rather than a vendor dashboard.
Bring answers to these five and the review is a conversation. Bring a vendor's security page and it is a veto.
The four proofs that answer them
Our research team's sovereign AI playbook proposes four tests an institution runs before an AI service goes to production, and reruns after material changes. They map onto the five questions, and their advantage is that they are demonstrations rather than assurances. A certification says a control exists somewhere in a vendor's environment. A proof shows it operating on your workflow.
| Security question | Proof | What you demonstrate |
|---|---|---|
| Who is acting; what can it see | Custody | Trace every copy of the information: prompts, retrievals, outputs, logs, safety signals, support access, subprocessors. Confirm the agent's permissions equal the operator's. Exercise deletion and revocation. |
| What keeps it in scope | Agency | Attempt unauthorized retrieval and action, including through injected content. Show the system blocks it even when the model attempts it. Record both the blocks and the legitimate tasks that still succeed. |
| What happens when risk escalates | Continuity | Exercise approval, revocation, and the kill switch mid-task. Remove a critical dependency and recover an accepted service within the agreed interval. |
| Can we trace it afterward | Exit | Restore the workflow in a second environment from the exported context and audit trail, with behavior and permissions intact. |
The review kit
Walk into the review with these six items. Each is a page or a diagram, not a deck, and each answers a question above with something the reviewer can check.
1. The charter. One consequential workflow, written down: what the agent may read, what it may do, what quality the business accepts, what happens when it fails, and who owns each of those answers. Security reviews a charter far faster than it reviews a platform, and it is the document the four proofs are run against.
2. Identity and access. How people and agents are provisioned and removed, which identity an agent acts under, how long its credentials live, and how access follows the source systems. On Fig this is single sign-on over SAML or OIDC, SCIM provisioning and deprovisioning, scoped roles, and connectors that inherit the permissions of the account that connected them, so the agent cannot see what the person could not.
3. The data path. A diagram of every place information goes: retrieval, model calls, tool calls, logs, monitoring, and support. For each hop, its location, purpose, retention, deletion, and who can see an exception. Where a model provider is on the path, the contract terms that govern retention and training, and the configuration that is actually running today, which is not always the one in the sales deck. Ask four questions of each provider: is content stored, can it be used for training, what safety signals are retained, and who can inspect an exception.
4. The action boundary. Which actions are read-only, which require approval, and which are prohibited outright. Approval bound to the exact operation, not to the session. Credentials scoped to the task. Outbound destinations limited. Tools granted per operation rather than as a blanket, which the current MCP specification supports through incremental consent and which you should require of any tool server in the path. On Fig, consequential actions go through approval gates before they execute, and the approver sees the operation, the records affected, and the expected side effects.
5. The audit trail. What is recorded per action and how it is exported: actor, input, model and version, records touched, tools called, approver, result, and timestamp, in an append-only form you can query with your own tools. Command Center holds this on Fig, and it exports. Retention should match the workflow's regulatory horizon, which for anything touching financial reporting means years, not weeks.
6. The results of the four proofs, run on synthetic or approved test data, with the failures listed and what was changed as a result. A review that sees failures that were fixed trusts the process more than a review that sees none.
A rollout security can approve
Three habits turn a one-time approval into a repeatable one. They are not original to us; they are what the organizations getting agents through review consistently do.
Gate on value first. Only workflows that have cleared a business case reach security review. That keeps the queue short and makes each review serious, because the workflow in front of security is one the business has already decided it wants.
Sandbox before production. Agents prove themselves on test data and read-only access before they touch production records, then earn write access one action class at a time. The four proofs run at each widening.
Pave one road. Give teams a single governed platform to build on, with identity, permissions, the action boundary, and the audit trail already in place, rather than reviewing every experiment from scratch. Security then reviews the road once and each workflow briefly. This is the single biggest determinant of whether the second agent takes a week or a quarter.
What a yes looks like
A yes is not blanket approval. It is a scope: this workflow, these records, these action classes, under this identity, with these proofs on file and a date to rerun them. Widening the scope means rerunning the proofs on the wider scope.
That is more work than a signature. It is also the reason security stops being the place agent projects go to die, because the answer to "can we do this" becomes "show me the four proofs" instead of "no."
Key takeaways
- The model is persuadable by design; the controls that count live in the layer where a call either has permission or it does not.
- Five questions decide the review: who is acting, what it can see, what keeps it in scope, what happens when risk escalates, and whether it can be traced.
- Four proofs answer them with demonstrations: custody, agency, continuity, exit. Run them on the workflow, not the vendor.
- Approve a scope, not a platform. Widening the scope reruns the proofs, which is why the second agent takes a week instead of a quarter.
Download the sovereign AI playbook for the full operating test, or talk to us about running the four proofs on your first workflow.
Sources: OWASP Top 10 for Agentic Applications, 2026; Model Context Protocol specification, 2026 revision; Fig Research, Sovereign AI: the operating playbook, September 2026.
