Agentic AI Security Guide: Threats and Controls Across the Agent Stack

Agentic AI does not introduce one new risk. It connects familiar ones in a new way. An agent reads untrusted content, decides what to do, and acts with real credentials against real systems, often without a human reviewing each step. In an agent, prompt injection, over-privileged identities, insecure tools and poisoned memory combine into one path from a malicious sentence to a production change. This guide sets out a six-layer threat model for agentic AI, maps it to the OWASP Top 10 for Agentic Applications, MITRE ATLAS and the main control frameworks, and explains which controls matter at each layer. It is written for security architects, identity teams and the engineers who build and run agents.

Key takeaways

• Six layers, one attack path: inputs, model, memory, tools, orchestration and identity. Most serious incidents cross several layers.
• Assume the model can be manipulated: OWASP says it is unclear whether there are fool-proof methods of preventing prompt injection, so design so that a manipulated agent still cannot cause serious harm.
• Identity and access set the blast radius: what an agent can do when it goes wrong is decided by its credentials and tool permissions, not by its instructions.
• Least agency, not just least privilege: the OWASP Agentic Top 10 asks organisations to avoid unnecessary autonomy, because agentic behaviour where it is not needed expands the attack surface without adding value.
• Use one shared vocabulary: map controls, detections and incidents to the OWASP Top 10 for Agentic Applications (ASI01 to ASI10) and to your existing NIST, ISO and CIS controls.

Why agentic AI needs its own security approach

Traditional code follows a fixed path; an agent's path is chosen at runtime by a model. The OWASP Top 10 for Agentic Applications puts the core problem plainly: agents and the underlying model "cannot reliably distinguish instructions from related content". Three properties follow:

• The attack surface is the content. Anything the agent reads, including email, tickets, web pages, documents, calendar invites, tool descriptions and other agents' messages, can steer it.
• Actions are real. Agents send messages, change records, run code and move money using legitimate credentials, so misuse often looks like normal activity in the logs.
• Errors compound. A wrong decision early in a multi-step plan, or in one agent of many, propagates to later steps and other agents.

OWASP's LLM06:2025 Excessive Agency entry names the root causes agents magnify: excessive functionality, excessive permissions and excessive autonomy. The Agentic Top 10 adds least agency: only the autonomy the task requires, backed by observability of what the agent does, why, and with which tools.

Agents are also non-human identities holding API keys, OAuth tokens and delegated sessions, so OWASP NHI Top 10 risks such as long-lived secrets and overprivileged NHIs apply directly. See AI Agents vs Agentic AI.

A layered threat model

The six layers follow how an agent works: it takes in content, reasons, remembers, acts through tools, coordinates with other agents and authenticates to systems. The Cloud Security Alliance's MAESTRO framework uses a seven-layer reference architecture for the same purpose and stresses threats that span layers. Either works if every layer has an owner and controls. See the AI Agent Threat Modelling Guide for running the exercise.

Layer 1: Inputs and context

Threats: direct prompt injection; indirect injection through retrieved documents, web pages, email, calendar invites and tool output; poisoned retrieval-augmented generation (RAG) indexes. The Gemini AI Calendar Prompt Injection 2026 is a clear example, described below.

Controls: treat all external content as untrusted; segregate and label it, as LLM01:2025 recommends; filter for known injection patterns (useful but not sufficient); restrict which sources an agent may read; and keep retrieval permission-aware. See the Prompt Injection Guide.

OWASP mapping: ASI01 Agent Goal Hijack.

Layer 2: The model and its instructions

Threats: goal hijack, jailbreaks, system prompt disclosure, hallucinated actions and drift after model updates.

Controls: never place secrets in system prompts; lock and version system prompts so goals and permitted actions are explicit and auditable, as ASI01 recommends; pin model versions and re-test before upgrading; and have the agent state its intended action in a structured form that a policy engine checks before execution. OWASP calls this check an "intent gate" that treats planner output as untrusted.

OWASP mapping: ASI01 Agent Goal Hijack, ASI09 Human-Agent Trust Exploitation.

Layer 3: Memory

Threats: poisoned long-term memory; cross-user or cross-session leakage; over-retention; an agent re-ingesting its own output as trusted fact.

Controls: isolate memory per user, session and task; scan writes before commit; require source attribution; expire unverified memory; block automatic re-ingestion of the agent's own outputs, which OWASP calls "bootstrap poisoning"; and keep snapshots for rollback. See the AI Agent Memory Security Guide.

OWASP mapping: ASI06 Memory and Context Poisoning.

Layer 4: Tools and integrations

