Use Cases

Each page here starts from a problem rather than a feature. Find the one that matches what you are trying to do, read what the solution looks like, then follow the link into the guide that builds it. New to Keycard? Start with the Quickstart, then What is Keycard.

The question that separates these cases is whose authority the agent carries when it reaches a system, and whether that person is present.

flowchart TD
    A[An agent needs to reach a system] --> B{Acting for a person?}
    B -->|Yes, and they are present| C[Act as the user who asked]
    B -->|Yes, several people, different reach| D[Same agent, different user]
    B -->|Yes, but nobody is present| E[Act for an absent user]
    B -->|No, it acts as itself| F[Give an agent its own identity]
    G{Or limiting an agent you already run?} -->|It reaches an MCP server| I[Allow one tool, deny the next]
    G -->|It runs on a developer machine| J[Govern a coding agent]
    K[Something needs to stop] --> L[Revoke once, access stops]

Act for an absent user has no page of its own yet. The Act on Behalf of Absent Users guide builds it: the person authorizes once, and a job later runs as them with nobody signed in.

Start with Act as the user who asked if you are evaluating Keycard for the first time. It is the shortest path to seeing per-user attribution work end to end, and most of the other patterns build on it.

I want to	Use case	What it covers	Build it	Effort
Let an agent reach a system as the person who asked, so the log names that person	Act as the user who asked	Federating your identity provider, token exchange per request, per-user attribution in audit	Act on behalf of users	Start here
Have one agent give different people different reach, driven by the groups in my directory	Same agent, different user	Group claims in policy, what an unmatched request gets under the managed defaults, and where the snapshot boundary sits	Access Snowflake	Builds on the first
Let a service authenticate without a secret in its configuration	Give an agent its own identity	Workload identity as an issuer and a subject, and what the runtime has to be able to prove	Authenticate deployed workloads	Independent
Withdraw access in one place and show a reviewer that it stopped	Revoke once, access stops	What revocation reaches, what it does not, and how both sides appear in the log	Revoke access	Read with any of the above
Permit an agent one tool on an MCP server and refuse the adjacent one	Allow one tool, deny the next	Policy on the individual tool at the gateway, and why refusal beats restraint	Allow or deny specific tools	Needs a gateway
Stop a coding agent on a laptop using the developer’s own production access	Govern a coding agent	Scoped, short-lived credentials in a recorded session, and where a local guardrail ends	Connect coding agents	Per developer machine

Every page carries a Common questions section answering what a security reviewer asks, so the page a builder reads to understand the pattern is the same page a reviewer can be sent.

A use-case page explains the problem, the shape of the solution, and what you end up with. It carries diagrams and configuration, no application code and no terminal commands.

A guide builds the thing. It carries prerequisites, a walkthrough, code in Python, TypeScript, and Go, and troubleshooting.

Read the use case to decide whether a pattern fits. Follow the guide to implement it.