The Agent Security Stack: Transport, Identity, Policy, Runtime

Let’s say you’re building an agent. It reads Linear issues, pulls context from Gmail, opens GitHub PRs, and posts updates in Slack. Or maybe it’s a system of agents with an orchestrator that hands off to specialists, each with its own job to do. Now you need to figure out how to secure everything, and you end up with several browser tabs pulling you in different directions.

One tab is selling you an MCP gateway. Another is a non-human identity inventory tool. Another is a runtime guardrail that watches for prompt injection. Another is a connector platform. Another is a policy engine. Another is a new spec that wants to replace API keys entirely. They all look like answers to “how do I secure my agent,” but they actually address different questions.

I work on agent identity and access at Keycard, and agent security solutions are proliferating so rapidly it’s challenging to know what you actually need for what, and why. This post is a map of the agent security stack: what each layer does, what kinds of tools live there, where the seams are, and which layer is currently the most under-served.

The demand for agent identity

In January 2026, CrowdStrike agreed to acquire identity security startup SGNL for approximately $740 million. A month later, Palo Alto Networks closed its $25 billion acquisition of CyberArk on February 11, 2026. Both companies commented on the future of agentic identity when they announced the deals. CrowdStrike CEO George Kurtz put it this way: “AI agents operate with superhuman speed and access, making every agent a privileged identity that must be protected.” When Palo Alto acquired CyberArk, CEO Nikesh Arora said, “The emerging wave of AI agents will require us to secure every identity — human, machine, and agent.”

They’re right, but this is where the problem starts, not where it ends. “Agent identity” isn’t one question. It’s several questions, and the answers live in different layers of the agent security stack.

Why one agentic security layer isn’t enough

A typical human API call has one control surface. You click a button, your session cookie travels to a server, and one permission check determines what happens.

An agent call chain has more surfaces than that. The LLM decides to invoke a tool. The invocation crosses a transport. A credential rides along. The receiving service authorizes the call. More and more, that “service” is another agent, which calls another, which calls a third, with each step needing its own scoped authority, traceable back to the human who initiated the whole chain.

Each surface fails differently. Transport auth tells you a client is allowed to connect, but it doesn’t tell you what the user authorized. A policy engine evaluates rules, but it doesn’t know how the credential was issued. A runtime guardrail watches behavior, but it doesn’t know what the agent is allowed to access. You can’t collapse them into one check without losing something that matters.

So let’s take a closer look at the layers of the agent security stack.

Layer 1: Transport

Transport is the front door. This is where an agent or client proves it’s allowed to talk to a server.

The Model Context Protocol (MCP) does a lot of heavy lifting right now. The MCP authorization spec anchors on OAuth 2.1 and treats MCP servers as resource servers, separate from authorization servers. Discovery happens via Protected Resource Metadata (RFC 9728). The 2025 spec revisions introduced two pieces worth knowing about. The June 2025 revision made Resource Indicators (RFC 8707) mandatory, so a token issued for one MCP server can’t be replayed against another. The November 2025 revision added incremental scope consent, allowing clients to request only the minimum access needed for each operation, and introduced Client ID Metadata Documents to replace dynamic client registration at scale. Agent2Agent (A2A) solves a similar problem for agent-to-agent communication with its own profile.

Agent security products built exclusively around MCP gateways and proxies centralize discovery, add audit logging, and enforce policy at the transport boundary. Such platforms are coupled to one transport. A gateway built around MCP doesn’t exercise control when your agent talks over A2A or hits a REST API directly.

Security solutions operating on the transport layer tell you if this client is allowed to connect, and if the client’s token is valid for this resource.

Transport layer solutions don’t tell you whether the user authorized this specific action, who’s actually behind the call, or whether the agent should be doing this now.

Layer 2: Identity and delegation

This is the layer that’s been most under-built and is now where the most action is. The questions at the identity layer are: who is this agent? Who is the agent acting on behalf of? What task is the agent carrying out?

Long-lived API keys answer none of those questions. A static token in an environment variable just says “whoever has this string is authorized.” It can’t tell you the user behind the request, the task it was authorized for, or whether the authorization is still valid.

Several solutions live in this layer, and conflating them is one reason the space feels confusing.

Workload identity: SPIFFE and SPIRE give workloads cryptographic identity, so a service can prove who it is without shared secrets. Cloud providers do their own version of this for managed workloads (AWS IAM Roles Anywhere, GCP workload identity, Vercel’s OIDC tokens). This is the prerequisite for everything else; without it, you’re back to bearer tokens. But workload identity by itself doesn’t address delegation. It tells you the workload is real. It doesn’t tell you what user the workload is acting on behalf of. Combined with runtime attestation, this is what lets some platforms eliminate static credentials entirely. The agent’s identity comes from its environment at runtime, not from a secret on disk.