Threats: over-permissioned tools; untrusted input passed to shells, databases or interpreters; malicious or typosquatted tools and MCP servers; hidden instructions in tool descriptions; runaway loops. The OWASP incident tracker maps the Amazon Q Developer Extension Compromise 2025, a destructive prompt placed in the extension, to ASI01, ASI02 and ASI04, and lists the postmark-mcp Malicious MCP Server 2025, which secretly copied emails to the attacker.

Controls: allowlist and pin tools and MCP servers; per-tool least-privilege profiles, such as read-only database queries and no send or delete rights for an email summariser; sandboxes that never run as root; argument validation; spend and rate budgets; and human approval for destructive operations. See the MCP Security Guide.

OWASP mapping: ASI02 Tool Misuse and Exploitation, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution.

Layer 5: Orchestration and inter-agent communication

Threats: spoofed or rogue agents; tampered or replayed messages; a planner passing its full privileges to workers; bad output cascading through other agents.

Controls: mutual authentication with per-agent credentials; signed agent cards and attested registries; signed messages with nonces and timestamps; protocol version pinning; an external policy engine between planning and execution; and circuit breakers. See the Multi-Agent and A2A Security Guide.

OWASP mapping: ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI10 Rogue Agents.

Layer 6: Identity and credentials

Threats: agents on human or shared credentials; long-lived, over-scoped tokens; secrets in configuration, prompts or memory; delegation chains that pass full privileges; permissions checked once and never again. In the PocketOS Database Deletion 2026, a coding agent used an account-scoped Railway token it found in an unrelated file to delete a production volume and its volume-level backups.

Controls: a dedicated identity per agent; short-lived, audience-bound, task-scoped tokens; delegation that records both user and agent; per-action authorisation; and secrets kept out of the agent's context. OWASP's ASI03 entry warns that without a distinct, governed identity, an agent operates in an attribution gap that makes true least privilege impossible. See the Agentic AI Identity Guide and the AI Agent Authorisation Guide.

OWASP mapping: ASI03 Identity and Privilege Abuse, plus the OWASP NHI Top 10 risks for the underlying credentials.

How the layers combine in an attack

Most serious agent incidents follow the same chain:

1. An attacker places instructions in content the agent will read (Layer 1).
2. The model treats them as part of its task (Layer 2), sometimes saving them to memory for later (Layer 3).
3. The agent calls a tool to act on them (Layer 4), or instructs another agent to (Layer 5).
4. The action succeeds because the agent's credentials allow it (Layer 6).

The Gemini Calendar case, disclosed by Miggo Security, shows the chain end to end. The attacker only sent an invite. When the user later asked about their schedule, Gemini read the planted event, followed its instructions and used its own calendar tool, with the user's delegated access, to write a summary of private meetings into a new event. Miggo says this worked even though Google had deployed a separate model to detect malicious prompts. According to Miggo, in many enterprise calendar configurations that event was visible to the attacker. No access control was broken: a read of untrusted content and a write tool sat in the same session, and the write tool became the exfiltration channel.

PocketOS shows that step 1 is optional: no attacker was involved, only a wrong assumption and a broad token in reach. Controls at Layers 1 and 2 reduce how often an agent goes off course but cannot guarantee it never does. Controls at Layers 4 and 6 decide how bad the outcome is when it happens. That is why identity and tool permissions are where to invest first.

Mapping to the OWASP Top 10 for Agentic Applications

The OWASP Top 10 for Agentic Applications for 2026 was published by the OWASP GenAI Security Project on 9 December 2025. It builds on the OWASP Top 10 for LLM Applications: OWASP notes, for example, that ASI01 combines LLM01:2025 Prompt Injection with LLM06 Excessive Agency. Its Appendix C maps NHI Top 10 risks to ASI entries, for example NHI5 Overprivileged NHI to ASI02 and ASI03, so identity teams can reuse existing NHI controls.

Controls that span every layer

• Inventory: record each agent's owner, purpose, tools, data sources and credentials, including agents with OAuth access to corporate SaaS. See the Shadow AI Discovery Guide.
• Policy outside the model: OWASP's LLM06 entry recommends complete mediation, implementing authorisation in downstream systems rather than relying on the model to decide whether an action is allowed. Guardrails in a prompt are not an access control.
• Human oversight in the right places: require approval for irreversible, high-value or externally visible actions, enforced by the platform, with a dry-run or diff shown first. Approving every step breeds rubber-stamping.
• Token hygiene for MCP and APIs: the MCP authorisation specification requires tokens bound to the intended server (the RFC 8707 resource parameter) and validated by it; its security best practices warn that token passthrough creates a confused deputy.
• Secrets out of reach: keep keys out of prompts, memory, configuration files and repositories the agent can read, See the Secrets Management Guide.
• Zero trust: verify every request from every agent as if it might be compromised. See the Zero Trust for AI Agents Guide.

