AI Security Perimeter Design for Agentic Workloads

An enterprise agent deployed today reads a support ticket, queries a customer database, drafts a refund in Stripe, checks the action against a Slack thread for approval context, and pushes a code fix to a repository, all inside a single workflow, often without a human looking at any intermediate step. That sequence is the whole problem in miniature. Traditional perimeter security was built on three assumptions: people sit inside the boundary, data and services sit at its edges, and access gets decided once, at login, based on where a request comes from and who it claims to be. Agents break all three at the same time: they are processes that act, chain, and decide, continuously, across every system they touch, not people waiting at a login screen.

The old model also assumed a round trip back to a human. A user logs in, does something, and if a system flags a problem, a person is there to stop and reconsider. Agents operate in a loop of observing, deciding, and acting, often many times a minute, with no human checkpoint between steps. The boundary that perimeter security relies on never gets a chance to reassert itself, because there is no pause in the loop where a boundary could matter.

Access control stops working the same way too. A login event used to be the moment identity got checked and permissions got granted for the length of a session. An agent's permissions need to be evaluated at the moment of each action, because the agent might call a tool, combine its output with another tool's output, and act on a conclusion no human ever reviewed. One compromised agent does not expose one account the way a stolen password does. It can execute commands, pull data out of multiple systems, and move laterally through every service it holds credentials for, producing a blast radius no single human user could generate on their own.

MCP as the primary attack surface for agentic deployments

The Model Context Protocol is the channel through which agents reach file systems, databases, APIs, code repositories, and enterprise software. A flaw in MCP is not contained to one integration. It propagates across the entire agentic stack at once, because nearly every tool an agent touches arrives through the same protocol.

The protocol also inverts the client-server relationship security teams are used to reasoning about. Clients used to ask servers for data, and the client controlled the conditions. MCP often flips that arrangement: servers query, and sometimes execute actions on behalf of, the clients connected to them. Threat models built around the old direction of trust do not track attack paths that run the other way, and those paths remain largely unmapped in practice.

That gap compounds through three connected attack classes. Tool poisoning is the entry point: an adversary hides instructions inside a tool's description, text the model reads but the user interface never surfaces, directing the agent to exfiltrate data or quietly suppress any notification of what it just did. Rug pull attacks extend that foothold over time. Nothing in the MCP spec tracks changes to a tool's definition or forces re-approval when one changes, so a server can earn trust with a benign tool, then redefine that same tool later. The agent keeps transacting with the altered server, session after session, with no mechanism anywhere in the chain to catch the switch. Cross-server tool shadowing then multiplies the damage, because a single MCP session commonly connects to dozens of servers at once, spanning file systems, GitHub, Slack, Stripe, and database connectors. One compromised server in that bundle can redefine how the agent understands every adjacent trusted server it's also connected to, turning one bad actor into a foothold across an entire toolchain.

OX Security disclosed a STDIO flaw in April 2026 that shows this is a design default built into every official MCP SDK, for Python, TypeScript, Java, and Rust, the four SDKs available at the time of disclosure, not a bug in one product. The Cloud Security Alliance has confirmed that Anthropic acknowledged the behavior as intentional and declined to change the protocol's architecture, which leaves remediation sitting entirely with the developers building on top of it. Authentication, meanwhile, is optional under the spec itself: an internet scan from July 2025, cited in CSA's research, found hundreds of publicly reachable MCP instances answering unauthenticated requests, servers that technically comply with the specification while remaining practically wide open.

The supply chain angle ties these pieces together. CyberDesserts' incident log traces a common thread through every major 2026 incident, from the Claude Code remote-code-execution flaw triggered by a poisoned repository config, to thousands of malicious skills found circulating in ClawHub, to the hundreds of unauthenticated MCP servers sitting on the open internet. MCP itself is the connective tissue. So you have a supply chain problem before you have anything else in AI agent infrastructure.

The Agentjacking case from June 2026 makes the stakes concrete. Thousands of organizations were found running Sentry MCP configurations with injectable DSNs, and testing by Tenet Security found that the vast majority of attempted agent executions succeeded against that exposure. Sentry declined to remediate the underlying issue and shipped only a payload-string filter in response. Exposure of that kind can persist well past disclosure, sitting live in production long after the problem has a name.

Identity verification has limits of its own, and that's where OAuth's limits show up. A multi-hop agent architecture, where an orchestrator delegates work to a specialist agent that then calls an MCP tool, is common in production deployments. OAuth tokens authenticate the final hop in that chain, the specialist calling the tool, but carry no record of the delegation that got it there. There's no delegation chain embedded in the token, no mechanism for the token holder to attenuate scope as authority passes from agent to agent, and no provenance binding tying the action back to the original request. An auditor looking at the token sees a valid credential. What that credential cannot show is who authorized the chain of actions that produced it.

The MCP spec revision dated 2026-07-28 tightens the authorization model considerably: mandatory resource indicators under RFC 8707, protected-resource metadata discovery under RFC 9728, issuer validation under RFC 9207, client-identity metadata documents, and a refined step-up authorization flow, first introduced in the 2025-11-25 spec, now carrying a mandatory scope-union requirement for insufficient-scope errors. All of that strengthens the transport hop. None of it touches the delegation chain itself, and closing that gap is the job left to whatever governs agents after the token is issued.

Enterprises using these systems show the same gap in their identity picture. Roughly one in five companies treat each agent as its own independent identity. The other four in five rely on shared credentials. A single compromised agent in that majority compromises everything else running on the same credential, with no boundary between them.

Policy enforcement at the tool-call level, not the session level

