Comparison · agent governance · Keycard

Keycard, measured.

Keycard gives agents their own identity and hands them short-lived, task-scoped credentials instead of static keys, with a Cedar policy evaluated before anything is issued. This page scores that architecture across 16 capabilities against the same capabilities in Agen.co, with the sources, the scoring ladder, the five rows that come out level and the one Keycard wins all on the page.

Talk to usJump to the comparison

The short answer

  • This is a real policy engine, not a login. Cedar policies, default-deny, an explicit permit required for the user, the application and the resource on every request, with group membership resolved at evaluation time rather than cached. Policy scope is a level row and it deserves to be.
  • Five of sixteen rows come out level, which is the most we publish against anyone. Policy scope, delegated access, MCP tool governance, deployment model and time to a first governed agent. Two of those are ones we usually win.
  • They take ecosystem breadth. SDKs, a Terraform provider, and integration guides spanning coding agents, MCP servers and third-party APIs, against our deliberately focused platform. That row is a 2 for us on every comparison we publish, including this one.
  • The decision is made about a credential, not about the action. A permit issues a short-lived, task-scoped credential; the write, the export or the delete happens afterwards, made by the agent with that credential in hand. That is a real verdict, earlier in the sequence than a session grant and later than the thing an auditor asks about.
  • Policy is written about principals that enrolled. Agents are integrated by SDK, CLI or MCP into a zone. An agent already holding a static key never asks for a credential, so no policy runs and no record is written — which is the population agent governance is usually bought to find.
  • The meter is the transaction. Users, agents and apps are unlimited on every plan and billing counts credential issuance, validation, exchange and step-up approvals. Agen is priced per governed agent, so the bill tracks the thing you are governing rather than how chatty it is.
The long read

The credential is not the action.

Keycard moved the access decision off the session and onto the credential, which is a real advance over an OAuth handshake that grants a scope and then goes quiet. It is worth being precise about what that buys, because it buys a great deal — and about the one step it stops short of.

What the product actually is

Worth stating plainly, because the category name attracts products that are much less than this one. Keycard is a control plane that issues credentials to agents, and every issuance is a policy decision.

  • Principals, not service accountsusers, applications and agents are all first-class principals inside a zone — a self-contained trust domain that authenticates them and authorises access to the resources within it. An agent can be given its own identity, or act on behalf of a user who delegated to it.
  • Cedar, default-denypolicies are written in a declarative authorisation language that describes who can do what under which conditions, with no loops and no side effects. Every authorisation request needs an explicit permit for the user, the application and the resource. Group membership resolves during evaluation rather than from a cached claim.
  • Short-lived, task-scoped credentialsthe output of a permit is not a session but a credential bound to the task at hand, least-privilege and short-lived. Static secrets come out of the picture — there are guides for running applications and deploying services without them at all.
  • A wide integration surfaceSDKs, a CLI that governs coding agents by virtualising their environment and MCP configuration, OAuth for custom MCP servers, Terraform, and guides reaching GitHub, Google, Slack, Snowflake and cloud providers. This is a product developers can actually adopt on a Tuesday.

Where Keycard is strongest

One of the sixteen rows below goes to Keycard and five more are level — the most level rows we publish against any competitor. They follow from a real difference in where each product places itself: theirs is at the point access is granted, ours is at the point the action is taken.

  • Ecosystem breadththis row goes to them and it is earned. SDKs, a Terraform provider and a catalogue of integration guides covering coding agents, custom MCP servers, cloud platforms and third-party APIs — a developer can wire an agent to a governed credential without talking to anyone. We are a focused platform rather than a marketplace presence, and that row is a 2 for us on every comparison we publish.
  • Policy scope, levelCedar is a serious choice. Rules can be written about the user, the application acting, the resource being reached, the delegation in play and — on the enterprise tier — the device. Constrained by design so a policy can be reasoned about rather than merely executed. That row is even, and we would rather print it than pad the table by leaving it out.
  • Delegation and MCP, levelan agent can act on behalf of a user who delegated to it, including one who is not present, and tool calls through MCP are governed per call rather than per connection. Both of those are rows we win against most of the field. Here they are ties, and the reason is that Keycard is built on the same premise we are: an agent is a principal, and what it does on someone's behalf is a question with an answer.
  • Deployment and time to value, leveldedicated, bring-your-own-cloud and on-premise deployment with customer-managed keys and private networking, which matters for residency; and a free tier plus a CLI quickstart, so the first governed agent is minutes of work rather than a procurement cycle. Both even.

