CyphrQ
Menu

AI Agent Security Architecture: Seven Layers and Their Controls

A layer-by-layer map of an AI agent's attack surface, from prompt to credentials, with the controls, OWASP and ATLAS IDs and logs each layer needs.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

AI agent security architecture means placing a control at every point where outside influence can enter an agent or leave it as an action: input, retrieval, planning, memory, tools, output and identity. No single layer can be made safe on its own. What holds is defence in depth: each layer assumes the one before it failed.

What is AI agent security architecture?

An AI agent is software built around a large language model (LLM) that pursues a goal by choosing and running actions, not just by writing text. If that idea is new, start with what an AI agent is and the guardrails that matter.

Security architecture maps where trust changes hands and which control sits at each handover. For an agent, instructions, documents, saved memories and tool results all land in the same stream of text the model reads, and its next decision depends on all of it.

CrowdStrike's vendor guide on agent security puts the design problem in five words: "Wherever influence enters, risk enters."

Which layers make up an AI agent's attack surface?

Seven layers is a workable model. Real products blur them, but each has its own owner, failure and log.

  1. Input and prompt. The user's request and the system prompt, the developer's standing instructions.
  2. Context and retrieval. Documents, records, web pages and search results pulled in to answer the request. Retrieval-augmented generation (RAG) is the common pattern: fetch relevant text from a store, then hand it to the model.
  3. Planning and reasoning. The model breaking the goal into steps and deciding what to do next.
  4. Memory. Anything the agent saves and reuses later, across turns, sessions or users.
  5. Tool selection and execution. The functions, APIs and connectors the agent can call, often through the Model Context Protocol (MCP). Our MCP security guide covers that protocol in depth.
  6. Output and actions. What leaves the agent: text a person reads, a link a browser renders, an email sent, a record changed.
  7. Identity and credentials. Whose authority the agent acts with, and which secrets it holds.

The first four layers decide what the agent wants to do; the last three decide what it can do. You can't fully control the first group, so you constrain the second.

How do attacks move between an agent's layers?

Attacks rarely stay in one layer. CrowdStrike's guide describes a feedback loop: tainted input bends the plan, the plan picks the wrong tool, the tool's result is written to memory, and memory shapes the next plan. Two documented cases show the pattern.

In practice: ForcedLeak (retrieval to output). On 25 September 2025, Noma Security disclosed a vulnerability chain in Salesforce Agentforce that it rated "critical severity (CVSS 9.4)". It affected organisations using Web-to-Lead, the feature that turns a public web form into a sales lead.

Text submitted through the form later reached the agent as context when an employee asked about the lead. Data could then leave through an image request to a domain on Salesforce's Content Security Policy allowlist, the list of sites a page is allowed to load content from. That domain had expired, and Noma says it "cost $5" to acquire.

Noma reported the issue on 28 July 2025. Salesforce released Trusted URLs Enforcement for Agentforce and Einstein AI on 8 September 2025. Two layers failed: retrieval accepted public text as context, and output allowed a fetch to a stale domain. A control at either would have broken the chain.

In practice: Gemini memory (input to memory to future sessions). On 10 February 2025, researcher Johann Rehberger showed that a crafted document could get Gemini to save false long-term memories about the user. Instructions planted in the document waited for an ordinary reply from the user, then triggered the memory tool as if the user had asked.

Google assessed it as an "abuse-related risk with low likelihood and low impact". OWASP uses the "Gemini Memory Attack" as its example of memory and context poisoning (ASI06) in the Top 10 for Agentic Applications. The harm outlives the session: clearing the chat doesn't clear the memory.

What controls belong at each layer of an AI agent?

The table maps each layer to its main threats, using identifiers from the OWASP Top 10 for LLM Applications 2025 (LLM), the OWASP Top 10 for Agentic Applications (ASI) and MITRE ATLAS (AML), a public knowledge base of attacks on AI systems.

