The 2026 Agent Security Stack: Identity, Admission, and Execution

Algis Dumbris • 2026/04/19

Three Layers, Three Vendors, No Name

Something is crystallizing in the agent security landscape that nobody has said out loud yet. Three independent vendors — working on three separate problems, with three different architectures — are converging on a single stack. Not because they planned it. Because agent security has exactly three failure modes, and each company picked one.

The stack has no name. It has no consortium. It has no joint press release. But if you squint at the announcements from Q1 and Q2 2026, the shape is unmistakable: Identity at the base, Admission in the middle, Execution at the top. Ledger handles the first. MCPProxy handles the second. NemoClaw and Docker handle the third.

This post names the stack. And more importantly, it explains why each layer fails catastrophically without the other two.

Layer 1 — Identity: “Who Is This Agent?”

The bottom of the stack is identity and attestation. Ledger’s hardware-anchored agent identity system, entering public beta in Q2 2026, gives every AI agent a cryptographically verifiable identity using Ed25519 key pairs with on-chain provenance. The question this layer answers is deceptively simple: who is this agent, and can a human vouch for it?

This is not OAuth. OAuth tells you that a token was issued by an authorization server. It does not tell you whether the entity holding the token is the same agent that was originally authorized, whether that agent has been tampered with since deployment, or whether a human operator has reviewed and endorsed the agent’s current configuration. Ledger’s approach anchors identity to hardware, making agent impersonation a hardware-tampering problem rather than a credential-theft problem.

The open-standard version of this layer is the AMP protocol — Agent Messaging Protocol — which defines agent addresses in the format agent@tenant.provider.ai. AMP provides the addressing and routing layer that lets identity-verified agents find each other across organizational boundaries. Together, Ledger and AMP answer the question that every other layer depends on: is this agent who it claims to be?

Without this layer, the rest of the stack is theater. You can gate tool access and sandbox execution all you want, but if you cannot verify the identity of the caller, every policy decision is built on sand.

Layer 2 — Admission: “What Can This Agent Activate?”

The middle of the stack is admission control. This is where MCPProxy operates. The question here shifts from identity to authorization: which MCP servers can this agent activate, and has a human reviewed them?

MCPProxy enforces this through quarantine-by-default. Every new MCP server that appears in a developer’s environment starts in quarantine. It cannot serve tools to agents until a human operator explicitly reviews and approves it. This is the enforcement gate between identity-verified agents (Layer 1) and execution-ready tools (Layer 3).

The design is deliberately opinionated. In a world where shadow MCP servers proliferate through IDE plugins, npm packages, and configuration file injection, the only safe default is denial. MCPProxy maintains an allowlist of reviewed servers and routes agent tool calls only to those servers. Unreviewed servers exist in a holding pattern — visible, auditable, but inert.

Anthropic’s own managed agents architecture describes this same conceptual layer. Their documentation outlines a pattern where agent capabilities are mediated through a gateway that enforces organizational policies before any tool execution occurs. MCPProxy is the open-source implementation of that pattern, purpose-built for developer workstations where enterprise gateway solutions do not reach.

The admission layer also handles the practical mechanics of tool discovery. MCPProxy’s BM25-based tool search ensures that agents find the right tools from reviewed servers without requiring every tool to be loaded into the context window. This is not just a convenience feature — it is a security surface. An agent that cannot discover a tool cannot call it, making tool visibility itself an access control mechanism.

Layer 3 — Execution: “What Can This Agent Do Once Running?”

The top of the stack is execution containment. Once an agent has a verified identity and has been admitted to a set of approved tool servers, the final question is: what can it actually do inside those servers?

NemoClaw, built on the OpenClaw framework, provides an out-of-process policy engine that evaluates every tool call against a declarative policy before execution. The policy engine runs outside the agent’s process, which means the agent cannot modify or bypass the rules that govern it. This is a fundamental architectural choice — in-process policy enforcement is trivially defeated by any agent that can write to its own memory.

Docker provides the complementary kernel-level sandbox. MCPProxy’s Docker-per-server isolation spins up each MCP server in its own container with minimal privileges, read-only filesystems where possible, no network access unless explicitly granted, and resource limits that prevent a single server from consuming the host. If NemoClaw is the policy brain, Docker is the physical cage.

Together, they enforce the principle of minimal privilege at two different levels. NemoClaw decides whether a specific tool call is permitted by policy. Docker ensures that even if the policy is wrong — or the MCP server itself is compromised — the blast radius is contained to a single disposable container.

This layer without the others is a locked room with no door check. You have constrained what happens inside, but you have no control over who walks in or what tools they brought.

Why the Stack Matters: Independent Failure Modes

The reason this three-layer architecture is not optional — and not reducible to two layers — is that each layer fails independently and catastrophically without the others.

Identity without admission. You know exactly who is connecting. You have cryptographic proof that Agent X belongs to Organization Y and was deployed by Human Z. But you have no mechanism to prevent Agent X from activating an unreviewed MCP server that exfiltrates data through a tool call. Identity tells you who did it after the breach. It does not prevent the breach.

Admission without identity. You have a quarantine system. Every MCP server is reviewed before activation. But you cannot verify that the agent requesting tool access is the agent it claims to be. A compromised agent using stolen credentials passes every admission check. Your carefully curated allowlist becomes a menu for the attacker.

Execution without admission. You have sandboxed every MCP server in its own container with minimal privileges. But you have no gate preventing unauthorized servers from being instantiated in the first place. The sandbox constrains what runs, but shadow servers run happily inside their own sandboxes, exfiltrating data through perfectly contained, perfectly unauthorized tool calls.

Admission without execution. You have reviewed and approved every server. But approved servers running without containment can still be exploited. A vulnerability in a reviewed MCP server gives an attacker full host access. The admission layer verified the server was trustworthy at review time. It cannot guarantee the server remains trustworthy at runtime.

Each failure mode is real. Each has been demonstrated in the wild in the past six months. The stack is not a theoretical framework — it is a description of the minimum viable security posture for production agent deployments.

MCPProxy’s Position

MCPProxy occupies the admission layer — the middle of the stack — and it is the only open-source tool built specifically for this role on developer workstations. Enterprise gateways from PointGuard, Cisco, and ServiceNow address admission control for cloud-hosted agent fleets. But developers running Claude Code, Cursor, or Windsurf on their laptops are not behind an enterprise gateway. They are the unprotected surface.

MCPProxy’s quarantine-by-default model, BM25 tool discovery, and Docker-per-server isolation make it the natural integration point for the full stack. Ledger’s identity attestation feeds into MCPProxy’s admission decisions. MCPProxy’s approved server list feeds into NemoClaw’s policy engine and Docker’s container orchestration. The admission layer is the switchboard.

The stack has three layers. Three vendors are building them independently. And the layer that connects identity to execution — the gate that every agent must pass through — is open source, runs on your machine, and is available today.

Get started with MCPProxy and put the admission layer in place. The identity and execution layers are converging fast. The stack is assembling itself. The only question is whether your agents will be inside it or outside it.