A permit is a decision about access

The sequence is worth walking through slowly, because the difference lives inside it and it is easy to skate over. An agent needs to reach a system. It asks the control plane. Policy evaluates the user, the application and the resource, and permits. A short-lived credential is issued, scoped to that task. The agent then uses the credential against the system.

That last step is the one worth sitting with. It happens after the decision, and it is performed by the agent. The verdict was rendered against a description of what was being asked for; the thing that actually reaches the system is whatever the agent does while holding the credential. For agents integrated through MCP the two collapse close together, which is why tool governance ties — a credential per tool call is very nearly a verdict per action, and the table scores it that way.

Elsewhere they separate. A credential scoped to a database or a cloud API is spent on statements and calls the control plane never sees, and the difference between reading one customer record and reading the table is not a difference the issuing decision was asked about. Nothing has failed here — the credential is doing exactly what least privilege intends. But the question an auditor asks is about the write that landed, and that question is answered by the resource's own logs rather than by a verdict.

Agen renders the verdict on the action itself, in under 30ms, with five verdict types rather than permit and deny: allow, step-up authentication, human approval, masking, and deny. Masking is the one that shows the difference most cleanly, because it is a verdict that can only be reached with the payload in view. It is a 1 on the other column not as a shortfall but as a consequence: a product that hands over credentials is never holding the data.

Policy is written about principals that enrolled

The second consequence is a coverage one, and it is the sharper of the two. A Cedar policy names a user, an application and a resource. All three have to exist inside a zone for a rule to be written about them, which means an agent has to be integrated — by SDK, by the CLI wrapping its environment, or by an MCP server configured against the control plane — before it is governed at all.

For agents a platform team is building deliberately, that is a reasonable ask and a well-supported path. The difficulty is the population that motivates most agent governance purchases in the first place: the agents nobody filed. A script with a personal access token in an environment variable. A vendor tool with an API key pasted into a settings page. An assistant a business team connected to a system of record without asking. None of them asks for a credential, so no policy runs, no decision is recorded, and nothing appears in the inventory.

Agen discovers agents across five surfaces without anything being installed and without an agent enrolling itself — including agents built on someone else's stack and agents carrying no identity object of ours at all. Discovery is not a separate exercise from governance here; it is the reason governance has something to be about. That is what the two lowest rows in the coverage group are measuring, and it is one property, not two.

Who is accountable, and when it is decided

Attribution is genuinely good on the delegated path. Composite identity binds the user, the device, the agent and the task together, so a request carries who initiated it and on what machine, and every authorisation decision produces a log that can be streamed to a SIEM. For a coding agent a developer is driving, that is a clear chain and the table credits it.

The gap opens where an agent is given its own identity and acts with no user in the request — a documented and deliberately supported mode, and the one that autonomous work uses. Then the principal is a workload attested by its infrastructure. That is a fine answer to what is calling, and it is not an answer to who answers for it. The record shows a permitted application; it does not name a person.

Agen holds the accountable human as a durable property of the agent rather than of a request. Every agent has a named owner, and every individual action resolves back to that owner whether or not anyone was present when it ran. That object has to exist before the action, not be reconstructed from a log afterwards, which is why the attribution rows sit where they do.

What the meter counts

