The Agentic AI Attack Surface, Layer by Layer

Security researchers have converged on a useful way to describe agentic AI: as a stack of layers, each with its own failure modes. A 2025 research framing splits it into four - a data layer of storage and models, an orchestration layer of planning and reasoning, an agent layer of execution and tools, and a system layer of infrastructure and user interaction. The important claim in that framing is not the taxonomy itself. It is that risk propagates across layers rather than staying contained: a poisoned input at one layer becomes a privileged action at another.

That is the right mental model, and this piece accepts it. But it leads somewhere the framing does not fully spell out. Walk the four layers and ask a blunt question at each: who already owns this control? For most, the answer is a category of tooling your organization probably already runs. For one, the answer is usually nobody. What follows is the attack surface, layer by layer, and an honest account of where the coverage runs out.

The layered model, and where coverage runs out

Here is the argument in one sentence before the detail. Network security, container and image scanning, cloud posture management, and identity systems cover most of the data and system layers, and part of the rest. The agent layer - the actual agents, MCP servers, skills, plugins, extensions, hooks, secrets, and CLIs sitting on developer and employee endpoints - is where cross-layer attacks come to rest, and it is the layer where almost no one has an inventory or a place to say no before a call runs.

You can't govern what you can't see. Every other layer has a scanner pointed at it. The agent-artifact layer, the one on the endpoint, does not.

Layer 1: Data (storage and models)

The data layer holds the models and the stores they read and write. Representative threats are model exfiltration, training-data poisoning, inference attacks that reconstruct sensitive inputs, and direct data-store manipulation. These are cross-layer by nature: a poisoned store or a manipulated model surfaces later as a bad decision at the orchestration layer, far from where the tampering happened.

This layer already has owners. Data-store hardening, access controls, and DLP guard the stores, and the gateway in front of a model is where teams put request inspection and rate controls - see Securing LLM Gateways and Proxies. Anomity does not inspect model weights or watch data-store traffic. Its contribution is narrow: it inventories the secrets and credentials that agents carry on the endpoint, redacts them on-device so only metadata leaves, and records which agents and MCP servers hold access to data sources. That complements DLP; it does not replace it.

Layer 2: Orchestration (planning and reasoning)

The orchestration layer is where an agent decides what to do. Representative threats are goal subversion, recursive or looping agent-invocation abuse, and state-graph compromise - attacks that bend the plan rather than the code. Frameworks that live here, such as LangGraph and Microsoft AutoGen, and the protocols that connect components, the Model Context Protocol and Agent-to-Agent messaging, define this surface. We break those down in Model Context Protocol (MCP) Security, Explained and Agent-to-Agent (A2A) Security and Trust Boundaries.

The uncomfortable part is that there is no mature orchestration scanner. Goal subversion usually arrives as indirect prompt injection, and no production model reliably separates instructions from data - see Indirect Prompt Injection, Explained. You cannot patch the planner into safety. What you can do is put an enforcement point at the moment a plan turns into an action. Anomity's hook sits at the agent's own call boundary - for example a Claude Code PreToolUse hook - and can allow, deny, or log a call before it runs. A subverted plan still has to make a real tool call to do damage, and that call is where a decision can be made. Pair the gate with behavioral baselines, as in Runtime Monitoring and Anomaly Detection for AI Agents, so a plan that suddenly loops or reaches for data it never touched before stands out.

Layer 3: Agent (execution and tools)

The agent layer is where intent becomes action: the agent calls tools, loads skills, and talks to other agents. Representative threats are tool and agent subversion, supply-chain attacks on third-party components, and cross-agent information poisoning where one compromised agent feeds tainted context to the next.

This is the layer the industry undercounts. Container and image scanning covers the images an agent runs inside, and that matters - but the risky artifacts are not in the base image. They are the skills, plugins, extensions, MCP servers, and hooks a developer installs into an agent after the fact, often from a public registry, often without review. A malicious skill or a poisoned MCP tool definition is a supply-chain compromise that no container scan will ever see, because it lands on the endpoint at runtime. We go deep on this in Securing AI Agent Frameworks, MCP Server Security: The Complete Guide, and AI Supply Chain Attacks: A Defender's Guide. Cross-agent poisoning through ordinary collaboration channels is the mechanism we documented in Comment-and-Control: Multi-Agent Prompt Injection and Credential Theft.

This is also where the lethal trifecta assembles - private data access, untrusted input, and an egress path, all wired together through installed tools - as we traced across four production disclosures in The Lethal Trifecta in Production. And it is the layer Anomity is built for. Its unprivileged Endpoint Sensor runs on Windows, macOS, and Linux and inventories eight AI artifact types - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - so you have an actual bill of materials for what is installed and active. The same hook that enforces at the orchestration boundary enforces here, at the tool call itself.

Layer 4: System (infrastructure and user interaction)

The system layer is classic infrastructure security applied to the machines and services the agents run on: misconfigurations, software vulnerabilities, weak authentication, and exposed APIs. It is the most mature layer in the stack. Cloud security posture management catches misconfigurations, vulnerability management and EDR handle software flaws, IAM handles authentication, and network intrusion prevention watches exposed APIs. Anomity does none of these, and does not try to; how the pieces fit together is the subject of The Practical Guide to AI Agent Security.

What Anomity adds at this layer is endpoint-level presence and evidence. It runs as an unprivileged sensor rather than a kernel agent, keeps a queryable 90-day audit trail of what agents actually did, and routes events to the SIEM, Slack, email, or Jira your team already uses. It complements EDR, DLP, GRC, and network tooling rather than replacing them, and it carries SOC 2 Type II.

The layers in one view

Read the third column. Three of the four layers have a clear owner. The agent layer's nominal owner is container scanning, and container scanning cannot see a skill or an MCP server that a developer installs into a running agent. That is the blind spot the whole framing points at without naming it.

It is also why supply-chain risk is described as cross-layer: developers have no direct oversight of the third-party libraries, external models, and downloaded tool definitions they pull in, so a single poisoned component can touch data, orchestration, and agent layers at once. The only place to catch that is where the component actually lands - the endpoint. We put numbers around how large this gap has grown in Agentic AI Trends 2026: The Visibility Gap, and what happens when it goes unmanaged in The OpenAI and Hugging Face Incident: Agent Containment.

How Anomity covers the agent-artifact layer

Anomity is deliberately scoped. It does not do network intrusion prevention, container scanning, or cloud posture management - those layers already have strong owners, and doubling them up buys nothing. It operates at the endpoint artifact layer, the one place a full agent inventory and a per-call decision can actually live, because that is where the agents, MCP servers, skills, plugins, hooks, and CLIs physically are.

Concretely, that is three capabilities. Inventory: the unprivileged Endpoint Sensor discovers the eight artifact types across the fleet, including the shadow ones nobody registered (see /#features). Runtime governance: the agent hook allows, denies, or logs a tool call before it runs, redacting secrets on-endpoint so metadata-only records leave the device (see /#runtime-governance and /#how-it-works). Audit: a queryable 90-day trail, routed to your SIEM, Slack, email, or Jira, so you can reconstruct what any agent did (see /#outcomes). How that lines up against adjacent categories is on /#compare, and the deployment detail is in the docs.

If you already run DLP, EDR, CSPM, IAM, and a gateway, you have most of the stack covered. The agent-artifact layer is the piece that sits between them, on every endpoint, unscanned - and it is where the cross-layer attacks in this map come to rest. To see it in your own fleet, request early access.