Layer Main threats (IDs) Controls What to log
Input and prompt LLM01 Prompt Injection; ASI01 Agent Goal Hijack; AML.T0051 LLM Prompt Injection; AML.T0054 LLM Jailbreak Label the source of every input; injection classifiers as one signal, not the gate User, session, input source, classifier verdict
Context and retrieval LLM08 Vector and Embedding Weaknesses; LLM04 Data and Model Poisoning; AML.T0070 RAG Poisoning; AML.T0099 AI Agent Tool Data Poisoning Permission-aware retrieval; partitioned stores; hidden-content checks before indexing; trusted sources only Query, document IDs returned, source and owner of each
Planning and reasoning ASI01 Agent Goal Hijack; ASI08 Cascading Failures; ASI10 Rogue Agents Step and time limits; a fixed list of allowed task types; stop when the plan leaves scope Plan summary per step, linked to the request
Memory ASI06 Memory & Context Poisoning; AML.T0080.000 Memory; AML.T0080.001 Thread; LLM02 Sensitive Information Disclosure Confirm before saving; per-user isolation; expiry; user-visible memory Every memory write and read, with its origin
Tool selection and execution ASI02 Tool Misuse; ASI04 Agentic Supply Chain Vulnerabilities; ASI05 Unexpected Code Execution; LLM06 Excessive Agency; AML.T0053 AI Agent Tool Invocation; AML.T0110 AI Agent Tool Poisoning Tool allowlist per agent; argument validation outside the model; sandboxed execution Tool, version, arguments, result size, approver
Output and actions LLM05 Improper Output Handling; AML.T0086 Exfiltration via AI Agent Tool Invocation; AML.T0101 Data Destruction via AI Agent Tool Invocation; LLM10 Unbounded Consumption Encode or strip links and images; destination allowlist with owner and expiry checks; approval for irreversible actions; spend caps Destination, action type, data class, approval ID
Identity and credentials ASI03 Identity & Privilege Abuse; AML.T0083 Credentials from AI Agent Configuration; AML.T0098 AI Agent Tool Credential Harvesting; AML.T0055 Unsecured Credentials One identity per agent; short-lived, scoped tokens; no secrets in agent config files Token issuance, scope, delegating user, failures

For the tool layer, the MCP specification's Security Best Practices tells clients to run servers "in a sandboxed environment with minimal default privileges" and to warn that servers "run with the same privileges as the client". Step and time limits and spend caps are common engineering practice rather than taken from a named standard.

Defences specific to injection, such as provenance marking and isolating untrusted text from the privileged model, are covered in Prompt Injection Explained. For agents that write code, see the AI coding assistants guide.

How should you monitor an AI agent in production?

Per-layer logs only help if you can join them. Give every request a trace ID and carry it through retrieval, planning steps, memory reads and writes, tool calls and the final output. Without it, an investigator sees a strange email go out and can't tell which document caused it.

CrowdStrike's guide argues for logging why an agent chose an action, not only what it did, in a redacted form linked end to end to the tool call it produced. A logged plan is a starting point for an investigation, not proof of the model's reasons.

NIST's Generative AI Profile (NIST AI 600-1) gives this a governance home. Under MANAGE 4.1, action MG-4.1-002 calls for processes for "post-deployment monitoring of GAI systems, particularly for potential confabulation, CBRN, or cyber risks." For agents built on a vendor's model, GV-6.2-004 asks for "continuous monitoring of third-party GAI systems in deployment."

Then baseline each agent. Its normal behaviour is narrower than a person's, so deviations stand out:

  • a tool the agent has never called before
  • a destination outside its usual set
  • memory writes during a session that ingested outside content
  • a sudden jump in steps, retries or tokens per request
  • retrieval of documents the requesting user couldn't open directly

Finally, plan containment before you need it. Each layer needs its own off switch: stop tool calls, block memory writes, disable the agent's identity, all without waiting for the vendor. Kill-switch basics are in the agent guardrails guide.