The commercial model is published and unusually clear. Users, agents and applications are unlimited on every plan; a transaction is recorded each time the platform issues a credential, validates an access request, exchanges a credential or handles a step-up approval. There is a free tier, a team plan at a fixed monthly price with a bundled allowance, and metered overage beyond it.

Unlimited agents is a real advantage over per-seat licensing, and the row is scored a 4 rather than a 2 for exactly that reason. The caveat is what the meter tracks. Cost follows how often agents ask for access, which is a function of how the agent was written — a chatty loop and a careful one governing the same system cost differently. It also means the governance bill and the governance question point at different objects: you are billed for exchanges and asked about agents.

Agen is priced per governed agent with no prerequisite tier. Our own platform-cost row is a 4 rather than a 5 and stays there: for a buyer already paying for an incumbent, we are net-new spend, and that caveat is what makes the 4 credible.

What is not published

Six of the forty-two rows we score were dropped rather than published. Decision latency is the notable one for a product sitting in the credential path: no vendor page publishes a figure, so the row does not score in either direction. Preservation of the authority chain across multiple agent-to-agent hops was dropped too — delegation is documented and scores a 5, but multi-hop chaining appears only in secondary summaries, and a row we would have to source that way is a row we do not print.

Two rows were dropped on fairness rather than evidence. Connector breadth would have set our curated count of governed connectors against a model that is deliberately bring-your-own — any OAuth or OIDC provider can be added — and the two numbers do not measure the same thing. New-integration turnaround was dropped for the mirror-image reason: nothing is published to compare our own commitment against.

One is ours, and one is a tie. Our audit-first rollout row is held pending internal confirmation and is not published on any comparison until it is. Platform cost comes out even at 4 and was left out only to hold the table at sixteen rows; the argument it carries is in the pricing section above, where it can be made properly.

The scored comparison

Sixteen capabilities, scored side by side.

Runtime enforcement, identity and accountability, coverage, and what it costs to operate — each scored 0–5 on capability depth against vendor documentation, including the five rows that come out level and the one Keycard wins.

Capability depthNoneCompleteKeycardAgen.co
01 · Runtime enforcement
Verdict rendered at the moment of actionKeycardVerdict at credential issuanceCapable3/5Agen.coPer-action verdicts, <30msComplete5/5
Masking or redaction at action timeKeycardCredentials, not data in flightBasic1/5Agen.coMasking at action timeComplete5/5
Human-in-the-loop approval on a risky actionKeycardApproval on credential requestsStrong4/5Agen.coHuman-in-the-loop, built inComplete5/5
Policy scope — what you can write a rule aboutKeycardCedar: user, app, resource, deviceComplete5/5Agen.coAny policy you writeComplete5/5
02 · Identity & accountability
A named human accountable for each agentKeycardComposite identity, or workload aloneCapable3/5Agen.coNamed owner, every agentComplete5/5
Each individual action attributed to that humanKeycardAttributed per access requestCapable3/5Agen.coAttributed per actionComplete5/5
Delegated (on-behalf-of) accessKeycardOn-behalf-of, absent users tooComplete5/5Agen.coOn-behalf-of, governedComplete5/5
Access evaluated at action time, not only at grant timeKeycardEvaluated at each token exchangeCapable3/5Agen.coJudged in context, per actionComplete5/5
03 · Coverage
Endpoint enforcementKeycardCLI on the developer machinePartial2/5Agen.coAgenShield on the deviceComplete5/5
Browser enforcementKeycardNo browser surface documentedBasic1/5Agen.coBrowserShield, early accessCapable3/5
Agents carrying no vendor identity objectKeycardRequires a Keycard identityBasic1/5Agen.coDiscovered, owned, governedComplete5/5
MCP tool governanceKeycardPolicy on every tool callComplete5/5Agen.coMCP tools governed per callComplete5/5
04 · Operate & buy
Pricing unit — what you are billed perKeycardPer transaction, not per agentStrong4/5Agen.coPer governed agentComplete5/5
Time to first governed agentKeycardFree tier, CLI quickstartComplete5/5Agen.coDays to a first governed agentComplete5/5
Deployment model and data residencyKeycardDedicated, BYOC, or on-premComplete5/5Agen.coSaaS, hybrid, or on-premComplete5/5
Ecosystem and marketplace breadthKeycardSDKs, Terraform, integration guidesCapable3/5Agen.coFocused platform, not a marketplacePartial2/5
10 rows Agen.co leads5 tied1 row Keycard leads
Levels reflect capability depth and supporting evidence. Capability descriptions based on vendor public documentation, September 2026.
What the table says

