KeycardLabs launches Keycard for multi-agent apps with token exchange and Cedar policy

• KeycardLabs' launch thread frames the core problem as multi-agent apps passing broad shared credentials between agents, with no task scoping, no session expiry, and weak auditability.
• According to KeycardLabs' delegation overview, Keycard creates a session at task start, then uses token exchange to issue narrower credentials at each handoff, with credentials expiring when the session closes.
• In KeycardLabs' churn-analysis example, the company says Cedar policy can stop Snowflake access from being re-delegated to a HubSpot-connected server and can block destructive actions like deletes across the whole chain.
• KeycardLabs' integration post says the SDKs cover TypeScript and Python, and work with LangChain, MCP, A2A, and generic APIs, while KeycardLabs' deployment post adds support for Vercel, Cloudflare, Fly.io, AWS, GCP, and Azure.

You can jump to the full write-up with code examples, inspect the three-server churn scenario, and skim KeycardLabs' security stack taxonomy that puts credential brokers next to MCP gateways and runtime guardrails. There is also an a16z demo day post showing KeycardLabs pitching alongside other AI security startups next week in San Francisco.

The product pitch is narrow and useful: agent chains need delegated auth, not another long-lived secret store. In the launch thread, KeycardLabs says today's pattern often passes the same Snowflake credentials from one agent to the next, which leaves permissions too broad and attribution too fuzzy.

Keycard's answer is session-scoped delegation. A task opens a session, each agent hop exchanges its current credential for a more limited one, and the chain dies with the session instead of leaving reusable tokens behind, according to KeycardLabs' delegation overview.

The clearest example is a churn-analysis workflow with three MCP servers:

• product analytics, with Snowflake access
• customer health, with HubSpot access
• churn prediction, with no external access

In KeycardLabs' example, Cedar policy expresses two concrete constraints that matter more than the architecture diagram: Snowflake access cannot be delegated into the customer-health server, and no agent in the chain can issue a delete.

That makes the launch feel closer to policy enforcement for agent handoffs than to a generic auth wrapper.

The company says the same auth model spans user-to-agent, agent-to-agent, agent-to-application, and agent-to-legacy-system calls through its gateway, per KeycardLabs' integration post. The implementation claim is deliberately lightweight: a few lines of code in TypeScript or Python SDKs, with LangChain, MCP, A2A, and plain APIs supported out of the box.

The runtime story is equally specific. In KeycardLabs' deployment post, the company says agents can establish identity from their runtime environment on Vercel, Cloudflare, Fly.io, AWS, GCP, or Azure, with no secrets on disk, no credentials stored in databases, and no token lifecycle plumbing left to the app team.

A day before the launch, KeycardLabs' security stack taxonomy split the agent-security market into five buckets: MCP gateways, policy engines, runtime guardrails, credential brokers, and non-human-identity inventory tools. That post is a small but revealing setup for this launch, because Keycard is being positioned specifically as the credential-broker layer rather than the whole stack.

The follow-up context is commercial, not technical. KeycardLabs' a16z demo day post says the company will demo at an a16z Security & AI event on May 21 alongside Socket, Cotool, Cygnvs, and Doppel, which is a decent snapshot of the security neighborhood Keycard wants to occupy.