A session is a long window, and an agent authenticated at the start of one holds that authentication for every action it takes until the session ends. That is the structural flaw: once in, an agent effectively carries a blank check for the duration, regardless of what it actually does with it. Tool-call-level enforcement, evaluating each individual action at the moment it happens, is the only granularity fine enough to actually constrain what an agent can do.

The habit of granting broad upfront permissions to keep agents flexible across varied tasks is widespread, and both the NSA's May 2026 guidance and the joint CISA/NSA publication from the same month name it as a primary risk category. The logic behind it is understandable: nobody wants to reconfigure permissions every time an agent needs to handle a new kind of task. But the blast radius when a broadly-permissioned agent gets compromised is disproportionate to whatever convenience the broad grant bought. CISA, the NSA, and their Five Eyes partners said as much directly in their joint guidance titled Careful Adoption of Agentic AI Services: give agents only the minimum access they need, for the shortest time required. That principle cannot be enforced at the session level. A session grants access for its full duration by definition, so a minimum-necessary-access rule means nothing unless you check it at every individual call.

Static allowlists fail for a related reason: agents invoke new tools dynamically, at runtime, based on what a task requires in the moment. A permission list fixed at onboarding has no way to account for a tool the agent decides to call six steps into a workflow that didn't exist when the list was written. Policy has to evaluate each call against the agent's current context as it happens, not against a snapshot approved weeks earlier.

Cisco's 2026 report documents this as a real pattern, not a hypothetical: a compromised research agent injecting hidden instructions into output that a financial agent then consumes and acts on. Implicit trust between agents, left unchecked, turns one compromised link into a chain of unverified instructions passed downstream.

The Drift and Salesforce OAuth token theft case shows what happens when this kind of enforcement is left out. An attacker compromised Salesloft's infrastructure and stole OAuth tokens that Drift held for its Salesforce integration, then used those tokens to reach into and pull data out of hundreds of Salesforce customer environments. The session itself was authenticated the whole time. What was missing was any governance over the individual tool calls made with that authenticated session, which is precisely where the damage happened.

Uber's governance model shows the alternative at scale. Three layers were built before agent adoption scaled across the company: an LLM gateway that handles PII redaction, access control, and audit logging on every request; an MCP gateway and registry that governs every single agent-to-tool connection across more than 10,000 internal services; and an agent identity system that extends Zero Trust infrastructure into multi-agent workflows, attaching cryptographically attested lineage to every tool call made. AIUC-1's update in the second quarter of 2026 moved the same way at the standards level: it made third-party access monitoring a mandatory control and extended tool call validation to cover MCP servers, closing a gap where prior API-focused security requirements had never accounted for agentic protocols.

This is where identity and policy meet in practice. Verified agent identity tied to every action, established through mechanisms like single sign-on, identity provisioning standards, and just-in-time credentials, is the foundation that makes tool-call-level enforcement possible at all, because a policy engine can only govern a call it can attribute to a specific agent. Platforms including Runlayer enforce identity at the MCP gateway level for this reason, attaching a traceable agent identity to every tool call rather than letting a shared service account absorb the action anonymously. When one agent on a shared credential is compromised, there's no way to isolate which actions were its own and which belonged to every other agent riding the same credential. Identity bound to the individual call is what keeps that collapse from happening.

Real-time detection for the threat classes that identity and policy alone cannot stop

Identity checks who is acting. Policy checks what that identity is allowed to do. Neither one checks whether the agent's understanding of its own task has been quietly manipulated, and that's the gap tool poisoning, rug pull attacks, and cross-server shadowing all live in. An agent can present a fully valid identity and stay within every policy boundary it's been given while still executing what an attacker wants, because these attacks work by changing what the agent believes it's doing rather than by stealing a credential or exceeding a permission.

The rug pull attack shows most clearly where identity and policy run out. And nothing about that redefinition touches authentication or violates any static policy, since the agent is still calling a tool it was already approved to call. Catching that kind of attack requires watching behavior over time instead of re-checking a credential that was never the problem.

Prompt injection has moved well past isolated, single-turn tricks. Cisco's 2026 report documents multi-turn attacks unfolding across extended conversations, achieving high success rates in testing against both open-weight models, as detailed in the "Death by a Thousand Prompts" paper, and closed, proprietary frontier models, covered in Cisco's 2026 follow-up report. When a session stretches across many turns and carries memory and tool access the whole way through, defenses built around catching a single malicious prompt in a single exchange offer much weaker assurance.

A related and subtler failure mode is intent drift: an agent that starts a session fully within its authorized scope can be nudged, prompt by prompt, toward actions nobody originally authorized. Each individual step looks like a small, reasonable extension of the last. Session-level controls can observe this kind of drift happening. They have no mechanism built in to interrupt it before the agent arrives somewhere far outside its original mandate.

The supply chain carries too much volume for manual review to keep up with. Snyk's ToxicSkills audit of the ClawHub ecosystem found that a significant share of skills in circulation carried at least one critical security issue, and the ClawHavoc campaign introduced malicious skills at a volume no human review process could keep up with. Catching that volume of bad behavior takes automated monitoring that watches what a skill actually does at runtime, rather than relying on someone reading its code before approval.

Three specific detection capabilities follow directly from these failure modes: inspecting tool outputs and the context returned to an agent for embedded instructions that try to redirect its next actions, comparing an agent's actual sequence of tool calls against its declared workflow to catch scope creep as it accumulates, and watching for data movement patterns that don't match what the agent's authorized task should ever produce. None of that works without a reliable record underneath it. Tamper-proof audit logs with full OTEL tracing are what make post-incident reconstruction possible at all, and that same logging satisfies the records-of-processing requirement under GDPR Article 30 in any case where an agent itself qualifies as the data processor. Identity establishes who acted. Detection catches the agent that did everything right on paper while it did what an attacker wanted.