AI Agent Security: The Threat Model and Controls a CISO Should Require

Every agent rollout reaches the CISO eventually, and the CISO can stop it there. Security reviews were built for software whose behavior is fixed at release. An agent's behavior is decided at run time by a model that reads whatever lands in front of it, and the agent acts with delegated authority. This guide sets out the threat model, the control for each threat and the evidence to see before signing.

• 13%of the 600 organizations in IBM's 2025 Cost of a Data Breach study reported a breach of an AI model or application²
• 97%of those breached organizations lacked proper AI access controls²
• 9.3the vendor's CVSS score for a 2025 flaw that let an attacker pull data out of an enterprise AI assistant³

What changes when software holds delegated authority

An AI agent changes the threat model because it joins three things security teams have always kept apart: authority to act, a decision-maker that can be persuaded by what it reads, and live connections to systems of record. OWASP puts the root problem plainly: agents cannot reliably tell instructions apart from the content they process.¹ The UK National Cyber Security Centre (NCSC) warns that prompt injection may never be fully mitigated the way SQL injection can be, because a model draws no inherent line between data and instruction.⁴

So the attacker model changes. Misusing a conventional application takes a code flaw or a stolen credential; misusing an agent takes only text in front of it, such as an email to a monitored inbox, a ticket comment, a shared document, a web page or a tool description. The agent does the rest with its own permissions, chaining actions with no person in between. OWASP treats a rogue agent as an insider threat amplified by speed and scale, and recommends adding agents to the insider threat program.¹

An agent's attack surface is, roughly, everything it reads multiplied by everything it can do, and review is the work of shrinking both. Sometimes that means a smaller design: OWASP's principle of least agency says to give a workflow no autonomy it does not need, since agentic behavior where none is required widens the attack surface and adds no value.¹ Tasks that follow fixed rules are easier to secure as deterministic integrations.

The OWASP Top 10 for Agentic Applications, mapped to controls

The OWASP GenAI Security Project published its Top 10 for Agentic Applications on December 9, 2025. It is the reference list of agent threats, and each entry maps to a control a CISO can ask to see working.¹ It extends the OWASP LLM Top 10 into multi-step, tool-using systems: goal hijack is the agentic form of prompt injection (LLM01), and privilege abuse the agentic form of excessive agency (LLM06).¹

Use the table as a worksheet for each agent: every risk gets a control, an owner and evidence, or a written reason it does not apply. An agent with no memory and no peers can exclude ASI06 and ASI07. No agent can exclude ASI01, because every agent reads something.

Give every agent its own identity and short-lived credentials

Every agent should run under its own non-human identity, with credentials that expire in minutes, cover one task and name the person it acts for. OWASP traces privilege abuse to identity systems built for people: an agent without a governed identity sits in an attribution gap where least privilege cannot be enforced.¹

The standard mechanism is OAuth 2.0 Token Exchange (RFC 8693, January 2020), which distinguishes impersonation, where the agent becomes indistinguishable from the user, from delegation, where it keeps its own identity and acts on the user's behalf. Nested actor claims record each step of a delegation chain, so a trace shows the user, the orchestrating agent and the sub-agent behind every call.⁵ MCP adds audience binding: clients name the target server when requesting a token, and servers refuse tokens issued for anyone else.⁶

OWASP's guidance adds three rules.¹ Recheck authority when each privileged action executes, since a user's rights can shrink during a long workflow. Never let an agent cache credentials in memory, where a later session can prompt it to reuse them. Keep signing keys away from the agent entirely, with an orchestrator signing on its behalf.

Treat prompt injection as an architecture problem

Prompt injection is managed by design: assume the agent will sometimes follow an attacker's instructions, and make sure doing so achieves nothing of value. The NCSC recommends deterministic safeguards outside the model that constrain what the system can do.⁴

OWASP cites a case in which one crafted email made an enterprise AI assistant send confidential emails, files and chat logs to an attacker, with no action by the user.¹ The flaw, CVE-2025-32711, was published in June 2025; the vendor scored it 9.3 (critical) and the US National Vulnerability Database 7.5 (high).³ Four design rules carry most of the defense:

• Privileges follow the least trusted input. After reading content from a party, an agent holds no more authority than that party, as the NCSC advises.⁴ Having read an inbound email, it can draft a reply; it cannot export the customer table.
• Break the path out. Injection becomes a breach when the agent can send data somewhere. Allowlist outbound destinations, as OWASP's per-tool profiles do, and hold messages to new external recipients for approval.¹
• Keep raw text away from the planner. The component that reads external content returns typed fields, such as a date or an amount, to the component that chooses tools.
• Put a policy engine between plan and action. A deterministic check outside the model approves or refuses each high-impact call, so a corrupted plan cannot execute itself.¹

Injection classifiers catch known payloads and miss novel ones, so they belong in monitoring and never in the sign-off argument. Approval gates for irreversible steps, covered in our guardrails playbook, complete the defense.

Secure the tool and MCP supply chain

Every tool an agent can call, and every MCP server that exposes one, is third-party code with a direct line into the agent's decisions, so it needs the controls of a production dependency plus review of the text it feeds the model. OWASP calls this a live supply chain, since agents load tools and even peer agents at run time, and counts tool descriptions as attack surface because the agent reads them as trusted guidance.¹