Delegation primitives: RFC 8693 OAuth 2.0 Token Exchange is a foundational standard here. A client presents its own identity and a subject token to a Security Token Service (STS). In return, it receives a new token scoped for a specific downstream resource.

A new IETF draft, Transaction Tokens for Agents, extends Txn-Tokens with actor and principal fields, where the actor is the agent performing the action and the principal is the human or system on whose behalf the agent is acting.

Dick Hardt’s AAuth proposal goes further. Every agent has its own cryptographic identity: an agent identifier (aauth:local@domain) bound to a signing key, published at a well-known URL, and verifiable by any party, with no pre-registration and no shared secrets. These are protocols, not products. Systems are built on top of them.

Credential brokers: These products handle the OAuth dance for SaaS APIs and give your agent a token. They’re useful when your agent needs to talk to twenty SaaS services and you don’t want to manage twenty OAuth flows yourself. Some of them layer scope-level governance, just-in-time confirmation, or fine-grained authorization on top. But structurally, none of them fuse identity, delegated authority, agent attestation, and policy into a single policy evaluation at the moment the credential is issued. The credential is brokered first. When policy is present, it’s evaluated separately.

Unified identity and access for agents: Keycard provides this. User identity federates from Okta, Entra, Google, or any OIDC provider. Workload identity federates from AWS, GCP, Vercel, GitHub Actions, and equivalents. Agent identity is established through workload attestation, binding the agent to a verified runtime (SPIFFE, Kubernetes service account, cloud instance ID, mTLS). A Security Token Service implements OAuth 2.1 plus extensions, evaluating policy at the moment an agent requests access. Teams can integrate with SDKs, either through direct STS calls, or through an MCP gateway. Whatever the entrypoint, the same authorization context and policy engine run underneath.

Think of this as IAM redesigned for the agent use case, where the principal might be a person, a workload, or an agent acting on a human’s behalf. The same system handles all three.

The identity and delegation layer tells you who is acting, on whose behalf, with what authority, for what task.

This layer doesn’t tell you specifically what the agent is allowed to do once it has a credential. That’s the next layer.

Layer 3: Policy

Policy is the question of whether a specific action in a specific context is allowed on a specific resource. Identity and policy answer different questions. Identity tells you who an agent is. Policy tells you whether they’re allowed to do something.

Standalone policy engines occupy this layer. AWS open-sourced Cedar, which is formally verifiable and strongly typed. Open Policy Agent is a long-standing Rego-based engine. OpenFGA is focused on relationship-based access control. AuthZEN is an emerging OpenID standard for a vendor-neutral PDP/PEP query protocol that facilitates interoperability.

The classic deployment pattern here is PDP/PEP: a policy decision point (PDP) answers “is this allowed,” and a policy enforcement point (PEP) stands in the request path to allow or deny an action. This pattern was designed for a credential that already exists, and you need to decide whether to honor it.

That assumption matters.

Given an identity, an action, a resource, and some context, policy determines if an action is allowed.

Policy does not tell you how the credential got there, or what to do about it after access evaluation.

Layer 4: Runtime behavior and governance

The last layer is the messiest, because it addresses three different problems people lump together.

Runtime guardrails: Solutions that provide just-in-time guardrails watch what the agent is doing and flag prompt injection, tool poisoning, jailbreaks, and behavioral anomalies. They operate on content, not identity. A guardrail can tell you the agent is behaving badly. It can’t tell you whether the agent should have access in the first place.

Non-human identity inventory: These solutions inventory all the API keys, service accounts, and OAuth grants in your environment and tell you what’s overprivileged, stale, or shared. They’re posture management. They tell you about credentials that already exist. They don’t issue or evaluate credentials in the request path.

Audit and delegation chains: These are logs that capture what happened, who authorized it, and what the credential allows. Most tools at this layer reconstruct this after an action; some capture it before.

Runtime behavior and governance tells you if the agent is doing something it shouldn’t, what credentials exist in your environment, and what the agent did after the fact. Guardrails can prevent some attack types at runtime.

But this layer doesn’t tell you whether the agent should have access in the first place.

The protocol layer is moving fast

