Announcing Keycard for Multi-Agent Apps: Auth for Agentic Systems
Today, we’re excited to announce Keycard for Multi-Agent Apps: identity, access, and telemetry for developers building agents that collaborate with other agents, call external services, and connect to your APIs, without sacrificing security, capability, or autonomy.
Multi-agent systems are eating enterprise workflows. The patterns go in every direction: fan-out, peer-to-peer, chained across any number of clouds and trust boundaries. But they’re non-deterministic, and every hop of collaboration or tool calling is another chance for something to go wrong. Without access scoped to the task at each handoff, the gap between what an agent is doing and what it has access to only widens, and a single misstep anywhere in the chain can expose data, trigger unintended actions, or break the entire workflow.
Keycard fixes this by scoping what an agent can access to the task at hand and who they’re working on behalf of, issuing ephemeral, identity-bound credentials at every hop. The SDKs for TypeScript and Python let you add scoped auth to anything you’re building, with out-of-the-box support for LangChain, MCP, A2A, or any API. You don’t need to be an identity or security expert, Keycard takes care of that so you can focus on what your agents actually do.
Agents built with Keycard establish identity directly from their runtime environment. The SDKs handle the full credential lifecycle, issuance, storage, rotation, and revocation, so you can deploy to Vercel, Cloudflare, Fly.io, AWS, GCP, or Azure with no secrets on disk, no credentials in databases, and no token lifecycles to manage.
The Problem: A Broken Paradigm
Service-to-service auth and user auth have been separate systems for as long as most of us have been building software, both designed for a world of static roles, deterministic software, and humans you trust. Everything is set once and left alone: credentials, access, sessions, identity validated once at the edge and trusted downstream. Agents break all of it.
In practice today, when one agent calls another to query Snowflake, either the calling agent passes down its own broad credentials or the downstream agent already has pre-existing access to the database. Nothing is scoped to the task, nothing expires with the session, and revoking a credential means revoking it for everything that depends on it. The stack has no way to bind access to the task, session, agent or human that may have initiated it.
It gets worse when agents span environments. An agent on a developer’s laptop calls an agent running in GCP that authenticates with a service account and queries Snowflake over OAuth. Another agent hits your internal API with an API key. How do you ensure access is scoped to the task across all of them? Each system has its own identity mechanism, but there’s nothing connecting them to each other, the task, or the user who asked.
Without that connection, secure multi-agent systems are impossible to build. Developers give agents broad access and lose control, lock them down and lose the upside, or try to build auth themselves and end up solving identity instead of building product. Agent capability is no longer the bottleneck, what’s missing now are the controls that enable their adoption.
Introducing Keycard for Multi-Agent Apps
The answer is delegation: the ability to scope access across applications, users, and agents, and have that hold across many hops. Keycard for Multi-Agent Apps unlocks this with a single model where user-to-agent, agent-to-agent, and agent-to-application auth all work the same way, with policy evaluated at every hop. Developers don’t need to become identity or protocol experts, Keycard handles that. The result is that agents can finally be controlled without being constrained, natively at the protocol and application layer, not through gateways or middleware bolted on after the fact.
When a user or agent initiates a task, Keycard creates a session tied to the originating request. As agents hand off to other agents or call applications, Keycard issues scoped credentials using OAuth 2.0 Token Exchange (RFC 8693), ensuring permissions are narrowed and tied to the delegated identities. Credentials are held in memory, never touch disk, and expire when the session closes.
That single model covers every interaction in the chain:
User to agent. Common harnesses like Claude Code, Claude Cowork, Codex, OpenClaw, and ChatGPT, or any modern application, can interact with any agent built using Keycard. No additional integration required, it works through standard OAuth 2.1.
Agent to agent. Client ID Metadata Documents establish public identities for agents, enabling any agent to discover and authenticate any other agent without requiring you to manage client IDs and secrets for each relationship. For agents built using Keycard, workload attestation lets them assume an identity directly from their runtime environment.
Agent to application. Keycard models each application and how to provision credentials for it, with built-in support for federation and brokering. This is how your agents connect to Snowflake, Salesforce, Google Drive, AWS, GCP, or any service, directly.
Agent to legacy systems. For systems that don’t support modern auth, Keycard’s gateway exchanges opaque, session-bound credentials for real ones at the boundary, across any supported wire protocol (Postgres, Kafka, HTTP, and more), so agents never have direct access to long-lived secrets.
Across all of these, every action in the chain is captured as real-time telemetry with full identity context: which agent did what, on whose behalf, with what permissions, and whether the request succeeded or failed. That makes it easy to debug why a workflow broke or for security to understand why an action was approved or denied, and using that data they can detect malicious activity, revoke access, and update policy.
Example: Sara’s Churn Analysis
Sara’s customer success team has built three specialized agents as MCP servers: one for product analytics (Snowflake), one for customer health (HubSpot), and one for churn prediction. Together they form a single workflow that Sara runs through Claude Cowork.
None of the servers have standing access to anything. When Sara starts a session, Cowork delegates to each server on her behalf, and each one only gets the scopes her session allows. Policy evaluates the full chain at every hop: Sara, through Cowork, to a specific server, for a specific resource. If any link isn’t authorized, the request is denied.
Policy also ensures each server stays in its lane. Snowflake access can never be delegated to the customer health server, and HubSpot access can never be delegated to the product analytics server, so even a misconfigured orchestrator can’t widen the blast radius. Across the entire chain, no agent can perform a delete operation, ensuring an entire class of hallucinations simply cannot exist. All of it expressed in Cedar policy.
Build With Keycard
Adding delegated auth takes a few lines of code. The SDKs for TypeScript and Python handle the full credential lifecycle, bootstrapped using workload identity with no per-environment configuration and zero long-lived secrets to manage:
from fastmcp import Context, FastMCP
from keycardai.fastmcp import AccessContext, AuthProvider
auth_provider = AuthProvider()
mcp = FastMCP("Churn Analytics Server", auth=auth_provider.get_remote_auth_provider())
@mcp.tool()
@auth_provider.grant("snowflake://acme.snowflakecomputing.com")
async def get_churn_data(ctx: Context) -> dict:
access_context: AccessContext = await ctx.get_state("keycardai")
credential = access_context.access("snowflake://acme.snowflakecomputing.com")
return await query(credential.access_token, "SELECT * FROM churn")Run on Vercel, Cloudflare, Fly.io, Modal, AWS, GCP, or Azure out of the box without any API keys.
Get Early Access
Keycard for Multi-Agent Apps is built on the same platform that powers Keycard for Coding Agents. If you’re already using Keycard for Coding Agents, your agents can build new agents and tools with delegation built in from day one.
Drop in the SDK and deploy your first agent.
- Quickstart → Install, open your first session, issue a scoped grant.
- Federation → Anchor the chain at hop zero on Vercel, Fly.io, Modal, AWS EKS, GCP GKE, or Azure.
- Agent authentication → Stand up an autonomous agent, deploy it, and collaborate using A2A.
- MCP integration → Wrap MCP tool calls in the delegation chain.
Sessions defined auth for web apps. IAM defined it for the cloud. For agents, it’s delegated cross-app auth.
