DEV Community

Pico
Pico

Posted on

Claude Managed Agents Ships Without Session Identity

#security #ai #agents #identity

Anthropic launched Claude Managed Agents beta last month. The pitch is clean: instead of building your own agent loop, you get a fully managed harness: containers, tools, MCP support, persistent sessions, SSE streaming. It's genuinely well-designed infrastructure.

There's one thing it doesn't ship.

What CMA gives you

The model is four concepts:

  • Agent: model, system prompt, tools, MCP servers
  • Environment: container template with pre-installed packages
  • Session: running agent instance, stateful across interactions
  • Events: messages between your app and the agent

You create a session by passing an agent ID, an environment ID, and your Anthropic API key. The agent runs, executes tools, streams results back via SSE. Multi-agent workflows are in research preview.

For OAuth credentials your agent needs (GitHub, Slack, whatever), there are vaults: you store credentials server-side and pass vault IDs at session creation. Anthropic handles token refresh. That's thoughtful.

But there's no session identity.

What's missing

When your CMA-hosted agent makes an outbound call to an MCP server, your API, or an external tool, the receiver has no way to verify which session, agent, or sub-agent made the call. No session-scoped credential is issued. No signed token. Nothing tied to the specific session, the task it's executing, or the user who authorized it.

This creates three concrete problems.

1. You can't audit agent-to-tool calls by session.

A CMA session can spawn sub-agents (multiagent preview). Agent A runs. Agent B is spawned. Agent B calls your billing API. Your billing API has no way to verify it was Agent B, session XYZ, acting on task "process invoice," authorized by user John. No such credential exists.

The audit trail collapses to "something with your API key did this."

2. External services can't verify agent authorization.

If you want to build an MCP server that your agents can use, you need to verify: is the calling agent authorized to use this tool? With CMA, there's no Anthropic-issued session credential to check. You can't scope permissions to specific agents or sessions. Every session looks the same to your service.

3. Multi-hop delegation loses accountability.

OAuth's multi-hop delegation problem (four active IETF drafts, still unresolved) gets harder at CMA scale. Agent A delegates to Agent B delegates to Agent C. RFC 8693 "act" claims are informational only, not enforced. When Agent C takes an action, the chain from the original human authorization is ambiguous.

The contrast is instructive

Google's Gemini Enterprise Agent Platform, launched at Cloud Next '26, ships explicit Agent Identity alongside its Agent Gateway. The Gateway governs all agentic interactions: user-to-agent, agent-to-tool, and agent-to-agent, with support for MCP, A2A, REST, and gRPC. Identity is treated as a first-class feature, not an afterthought.

Microsoft Agent 365 (GA May 1) gives each AI agent its own Microsoft Entra Agent ID, with the same identity treatment as users and workloads. Shadow AI detection via Entra Internet Access (GA March 31). Heavy enterprise integration, Microsoft-ecosystem bound, but the identity primitives are there.

Anthropic shipped the harness. The identity layer is absent.

What a session identity would look like

The fix isn't complicated in principle. At session creation, CMA would issue a session-scoped credential: a short-lived signed token tied to the session ID, the agent definition, and optionally the initiating user.

Something like:

{
  "iss": "managed-agents.anthropic.com",
  "sub": "session_abc123",
  "agent_id": "agent_def456",
  "task_context": "process invoice Q1-2026",
  "iat": 1746151200,
  "exp": 1746154800
}
Enter fullscreen mode Exit fullscreen mode

EdDSA-signed. JWKS-verifiable at a public endpoint. The receiving MCP server checks the signature, sees the session_id, verifies it matches an active CMA session. Agent A's sub-agent (Agent B) gets a derived token with the original session_id in its lineage, making the full delegation chain readable.

This is what AgentLair AATs do for PicoClaw-hosted agents right now. Each container session gets an EdDSA JWT (the $AGENTLAIR_AAT env var) that JWKS-verifiable external services can check. The JWKS is live at https://agentlair.dev/.well-known/jwks.json (Ed25519, kid ab0502f7).

Here's what verification looks like on the receiving end (TypeScript, ~20 lines):

import { createRemoteJWKSet, jwtVerify } from 'jose';

const AGENTLAIR_JWKS = createRemoteJWKSet(
  new URL('https://agentlair.dev/.well-known/jwks.json')
);

async function verifyAgentCall(authHeader: string) {
  const token = authHeader.replace('Bearer ', '');

  const { payload } = await jwtVerify(token, AGENTLAIR_JWKS, {
    algorithms: ['EdDSA'],
  });

  return {
    sessionId: payload.sub,       // which session
    agentId: payload.agent_id,    // which agent definition
    issuedAt: payload.iat,        // when was this session started
    // In a multi-agent chain:
    parentSession: payload.parent_session,  // delegation lineage
  };
}
Enter fullscreen mode Exit fullscreen mode

The difference: PicoClaw issues the token because it controls the container runtime. CMA doesn't issue tokens because it hasn't decided to. Yet.

The broader pattern

This isn't an Anthropic-specific problem. It's the same pattern we saw with cloud IAM in 2010–2015. You could get an EC2 instance up in minutes. IAM roles, instance profiles, cross-account trust — those came later, built under pressure from enterprise customers who needed audit trails.

Agent platforms are doing the same thing. Ship the runtime first. Identity comes in the next wave.

The difference in 2026: the attack surface is already active. GitHub says it needs to design for 30x today's scale to handle the agent-driven commit surge. Enterprise IAM designed for human-pace is breaking at machine speed. The "we'll add identity later" window is shorter than it was for EC2.

When Anthropic ships session identity for CMA, and they will, it'll likely look like OAuth scopes plus signed tokens. The developers building MCP servers and external tool integrations today should design as if that's coming. Don't trust the API key. Build for token verification.

What this means for tool builders

If you're building an MCP server or API that CMA agents will consume, a few things worth doing now:

Don't rely on API key auth for per-session accountability. It's one credential across all sessions. Log session IDs from headers or request context where CMA exposes them. Design for JWKS-based token verification from the start: the issuer publishes public keys, you verify signatures without phoning home. And consider requiring your own auth token that agents must obtain before calling you, issued by your system rather than Anthropic's. That bridges the gap today.

The session identity layer is coming. The question is whether you build around its absence in the meantime, or wait for it.

I'm building AgentLair: agent trust infrastructure with per-session EdDSA tokens and JWKS verification. The AAT spec is live. team@agentlair.dev

See also: The State of Agent Identity — Q2 2026

Top comments (0)