Both products decide before anything happens. They disagree about what is being decided.

Read the four groups in order and the shape is unusual for this site. Operate and buy is close, and three of its four rows are level or theirs. The identity group is closer than it is on any other comparison we publish — delegation ties outright, because a credential broker and a governance plane are reasoning about the same object. The separation arrives in two places, and it is one idea in both.

Access is granted to a principal that asked; an action is taken against a system. Deciding the first thing well, as this product does, still leaves the second thing to the agent and to the resource's own logs — and it leaves the agents that never asked outside the policy altogether. That is not a gap in feature scope. It is where the architecture draws its line, and it is the line the four lowest rows are measuring.

The findings

Four groups, four boundaries.

One per group in the table above, each traceable to the rows beneath it.

01

The verdict lands on the credential

Default-deny Cedar policy, evaluated before anything is issued, with human approval available on an access request — a real decision, and earlier than a session grant. What follows it is the agent using the credential, so a verdict that needs the payload in view is not available: redaction at the moment of action is the row that shows it.

decision pointissuance
verdict typespermit / deny
02

A workload is not a person

Composite identity binds user, device, agent and task, and on the delegated path the chain is clear and credited. Where an agent is given its own identity and runs with no user in the request — the supported mode for autonomous work — the principal is a workload attested by its infrastructure, and no named human is carried into the record.

delegated attributionstrong
accountable owner per agentnone
03

Governed means enrolled

Policy names principals inside a zone, so an agent is governed once it has been integrated by SDK, CLI or MCP. Thorough for agents a platform team builds on purpose, and silent for the ones nobody filed: an agent holding a static key never requests a credential, so no policy runs and nothing appears in the inventory.

integration requiredSDK / CLI / MCP
agentless discoveryno
04

Billed per transaction

Users, agents and apps are unlimited on every plan, which is a genuine advantage over per-seat licensing and is scored as one. The meter counts credential issuance, validation, exchange and step-up approvals — so the bill follows how often agents ask for access rather than how many of them you are governing.

pricing unitper transaction
agents includedunlimited
Watch it happen

Every access brokered and judged at the moment it happens.

Not a credential handed over and spent out of view — a verdict on the action itself, with human approval reaching the named owner in seconds and an audit chain that runs request, approval, action performed.

action brokering · live product scene
What closes the gap

Keep the credentials short-lived. Add the verdict on what they are spent on.

Nothing about issuing task-scoped credentials from a Cedar policy conflicts with governing the action itself. Agen adds what a credential cannot carry: every agent discovered without anything being installed and without enrolment, a named accountable human behind each one, and every action judged against your policy at the moment it happens — internal agents and the ones facing your customers, on the same plane.

Select a capability

Continuous discovery across your IdP, gateway, devices, cloud, and registries. Nothing has to self-register: agents are found, risk-scored, and resolved to a named human before they act.

  • Agentless and API-based across five surfaces
  • First-party, custom, and third-party agents alike
  • Every agent mapped to an owner, approver, and escalation
Agen Discover AI agent discovery flow: any identity provider, productivity suites and assistants, cloud, gateway, endpoints, and MCP server registries all feed one agent registry where every AI agent is inventoried, risk-scored on arrival, given a named human owner, and shadow AI is surfaced.
Discovery pulls from five surfaces into a single agent registry — no SDK self-registration required.
ClosesWhich agents are running that nobody registered?
no SDK required5 surfacesowner-mapped
Discover in depth →