Both failures have appeared in the wild. OWASP records the first reported malicious MCP server, published to a public package registry under the name of a legitimate email integration, which quietly copied the emails it sent to the attacker.¹ Separately, an open-source MCP client component could be made to run operating system commands on the user's machine just by connecting to a malicious server (CVE-2025-6514, scored 9.6, critical).⁷

For MCP servers and tools, require:

• A private registry of approved servers and tools, pinned by content hash, where a changed tool description is a new release.¹
• OAuth on every remote server, with tokens bound to that server and refused everywhere else.⁶
• Minimal scopes at first connection, step-up for privileged operations and no wildcard scopes.⁸
• Local servers started only after the exact command is shown and approved, inside a sandbox.⁸
• A bill of materials for each agent, and a kill switch that revokes one tool across every deployment.¹

Protect memory and context from poisoning

Memory poisoning is prompt injection that persists: an attacker plants content in what the agent stores or retrieves, and it shapes later sessions, including other users' sessions when stores are shared.¹ Treat the retrieval index as memory. If an agent draws on a wiki or ticket history that any employee or customer can edit, every one of those writers can place instructions in front of it. OWASP's controls amount to data governance for everything the agent can remember:¹

• Separate memory per user, per tenant and per domain.
• Record each entry's source, and weight retrieval by trust.
• Validate writes before they commit, and expire entries nobody has verified.
• Never write the agent's own outputs back into trusted memory, where one error becomes self-reinforcing.
• Keep versioned snapshots so a poisoned store can be rolled back.

Set trust boundaries between agents

Agents should give each other no more trust than an unknown external service gets: every request is authenticated, authorized against the original user's rights and checked against the task. OWASP's counterexample is a crafted email that leads a sorting agent to instruct a finance agent to pay an attacker, and the finance agent complies because the request came from an internal peer.¹

The A2A specification, now at version 1.0, requires servers to authenticate every request and scope results to the caller's authority, and it leaves the authorization model to each implementer.⁹ That model is where your policy lives. Carry the user's identity through the chain with nested actor claims,⁵ and never give a sub-agent the full rights of its caller. On the wire, require mutual authentication, signed messages with nonces and pinned protocol versions; between planning and execution, add quotas, rate limits and circuit breakers so one fault cannot spread.¹

Detection, the kill switch and the incident runbook

Detection for agents compares behavior with a baseline (which tools, in what order, how often, against which data) and alerts on deviation, because each action of a compromised agent can look legitimate on its own.¹ It starts with an inventory: in IBM's 2025 study, one in five organizations reported a breach due to shadow AI.²

The EU AI Act expects the same of high-risk systems: overseers must be able to interrupt the system with a stop button or similar procedure that halts it in a safe state.¹² The runbook then runs in order:

1. 1Contain Pull the narrowest stop that works, and rotate every credential the agent could reach.
2. 2Preserve Freeze traces, memory snapshots, tool manifests and version records.
3. 3Scope Replay the traces to list every record read, action taken and user affected.
4. 4Eradicate Purge poisoned memory, roll back tool versions and close the path the attacker used.
5. 5Recover Restore service only after fresh attestation of the agent's components and a named person's approval.¹
6. 6Learn Add the attack to the red-team suite, so the same payload fails on every future release.

Red-team the agent before launch and after every change

Red-teaming an agent means attacking the whole system (inputs, tools, memory and peers) to make it take a harmful action, before launch and after every material change. OWASP recommends periodic tests that simulate goal override and confirm that rollback works.¹ Cover each route in:

• Injection through every channel the agent reads (ASI01).
• A poisoned tool description or a look-alike server name (ASI04).
• Planted memory that surfaces in a later session (ASI06).
• A forged agent card or a replayed message between agents (ASI07).
• Credential reuse across sessions and users (ASI03).
• Approval fatigue: harmless requests followed by a harmful one dressed the same way (ASI09).

Score the outcome. A model will sometimes follow an injected instruction; the test passes when the harmful action still fails because a control outside the model stopped it, a measure that holds across model upgrades. After launch, OWASP suggests replaying the previous week's agent actions in an isolated copy of production before any policy is widened.¹ A new model, tool or data source is a material change.

Map the controls to NIST AI RMF, ISO/IEC 42001 and the EU AI Act

One body of evidence serves all three frameworks, so build it once. The NIST AI Risk Management Framework, released on January 26, 2023, organizes the work into four functions: govern, map, measure and manage.¹⁰ ISO/IEC 42001, published in December 2023, sets requirements for an AI management system.¹¹ Article 15 of the EU AI Act requires high-risk AI systems to resist unauthorized attempts to alter their use, outputs or performance, with measures to prevent, detect, respond to, resolve and control attacks, including inputs designed to make the model err.¹² Prompt injection fits that description, so for systems in scope these defenses double as Article 15 evidence.

The CISO sign-off checklist for an AI agent

Sign when the team shows evidence for all twenty items. An item without evidence stays open as a finding, with an owner and a date.

This is how we approach AI agent development: the threat model comes before the first tool is connected, and this evidence is produced as the system is built, so the security review reads a file instead of commissioning an investigation.