AI Exposure Management: Validating Reachable Agent Attack Paths
Learn what AI exposure management is, how it validates which agent attack paths are actually reachable, and how it differs from AI-SPM and red teaming
Rushali
2026 State of Agentic AI Security
How ready is your organization to secure AI agents?
3 quick questions. See how you compare to other security leaders.
At first glance, a Microsoft 365 Copilot tenant might seem to be well protected against the issue known as "EchoLeak" (CVE-2025-32711, CVSS 9.3), which has just been unveiled. A security policy limiting where data could be sent in responses was in place, link redaction was enabled, and there was a prompt injection classifier. Even with these three controls in place, Aim Security researchers were still able to bypass them and extract a great deal of internal data from an inbound email without ever clicking anything. No control was found, and there was no configuration checklist to identify this route. AI exposure management bridges the divide between a list of settings and a path to your data. This guide includes what it validates, how it differs from AI-SPM or AI red teaming, how it looks in production, and how to take a validated path and convert it into a fixed path you can validate.
The Problem: You Can't Act on Risk You Can't Prove
Security teams have little trouble finding their findings. What they don't have is a defensible method for choosing which ones are important today and which ones are not.
Why Raw Findings Overwhelm Security Teams
Posture tools make their judgment based on the rule they assess, individually. Agent has a tenant-wide read scope: high. A connector can send e-mail to other parties: medium. A knowledge source refers to a common mailbox: medium. When it is repeated by hundreds of agents created by business users on various platforms, the queue of findings grows to thousands of records and is arranged only by severity labels. Most of them are not exploitable, there is some precondition missing. No one outside the company can write to that agent's input, or there's no way to exit the agent, but it is blocked. The results don't specify which ones.
The problem is aggravated by tools. Cloud Security Alliance reveals that a typical large enterprise today operates with 70 or more security vendors, with each vendor releasing its own list. That's the kind of volume that makes people overwhelmed, and it can drive teams to triage based on intuition. What the output security leaders really need is exactly the opposite: prioritization over volume, a short list of paths that are exploitable today that have evidence attached to them, so that every single item on the list is worth an engineer's time.
What Is AI Exposure Management?
AI exposure management is an ongoing process of creating an exposure graph of how AI agents, identities, tools, and data flow together and demonstrating which combination an attacker might actually be able to traverse. It implements Gartner's CTEM (Continuous Threat Exposure Management) model that consists of five phases: scoping, discovery, prioritization, validation, mobilization, and systems that act independently. In essence, the following two concepts explain why inventory is insufficient and how correlation forms attack chains.
Seeing an Agent Isn't the Same as Knowing Its Risk
An inventory is a place that informs you of the existence of an agent, its model, the owner, and its connectors. That is not a risk ruling. There are two agents: one writing an internal wiki and one reading a public support inbox and sending email on the company's behalf. The risk is in the input to the agent, what the agent can reach, and the output of the agent.
This is where agentic exposure management differs from traditional exposure programs. Assets, CVEs, and misconfigurations are scored by traditional tooling. Agents bring in other aspects it wasn't expecting to consider: context is what the model reads as instructions, tool permissions dictate what a sentence can do, and runtime dictates the difference between being configured on file and being run.
Correlating Identity, Data, and Behavior into Complete Attack Chains, Not Isolated Findings
IDENTITY-DATA-BEHAVIOR-CORRELATION correlates three types of signals. Identity is the main entity that the agent represents: a maker's delegated token, a service principal, an IAM role, and the OAuth scopes of the IAM role. Data is the collection of vulnerable stores to which identity can access. At runtime, it is the behavior of the agent that is of interest: which triggers fire, which tools it calls, which destinations it gets traffic to.
When they are connected to form a graph, they create edges like "is triggered by," "can read," or "can send to. An attack chain is a sequence of nodes from an untrusted node entry, to a sensitive data node, to an exit or state change node. A candidate chain could be something like this prior to validation:
Each of the three observations of a posture tool could be a hypothesis to test. For years, attack path management tools have been doing this for Active Directory and cloud IAM; all agents need to have the same graph with new edge types.
AI Exposure Management vs. AI-SPM
The two terms are often used interchangeably, and that leads to teams buying one hoping to get the other. These describe different questions and are best used sequentially.
AI-SPM Finds Misconfigurations and Exposures
AI security posture management works continuously to inventory models, agents, MCP servers, and AI SaaS usage and evaluates each model, agent, MCP server, and AI SaaS usage against policy. It identifies over-permissioned agents, unauthenticated MCP servers, public endpoints, missing guardrails, sensitive data in either the training or retrieval sets, and shadow AI. It is limited in its scope: it compares an asset to a rule, but it does not check if conditions are aligned across assets in order to form a working attack.
Exposure Management Proves Which Ones Are Actually Reachable End-to-End
AI security posture management is the input for exposure management, and each of the findings is considered a hypothesis. The question becomes "can an attacker get from here to that data, through this estate, today?".
AI-SPM | AI exposure management | |
|---|---|---|
Question answered | Is this asset configured against policy? | Can an attacker traverse this chain in the live deployment? |
Unit of analysis | One agent, model, or MCP server | A chain across agents, identities, tools, and data |
Treats a finding as | A risk | A hypothesis to prove or dismiss |
Output | Findings with severity labels | Ranked, validated paths with evidence |
A posture finding that takes a lower priority than those that are reachable. An urgency is issued for a medium severity finding which completes a verified chain.
What "Reachable" Actually Means for an Agent Attack Path
If, in the current deployment, an attacker can put content on the path that the agent reads, then the agent's identity can reach sensitive data, and there is an action channel or egress channel that the data can travel along without breaking a hop, then the path is reachable. There are three types of reachable agent attack paths, and each requires a different type of reachability analysis.
An Agent Ingesting Untrusted Input (email, webform, ticket) → Sensitive Data Pull → External Send
In June 2025, Simon Willison described this trifecta of access to private data, exposure to untrusted content, and the ability to communicate externally as the "lethal trifecta. Email, webforms, and tickets are the traditional sources, as anyone on the internet can send them an email.
The steps involved in validating this shape include making a practical check on each leg. Does an outside sender get a message into the “agent's” mailbox, or is it prohibited by transport rules or sender allowlists? Does retrieval bring that message into the same context window as sensitive documents? Is there any output channel that can send data? It's not a send tool; rather, it is the last question. This exfiltration took place through a reference link, and the exploitation was of a domain that was already permitted by default by the content security policy.
We just mentioned the trifecta above, but there is a test for this in the Agents Rule of Two by Meta, which was published in October 2025: An agent in a session should not have more than two of the above three properties. The 1st leg must be set up; if it is not, it's a theoretical path. The presence of all three, and if a probe penetrates, it has been proven. The whole idea of the exercise is to distinguish between proven and theoretical risk.
Cross-Platform Chains: One Agent Handing Off to Another Across Different Builders
Imagine a Copilot Studio agent that reads and summarizes email from inbound customers, and an Amazon Bedrock agent that accesses the ticket queue, empowered to refund customers and update customer records. The first agent reads untrusted input and writes to an internal system on its own. The second has privileged actions and only reads data that is supposed to be trusted, that is, data in the internal memory. Half of the picture is seen by each platform and scores low risk.
Combined, it becomes one path: attacker-written text traverses a platform boundary and reaches a privileged action with its origin laundered. Such cross-platform attack chains will only appear if identities are joined from both platforms into a single graph (e.g., an Entra service principal and an IAM role), and the handoff becomes a graph edge. The same applies to the business agents' counterparts outside of the business. The University of Illinois researchers showed how they could program one agent, a content agent, to write something into a repository, and then have another agent, Aider, execute the instructions.
Context Privilege Escalation: Low-Privilege Input Propagating to a High-Privilege Action
The same 2026 paper from the University of Illinois that I linked to above defines a context privilege escalation (CPE). The variant is the message-role, where attacker content from lower-privilege source data (like tool result data) is added to a higher-privilege message role. In the cross-scope variant, the content will stay in the system after the launching session, such as being saved in a memory file or a skill file loaded at each subsequent launch.
The researchers tested 12 different agent harnesses (Claude Code, Codex, Gemini CLI) and found 282 context sources vulnerable in 16 attack vectors. One of them: Claude Code executes a series of git commands at launch and puts the messages of recent commits into system-level context, meaning that a command buried in a pull request's commit message is executed with system authority. Since then, Codex and Gemini CLI have released the mitigations.
Then CPE means validation will not be based on the entry point of content. A path check must run along the places where content can be written and the role it is assigned if it is read back. A guide to agent harness security, focusing on the harness side, is available here.
How Attack Path Validation Works
In attack path validation, AI agents are an easier target than hosts, because the attack exploit is written in natural language, and the result is probabilistic. The following four steps transform a candidate chain into a statement you can support.
Step 1: Understand the Environment (assets, identities, connected tools, MCP servers)
Draw the graph first. List all agents, models, triggers, and all tools and their schemas. Add MCP servers, remote servers, and local stdio servers (that are set up within developers' IDEs), as these also contain real credentials. Write down the identity used by each agent and tool and if permissions are delegated from a user or granted to the application. Next, draw in reachable data stores and egress points. Next add in reachable data stores and egress points. Employee-side agents should be in scope with cloud deployments, or else they'll lead to false negatives later.
Step 2: Enrich with Threat Intelligence and Behavioral Signal
Threat intelligence will inform you of the edges that are known to be exploited by the attackers: for example, MITRE ATLAS techniques like prompt injection (AML. Known malicious or vulnerable MCP packages (T0051), disclosed CVEs in your agent platforms. Behavioral signals indicate which edges are active. Even if the same send permission is used, it's a different risk if it's one that's never been exercised, as opposed to one that is used every day and to external domains. The candidates whose runtime behavior matches the edge go to the front of the queue.
Step 3: Build a Targeted, Safe Validation (not a disruptive live exploit)
Write for each candidate the smallest probe that will cover all the hops. In the case of the mailbox chain above, it's a message from an external address containing an instruction to retrieve a planted canary document, which it will then send to the mailbox a security team controls. No one accesses real sensitive data, and no one calls a destructive tool. Since model behavior is variable, try a number of phrasings and delivery variations and note the percentage of success (not failures). First of all, the answer that the AI gives is never the same twice when you're trying to validate an exploit, so a single shot doesn't count.
Step 4: Prove, Prioritize, or Dismiss Each Finding
All candidates are in one of three states. Proven: The canary reaches the sink, and the complete trace is recorded (input, tool calls, identity, data touched, egress). DISMISSED: a control failed to pass a hop, and the record names which control failed, which is evidence for that compensating control. Inconclusive: Re-test with new variants. Existing paths are then scored according to how sensitive the data is, how much it will be blown up, and how simple it is (success rate, and if the attacker has to gain entry at all). As much as proofs, dismissals are important as they allow you to close tickets based on evidence rather than opinion.
Why "Safe" Validation Matters
Validation runs against the deployment that you are interested in, so it needs to be designed not to be the incident it's looking for. Safe AI exposure validation can limit the actions the probe can take and who is authorized to approve it prior to execution.
Testing Exploitability Without Disrupting Production Agents
There are a couple of definite ways that non-disruptive validation is accomplished. On a seeded canary, success can be identified, and there is no real customer data leaving the records. The security team (a dedicated mailbox or domain) owns the sink; therefore, exfiltration ends up in a safe place. Where the platform has a dry-run mode, it is used; probes do not use, delete, or payment tools. A rate limit prevents a probe from causing an agent loop and API quota from being consumed, and a path will not be tested after it is confirmed. Cleanup matters, too: The CPE research indicates that injected content can be left in memory files, and a safe program checks to see if any of the probe text remains in the agent's memory following cleanup.
The Role of a Separate Reviewing Layer to Check Each Probe Before Execution
Probes are frequently created by a model, and a model that generates attacks can easily be the same. Each probe is checked by a separate reviewing layer (usually a deterministic policy with an optional second model). The generator will not approve its own work.
Probes that were rejected get logged with the rule that was broken, and auditors can see that the probe validated stayed within bounds.
From Proven Path to Fix
If the path is not leading to a verifiable change, then it may as well not exist. The following practices are for fixing, receiving, and confirming.
Mapping Each Validated Path to a Concrete Remediation
The fact that the trace is able to give information about each hop means that the fix can be applied to the cheapest hop to break without having to look for the loudest. If one leg of the path is removed, the path collapses: The send tool is removed, the recipient allowlist is added or adjusted, the path is reduced to a single site that the agent needs to send to, mailbox content is marked as untrusted and cannot trigger tool calls, or external sends require human approval. If there's a structural change that would break the business process, the fall-back is a runtime guardrail on the specific hop. Instead of being documented, the successful hop is enforced as a guardrail to block prompt injection and unsafe tool calls in the request path with Akto's confirmed red teaming findings.
Risk Acceptance as a Structured, Evidence-Backed Alternative to Remediation
There are some agents whose only goal is to have all three legs. A customer service representative needs to read correspondence, find the orders, and respond. A risk acceptance workflow makes that decision public rather than it being tucked in a finding backlog:
The expiry date and revalidation triggers are what separate accepted risk from ignored risk. When either fires, the path goes back through validation.
Revalidating After a Fix to Confirm the Path Is Actually Closed
Repeat the same pathway used for the successful probe and perform variations: change the phrasing of the probe, the delivery channel, and alternate egress paths. Data sent out via a rendered link will not have anything done through a recipient allowlist on the send tool. But, as Tanium notes in its CTEM guidance, simply making a change a “full change” does not mean that the change is not reachable. The ticket closes only if the replay and variants fail, and the failed trace is added as evidence closing the ticket.
Why This Matters More for Agents Than for Traditional Infrastructure
In the case of exposure management, this concept began with servers and cloud accounts. The same discipline becomes more pressing here because of two characteristics of agents.
Agents Chain Actions Autonomously: One Small Exposure Can Cascade
An attacker still carries out each phase of the attack when using a vulnerable server. The agent is used to do attack steps on the machine at machine speed, with legitimate credentials, under the guise of normal work. There was no "click" from the victim required by EchoLeak. One untrusted field, for example, one line on a ticket, can be retrieved by a tool called and handed off to another agent, none of them having seen it. The exposure that gets the chain going is usually a rather minor exposure on its own, which is why severity-per-finding isn't catching it.
The Attack Surface Changes Every Time Tools or Permissions Change, Not on a Patch Cycle
Infrastructure risk is primarily on patch and release cycles. Agent risk changes if a maker adds a connector, an admin expands a scope, a model version alters the way instructions are interpreted, or an MCP server updates its tool list. The MCP specification also has the ability for the server to inform clients that its tools have been changed during the session, which is what is accomplished in a rug-pull exploit. None of these events is a CVE, and none of these events is a vulnerability scanner. Most will be missed when using a validation cadence that is based on calendar quarters.
AI Exposure Management vs. AI Red Teaming
Both are an attack on your own systems, hence the confusion. The difference is the question that each one asks.
Red Teaming Simulates Attacks in a Controlled Test Environment
The goal of AI red teaming is to challenge a model or agent by feeding it adversarial inputs to see what is possible: jailbreaks, susceptibility to direct and indirect injection, unsafe tool use, data leakage. Typically, it is used to run broad probe libraries against staging environments or to be run in CI/CD before release, and the results are a description of classes of weakness in the system being tested.
Exposure Management Continuously Validates What's Reachable in Your Actual, Current Deployment
The production graph is used for the beginning of exposure management, rather than the test harness. It inquires if a known weakness can be accessed from the identities, data, and connectors that are currently present. If no untrusted input makes it to an agent that is very injectable in staging, it might not be reachable in production. If an agent has passed all the staging tests, it could be exposed in production if a public form was added by a maker last week.
Why You Need Both, Not One Instead of the Other
Red teaming lets you know what an agent can do. That's where exposure management comes in. They feed each other: AI red teaming results are used as the edges in the exposure graph (this agent follows instructions injected into retrieved content), and the exposure analysis scopes the next round of red teaming toward the agents that reside on proven paths. One alone leaves you with weaknesses, which you can't find, and paths, which you can't weigh.
Moving from Scan-and-Ticket to Continuous Exposure Reduction
Periodic scanning concludes in a ticket. Exposures come to a close with proof of exposure reduction. The transition from one to the other is more of an operating model change than a tooling change.
The Vulnerability Operations Center (VOC) Model Applied to Agents
Check Point describes the Vulnerability Operations Center as the remediation side equivalent of the SOC, and just like the SOC, it was created for the same reason: volume exceeded distributed ownership. A VOC focuses on the qualification, prioritization, and the push toward remediation of exposures, and it has owners and escalation paths. For agents, the VOC has ownership of the validated paths in the queue, and its most difficult task is routing, as the owner of an agent is typically a business user, not an engineer. Helpful metrics also shift: raw number of findings, time to validate, and time to close proven paths are what are changing. Organizations that are focused on security investment based on ongoing exposure management will be three times more likely to experience a breach by 2026, according to Gartner, but there hasn't been a study conducted to measure it, Vectra notes.
Evidence-Backed Findings Over Periodic, Stale Reports
An agent risk report is out of date within days as the agents in the report obtain tools and permissions. The finding's trace is an evidence-based finding: input, tool call, identity, data touched, egress channel, and timestamp. When the canary leaves, they do not argue about severity anymore, and when they give people fewer items, each of which is proven to be real, they take fewer events, and they are happier!
How Akto Delivers AI Exposure Management
The loop described above is addressed by Akto's AI agent security platform: finding all of the agents and enforcing a fix. Below are the capabilities associated with each problem raised previously in this article.
Full Agentic Attack Surface Discovery: Not Just "AI Apps"
Step 1 fails if inventory does not proceed to the authorized cloud app. Drawing on 80+ connectors, Akto automatically discovers and catalogs MCP servers, AI agents, tools, and resources across infrastructure, clouds, and employee laptops. Akto Atlas encompasses visibility and safety measures for the AI agents, LLMs, and MCP tools used by employees on their own devices. Akto Argus maintains a dynamic inventory of homegrown agents, MCP servers, and GenAI applications across development, staging, and production, eliminating the false-negative issue on the employee side and shadow agents.
Attack Path Context Across Agents, MCP Servers, and Tools
Isolated findings are only connected into chains by relationships being mapped. Akto's Agent Context Graph automatically maps agents, MCP servers, tools, and external services into a live topology and connects each agent to the models they interact with and the sensitive data they access to get the most accurate blast radius for tracing and prioritizing. Then, Akto's automated agentic red teaming tests hundreds of probes, including injection, escalation, data leakage, and misuse of tools, and is integrated with CI/CD to ensure that behavior is validated for each change.
Discover → Map → Test → Govern → Enforce as One Operational Loop
These are not tools, but a discover-map-test-govern-enforce lifecycle. The discovery feeds into the Context Graph, which is used in graph-scope testing; the agentic security posture management is used in configuration; and enforcement at runtime is done via MCP and agent guardrails. Argus acts as an MCP proxy between the clients and servers and introduces authentication and tool-level authorization; thus, a hop that is known to be susceptible to exploitation can be blocked at that point. Akto is available as open source, self-hosted, or cloud.
Final Thoughts on AI Exposure Management
The central principle of AI exposure management is to not consider any posture found as an action item but as a hypothesis and to escalate only those paths that have been proven end-to-end safe in the live deployment, and to close only when the original probe fails when replayed. Problems the article highlighted were agents that no one counted in inventory, findings that no one added to a chain, exploitability that no one could demonstrate without taking some risks to production, and fixes that no one could test. It does so by agentic discovery across cloud, homegrown apps, and employee devices; the Agent Context Graph that provides a network of agents, MCP servers, tools, and sensitive data, with traceable paths; automated agentic red teaming with 1,000+ probes to test CI/CD; and runtime guardrails, such as Argus's tool-level authorization at the MCP layer, to enforce the fix at the exact hop. To view this loop with your own agents, book an AI Security demo.
FAQs on AI Exposure Management
How often should agent attack paths be revalidated?
Make revalidation tie to change events rather than calendar. When a tool or connector is added, a permission scope is changed, the underlying model version is changed, or a memory or skill file is added to the database by an MCP server, rerun the validation for any path that touches the added connector or tool or has a scope change. In addition to those triggers, impose a time-based floor (e.g., weekly for paths with regulated data, a good starting point) that catches drift that did not raise an event. Accepted risks are accepted based on the triggers entered in their acceptance record.
Can exposure management confirm whether a remediation actually closed a path?
It can tell you that nothing in the known path works anymore – much more convincing than a change ticket with a done attribute. It has no way of showing that there is no other way. Hence, revalidation should provide for alternate egress channels (and rephrased payloads), and a closed path remains in the graph: if it's later changed to open, it goes back to the queue without requiring anyone to rediscover it.
Experience enterprise-grade Agentic Security solution