Methodology

How these scores were reached.

Sixteen capabilities publish from a worksheet of forty-two scored rows, on one 0–5 ladder applied to both columns. Six rows were dropped rather than guessed: decision latency, because no vendor page publishes a figure in either direction; preservation of the authority chain across multiple agent-to-agent hops, because delegation is documented but multi-hop chaining appears only in secondary summaries; connector breadth, dropped on fairness because a bring-your-own-provider model and a curated connector count do not measure the same thing; new-integration turnaround, unpublished on the vendor side; our own audit-first rollout row, held pending internal confirmation; and platform cost, which ties at 4 and is argued in the long read instead of occupying a seventeenth row. Ties and the row Keycard wins are printed rather than filtered.

Sources7 primary
Evidence ledger
  1. Keycard — control plane for autonomous agentsTier AComposite identity resolution binds identity across user, device, agent and task. Policy is enforced at the gate, evaluated in real time before a credential is issued, and credentials are short-lived, least-privilege and bound to the task at hand. A CLI governs coding agents by virtualising their environment and MCP configuration, and telemetry streams in real time to destinations including Splunk and Datadog. Auto-approval of access requests is cited rising from 72% in the first week to over 94% by week twelve.
  2. Keycard DocsTier AEvery tool call gets a credential and every action gets a log. Integration is by CLI, by SDK, or through MCP and OAuth primitives. The admin surface covers SSO, roles, policies, audit and observability, with an audit trail of every authorisation decision and audit-log export. Credentials are scoped to one user, one agent and one action.
  3. Keycard Docs — policiesTier APolicies are authored in Cedar, described as intentionally constrained: policies describe who can do what under which conditions, without loops or side effects. Evaluation is default-deny — every authorisation request needs an explicit permit for the user, the application and the resource being accessed. A permit results in a credential being issued; a denied request receives none. Group membership is resolved dynamically during evaluation rather than statically cached, and the decision and resulting access are available for audit.
  4. Keycard — pricingTier BA transaction is recorded each time Keycard is involved in a request — issuing a credential, validating an access request, exchanging a credential, or handling a step-up approval. Starter is free with 5,000 transactions a month and unlimited users, agents and apps; Team is $500 a month including 100,000 transactions with additional transactions at $1 per 1,000. Enterprise adds organisation policy, device-based policy, SCIM, Active Directory and LDAP provisioning, dedicated, bring-your-own-cloud or on-premise deployment, private networking, customer-managed KMS, extended retention and a 99.95% uptime SLA. RBAC, ABAC and ReBAC are included from the free tier.
  5. Keycard Docs — providersTier AA zone is a self-contained trust domain that authenticates users and agents and authorises access to resources within the zone, and external providers can be added to a zone to establish trust with other domains. Identity providers connect over OpenID Connect and SAML, with Microsoft Entra, Okta, Google and Apple named; cloud service providers named include AWS, Azure, Google Cloud, Vercel and GitHub Actions. No connector count and no new-integration turnaround are published.
  6. Keycard Docs — usersTier AUsers are people who access protected resources, either directly or by delegating access to applications and agents that act on their behalf. Users, applications and agents are modelled as distinct principals, and an agent can be given its own identity and operate autonomously with no user in the request.
  7. Keycard Docs — guidesTier AGuides cover connecting Claude and Cursor to resources, controlling tool calls, accessing APIs on behalf of users, acting on behalf of absent users, running apps without static secrets, granting agent access to APIs, adding auth to a custom MCP server, calling external APIs from MCP, protecting an API, deploying without secrets, accessing Snowflake and building a Slack agent, with Cedar policy, OAuth, OIDC and Terraform named throughout.

Vendor capabilities change. If a row is out of date or wrong, tell us and we will re-score it — corrections are published with the date they were made.

FAQ

Questions, answered.