What should a CISO ask before approving an agent architecture?

  • Which layers hold untrusted content, and which controls sit after them?
  • Is every control after the planning layer enforced in ordinary code, outside the model?
  • Who can add a tool, data source or memory feature, and does that trigger a review?
  • Can we trace one request from input to action in a single query?
  • What is the blast radius if the agent's identity is fully compromised?

More AI security guides are in the AI Security section.

Going deeper: for security and IT teams

Trust boundaries. Draw a boundary wherever text from a less trusted party enters the context window: retrieval results, tool results, memory reads and messages from other agents. The model can't enforce these, so every control that must hold sits downstream of it: in the retrieval service, tool gateway, output renderer or identity provider. Multi-agent designs add one more boundary; OWASP files spoofed or tampered messages between agents under ASI07 Insecure Inter-Agent Communication.

Threat model. NIST AI 600-1 files prompt injection and data poisoning under its Information Security risk, noting that GAI "expands the available attack surface". The cheapest attacker needs no account, only a way to put text where the agent will read it, like ForcedLeak's public form field. A stronger attacker controls a tool or its supply chain (ASI04, AML.T0110) and can change behaviour after approval. The strongest holds the agent's credentials (ASI03) and needs no model manipulation at all. The tool and identity layers cap what any of them gets.

Retrieval controls. OWASP's LLM08:2025 entry recommends "fine-grained access controls and permission-aware vector and embedding stores", with datasets partitioned so one group can't retrieve another's data. It also describes hidden text in a CV (white text on a white background) steering a RAG screening tool, and recommends extraction that ignores formatting and detects hidden content before documents enter the knowledge base. Check permissions at query time against the requesting user, not only at indexing time against the service account that built the index.

Memory controls. Rehberger's recommendations map directly to architecture: require explicit user confirmation before new memories are saved, and require confirmation for sensitive tool calls once the context contains untrusted data. Store memory per user and per tenant, tag each entry with the session and sources that produced it, and give it an expiry date. That tag lets you purge everything a poisoned session wrote.

Output controls. Treat every URL in model output as an egress path; ForcedLeak's exit was an allowed domain. Review allowlists for domain expiry and ownership as you would DNS records, and prefer proxying images and links over letting the client fetch them directly. Noma's recommendations also include runtime controls on tool calls, output sanitisation and an inventory of agents including AI Bills of Materials.

Approval design. CrowdStrike's guide makes a point worth building in: the approval screen must be one the agent can't edit or argue on. Render the proposed action from the structured tool call (recipient, amount, file) rather than from the agent's own summary of it.

Detection engineering. Tag SIEM rules with ATLAS IDs so coverage gaps are visible. Starting points: AML.T0086 (an agent tool with write access sending data to a new destination), AML.T0080.000 (memory writes in sessions that ingested external content), AML.T0083 (reads of agent configuration files by unexpected processes), AML.T0101 (bulk delete or update calls from an agent identity). The ATLAS IDs here were checked against ATLAS data version 5.6.0 on 25 October 2026; confirm them against the current release before you build on them.

Testing. NIST's MS-2.7-007 calls for AI red-teaming against GAI attacks such as prompt injection. In a test tenant, plant harmless canary instructions in each untrusted source the agent reads (a form field, a document, a tool result) and record which layer stopped each. A layer that stopped nothing is trusted on faith. Track near-misses as MG-4.3-002 suggests.

Questions for vendors. Which of the seven layers do your controls cover, and which are deterministic? How do we purge memory written by one session?

Key takeaways

  • An agent has seven layers where influence enters or leaves: input, retrieval, planning, memory, tools, output and identity.
  • You can't fully control the first four, so constrain tools, output and identity in ordinary code.
  • Real attacks cross layers, so one control per layer beats one strong control at the front.
  • Log every layer, join the logs with one trace ID, and baseline each agent's normal behaviour.
  • Map controls and detections to OWASP and ATLAS IDs so gaps are visible.

Sources