Detection and monitoring

OWASP asks for a behavioural baseline per agent and alerts on deviation, with tamper-evident logs bound to a cryptographic agent identity. Log the agent, delegating user, tool, arguments, policy decision and outcome for every action.

Be able to pause an agent, revoke its credentials and quarantine its memory in minutes, and include agents in the insider threat programme, as ASI01 suggests. See the AI Agent Observability and Incident Response Guide.

Common failure patterns

• Trusting the detector: relying on a prompt-injection classifier as the main control. The Gemini Calendar path worked despite a separate detection model; Google's response, as reported, included asking the user to confirm before Gemini creates events, which is a permission decision rather than a detection one.
• Read and write in one session: create, send or share rights when the task only needs answers, giving injected instructions an exfiltration channel (ATLAS mitigation AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data). EchoLeak 2025 and ForcedLeak 2025 are both mapped to ASI01 in the OWASP tracker.
• Tokens left in reach: account-wide tokens in repositories and config files that a coding agent can find, as in PocketOS. See the AI Coding Agents Security Guide.
• Direct agent-to-production access: OWASP's ASI05 guidance warns against it, and the tracker maps the Replit AI Agent Database Deletion 2025, where an agent deleted a production database and generated false outputs, to ASI01, ASI09 and ASI10.
• Unvetted tools and servers: MCP servers and extensions installed from public registries without pinning or provenance checks.
• Approval theatre: approvals for every step, or a model-written rationale instead of the actual action and its side effects.
• No off switch: no tested way to stop an agent and revoke its credentials quickly.

Framework mapping

The mappings show where agent controls sit in frameworks you may already report against. NIST's preliminary draft Cyber AI Profile (IR 8596) organises AI cybersecurity guidance using CSF 2.0 outcomes, and the NIST AI RMF provides the governance functions (GOVERN, MAP, MEASURE and MANAGE) for AI risk more broadly.

Metrics that show progress

A maturity path

Each stage makes the next possible; skipping containment for runtime tools leaves broad credentials untouched. For a scored version, see the Agentic AI Identity Maturity Model.

1. Visibility: find every agent and AI integration, including those with OAuth access to corporate SaaS, and assign an owner.
2. Containment: move agents onto their own identities with least privilege; remove shared and human credentials and secrets in the agent's context.
3. Guardrails outside the model: tool allowlists, sandboxes, policy checks and approval gates for high-impact actions.
4. Runtime assurance: per-action authorisation, behavioural baselines and alerting tied to ASI risks.
5. Resilience: tested kill switches and revocation, regular red teaming, and threat models kept current as agents gain tools and autonomy.

Implementation roadmap

See the Agentic AI Security Policy Template.

Practitioner checklist

• Maintain an inventory of agents, their owners, tools, data sources and credentials.
• Treat all content an agent reads, including tool descriptions and other agents' messages, as untrusted.
• Keep secrets out of prompts, memory, agent configuration files and repositories agents can read.
• Give each agent its own short-lived, least-privilege identity; authorise each action, not just the session.
• Allowlist and pin tools and MCP servers, sandbox code execution and restrict network egress.
• Bind tokens to their intended audience and never pass client tokens through to downstream APIs.
• Require enforced human approval for irreversible or high-value actions, with a preview of the actual effect.
• Authenticate and integrity-protect communication between agents, and stop privileges flowing down delegation chains.
• Log agent, user, tool and outcome for every action; alert on deviation and rehearse stopping an agent and revoking its access.
• Threat model and red team agents before deployment and after significant changes.

Standards and references

• OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• OWASP: Non-Human Identities Top 10 (2025)
• Model Context Protocol: Authorization specification
• Model Context Protocol: Security Best Practices
• MITRE: ATLAS data (Adversarial Threat Landscape for AI Systems)
• Cloud Security Alliance: Agentic AI Threat Modeling Framework: MAESTRO
• NIST: AI Risk Management Framework (AI RMF 1.0)
• NIST: IR 8596 Cyber AI Profile (initial preliminary draft)
• NIST: Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations

Related NHI Mgmt Group resources: Agentic AI Identity Guide · MCP Security Guide · AI Agent Threat Modelling Guide · Identity Governance for AI Agents Guide · NHI breach database