What is Keycard?
It is an identity and access platform for AI agents. Users, applications and agents are first-class principals inside a zone — a self-contained trust domain — and access is granted by evaluating a default-deny Cedar policy that requires an explicit permit for the user, the application and the resource. A permit issues a short-lived, least-privilege credential scoped to the task rather than a long-lived key or an open session. It is adopted through SDKs, a CLI that governs coding agents by virtualising their environment and MCP configuration, and OAuth integration for MCP servers.
Where does Keycard score better than or level with Agen.co?
One row of sixteen goes to Keycard outright and five more are level, which is the most level rows we publish against any competitor. Ecosystem breadth is theirs: SDKs, a Terraform provider and integration guides spanning coding agents, custom MCP servers, cloud platforms and third-party APIs, against our deliberately focused platform, a row we score a 2 on everywhere. Level with us on policy scope, on delegated on-behalf-of access, on MCP tool governance, on deployment model and data residency, and on time to a first governed agent.
Does Keycard enforce policy at runtime?
It renders a real decision, and where it sits is worth being exact about. Policy is evaluated every time a credential is requested, issued, validated or exchanged — not once at login — and for agents integrated through MCP that is effectively per tool call, which is why MCP tool governance is scored level. The distinction the table carries is that the verdict is about the access being requested rather than about the action performed afterwards with the credential in hand. A credential scoped to a database is spent on statements the control plane does not adjudicate.
How does Keycard identify the human behind an agent?
On the delegated path, well. Composite identity binds the user, the device, the agent and the task, so a request carries who initiated it, and every authorisation decision is logged and exportable. The gap opens in the mode autonomous work uses: an agent can be given its own identity and act with no user in the request, attested as a workload by its infrastructure. That identifies what is calling rather than who answers for it, which is why the accountability rows are scored a 3 rather than a 1 or a 5.
What happens to agents that were never integrated with Keycard?
They are outside the policy. Cedar rules name a user, an application and a resource, and all three have to exist inside a zone, so an agent has to be integrated by SDK, by the CLI, or through an MCP server before any rule applies to it. An agent already holding a static key or a personal access token never requests a credential, so no policy is evaluated, no decision is logged, and it does not appear in the inventory. Agen discovers agents across five surfaces with nothing installed and no self-registration, including agents built on another stack and agents carrying no identity object of ours.
How is Keycard priced?
Per transaction, with users, agents and applications unlimited on every plan. A transaction is recorded each time the platform issues a credential, validates an access request, exchanges a credential or handles a step-up approval. There is a free starter tier with a monthly allowance, a team plan at a fixed monthly price with a larger bundled allowance, and metered overage beyond it; enterprise adds organisation and device-based policy, directory provisioning, dedicated, bring-your-own-cloud or on-premise deployment, customer-managed keys and an uptime SLA. Agen is priced per governed agent with no prerequisite tier, so the bill tracks the population being governed rather than how often it asks.
Can Agen.co run alongside Keycard?
Yes, and the two sit at different points in the same sequence, so it is a natural shape. Keycard keeps doing what it is good at: no static secrets, short-lived credentials scoped to a task, a Cedar policy deciding what an agent may be given. Agen governs what happens next — every agent discovered without anything being installed, a named accountable human behind each one, and every action judged against your policy in under 30ms with five verdict types including step-up authentication, human approval and masking. Nothing you already run has to be removed.
What is the difference between granting access and governing an action?
Granting access answers what an agent may be given; governing an action answers whether the specific thing it just did was permitted. The first decision is made about a request and produces a credential. The second is made about a write, an export or a delete, at the moment it is attempted, and can depend on things only the action knows — what is in the payload, how much of it there is, who is accountable, whether a person should approve it first. The two collapse together for a single scoped tool call and separate as soon as a credential is broad enough to be spent more than one way.

See the row that decides it.

Bring the agent you are least comfortable with — ideally one nobody filed, running with a key in an environment variable. We will show you that it exists, who answers for it, and a verdict on the next action it takes, in a working environment, in under a day.

Talk to usSee the platform