The Agent Security Stack: Transport, Identity, Policy, Runtime — Keycard Skip to content Copy logo SVG Download logos<br>Menu

Kim Maida Developers

12m read<br>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...