Skip to content
API Reference
Start here

What is Keycard

Keycard provides authentication and access control for agents and the tools they use.

  • Authentication: who is asking? People sign in through your identity provider, and each agent, tool, and worker has an identity of its own.
  • Authorization: may they? Each step is checked against your policy: may this User, through an agent, reach your tool? May your tool reach the next service for them?

Agents act for people in GitHub, Google, Linear, and your own APIs, sometimes after they’ve stepped away. Instead of access fixed up front and rebuilt in every agent and tool, Keycard checks each request against your policy, outside the agent, where no prompt can change it.

With Keycard, you can:

In Keycard, people are Users; agents, tools, and workers are Applications; and what they reach is a Resource. Your MCP server is both: a Resource to the agent that calls it, and an Application when it calls GitHub.

Agents such as Claude Code, Cursor, your own agents, or any MCP client reach the services they use, such as GitHub, Jira, Confluence, Linear, Google Drive, and Gmail, and your own MCP servers and APIs. Access is enforced in one of three places: the Keycard CLI, the MCP Gateway, or your server with the Keycard SDK. Each of those asks Keycard, which sits beneath them, not on the request path. Keycard brings together identity, policy, credentials, and the Audit Log. For each request, Keycard checks who the User is and which Application is asking, then your policy. It answers the enforcement point with a credential, or refuses, and records the decision in the Audit Log. The Keycard CLI runs around a coding harness, such as Claude Code or Cursor, and supplies its credentials for the session. Only the MCP Gateway sits on the request path, and it checks each tool call. With the SDK, your server, not the agent, gets the upstream credential. People sign in to Keycard through your identity provider: Okta, Microsoft Entra ID, Auth0, Google, or any OIDC provider.

Each decision answers three questions: who the User is, which Application is asking, and whether your policy allows it. A request can also act for a User who has stepped away, when your policy allows it, or for no User at all. Every decision lands in the Audit Log.

How each check works

Who is the User? Users sign in through your identity provider, and the token your server receives names them. A request can act for the signed-in User, for a User who authorized a service earlier and isn’t present, or for no User when an agent or worker acts on its own.

Which Application is asking? Each agent, tool, and worker is an Application. MCP clients such as Claude Code can register themselves when a User connects: Keycard records which client asked on each token and has the User approve it each session, since a self-registered client can’t prove who it is. Your own tools and workers authenticate with a credential you configure or, once deployed, with their runtime’s workload identity, so no secret ships with the code.

Does your policy allow it? Keycard evaluates your Cedar policies before it issues a token and again before it supplies a credential: may this User reach that Resource, and may this Application act for them? Out of the box, every signed-in User reaches every Resource and any Application the User approved can act for them; acting for a User who isn’t present takes a policy. Through a Gateway, Keycard also checks each tool call.

What Keycard hands out depends on the service: the User’s OAuth token, a Keycard-signed token for your own API, or a key from Keycard Vault. Register GitHub once as a Resource and every tool reuses it, with no second OAuth app. To change who can do what, you change your policy, not any agent’s or tool’s code.