In the past eighteen months, the protocol surface has gone through real change. The MCP authorization spec shipped three versions in less than a year. A2A has its own auth profile. RFC 8693 token exchange has been around since 2020 but is suddenly doing new work for agent scenarios. Txn-Tokens-for-Agents shipped its fourth IETF draft in February 2026. AAuth emerged with a fresh take on agent identity. AuthZEN is doing the same for policy queries by making them vendor-neutral.

If your agent auth is built inside a transport, transport churn becomes your churn. MCP gateways are the clearest example: they centralize policy at the MCP boundary. That’s great if all your agent traffic is MCP forever. It’s a problem if you need any non-MCP protocol. Every time the spec is revised, your gateway has to be updated. Every new transport (A2A, AAuth’s signed HTTP, unnamed thing shipping next month) is a new gateway to deploy.

If your agent auth is built underneath transports on a primitive like RFC 8693 token exchange, your auth model is resilient to transport churn. The agent presents its identity, requests a scoped credential for a specific action, and gets it or doesn’t. That happens the same way whether the agent is talking over MCP, hitting a REST API, talking to other agents over A2A, running a CLI command, or using a transport that hasn’t been invented yet.

The term for these tools is “protocol-agnostic.” A protocol-agnostic solution continues to work regardless of transport upheaval.

When policy and credential issuance are the same act

Most of the stack treats identity, delegation, and policy as separate concerns with separate enforcement points. You federate identity at one place (your identity provider). You broker credentials at another (a connector platform). You evaluate policy at a third (a policy decision point at the access boundary). Each point has its own model, its own integration story, and its own seams.

When an agent requests authorization, Keycard’s STS evaluates policy against the full authorization context: the user’s authenticated identity, their device posture, the agent’s identity and workload attestation, delegated authority, and the requested resource. If policy permits, a scoped credential is issued. If it doesn’t, no credential exists.

This compounds when you stretch from one agent to a chain of agents. A user asks the orchestrator agent to triage incoming Linear tickets. The orchestrator delegates the GitHub investigation to a code-search agent. That agent calls a doc-search agent. At each agent transition, Keycard’s STS evaluates policy and issues a new scoped credential, each narrower than the one before. The doc-search agent never holds the credential that could close a ticket. The code-search agent never holds the credential that could write to Linear. If the user revokes their session, every token in the chain is invalidated at once.

Agent attestation means the policy decision can include whether this request is actually coming from the agent it claims to be coming from, in an environment that hasn’t been modified. That’s a much more meaningful signal than “the agent has a valid token.” A leaked token from an attested agent is less useful to an attacker than a leaked token from an unattested one.

This is different from PDP/PEP at the access boundary in a few specific ways. The credential itself can’t exist if policy says no, so there’s nothing to leak, intercept, or revoke from a denied request. Sensitive operations can trigger a loop back through the authorization flow for step-up auth or human approval. This all happens before the credential is issued, instead of being blocked at access time after a credential already exists. The full authorization context is captured at the moment the credential is created. That delegation chain is not reconstructed later from logs.

You can compose this yourself. RFC 8693 token exchange with a policy engine, a workload identity provider, a federation layer, and an audit pipeline gets you most of the way. The tradeoff is the integration work and the joints between the pieces. This is a familiar build vs. buy scenario in auth: the integration is the hard part, and the seams are where the failures live.

Most developers building agents aren’t identity experts, don’t want to become identity experts, and most importantly: they shouldn’t need to. The layers of the agent security stack are all important. When you’re choosing solutions to secure the stack, the tool should stay out of your way while remaining fully auditable.

Questions for your next vendor demo

You’re back to the ten tabs. Here’s what you should ask of each one:

1. Which layers does this cover, and where are the seams? Both a Layer 1 tool and a Layer 2-and-3 tool can be useful. They’re solving different problems.
2. Is policy evaluated when the credential is issued, or when it’s used? This determines whether a denied request leaves any artifact that can be replayed, leaked, or misused.
3. Is this built inside a transport, or underneath one? Will it survive when the protocol surface changes again next quarter?
4. Does this work with one agent and many agents? Will the identity, policy, and audit story still work when your task crosses three agents calling four tools across two services? Does it still tell you who authorized what?

The agent security stack is still expanding rather than consolidating. Each layer’s surface area and failure modes are different. The useful question isn’t “which security product do I buy?” It’s “which layers do I need to cover, what am I composing, and how does it all fit together?”

If you’d like to dig into how Keycard unifies identity and access for agents, the docs explain the agentic access loop, authorization context, and the federation model in more depth. The agent taxonomy is still taking shape. To best prepare for what’s to come, secure multiple layers of the stack and stay protocol-agnostic.