Compare · Obelisk vs Keycard

Obelisk vs Keycard

Looking for a Keycard alternative? Here's an honest, side-by-side comparison of Obelisk and Keycard — what each does best, where they differ, and where Obelisk falls short. Keycard is runtime auth for agents: it gives each agent its own identity, authority to act, and access to resources under your policy.

Obelisk vs Keycard, honestly

Keycard is runtime auth for agents: it gives each agent its own identity, authority to act, and access to resources under your policy. (source, checked 2026-10-02) Obelisk is a passkey-first identity and security plane built around one idea: security you can prove, not just promise. This page compares the two fairly — Keycard is a genuinely good product for teams that want policy-checked, short-lived credentials for agents on top of the identity provider they already run, and we say so plainly below.

The short version: if your agents need tokens of their own today, Keycard issues them and Obelisk does not (see the table). Obelisk's distinct piece is the record: agent lifecycle events go to a hash-chained ledger whose inclusion proofs need no account to fetch, and an agent can publish a Proof Link that anyone can read. See the full field →

Where Keycard shines

Each request is evaluated against policy at runtime: an approved one gets a short-lived token scoped to the task, and a denied one creates no credentials but is logged. (source, checked 2026-10-02) Policy is written in Cedar and managed through Terraform, and Keycard adds policy and token issuance on top of the identity provider you already run instead of replacing it. (source, checked 2026-10-02) Its site lists a SOC 2 Type II attestation. (source, checked 2026-10-02)

Side-by-side: Obelisk vs Keycard

Obelisk's column says what Obelisk does today, including what it does not do. Every Keycard cell is drawn from the page it links, checked on the date shown; vendor capabilities change, so verify the latest from their docs.

DimensionObeliskKeycard
Agent as an identityEach agent is its own record in Agent Studio: its own key, held by the agent's runtime (Obelisk never receives the private key), a passkey-holding owner, and an opt-in public Proof Link that is opaque and revocable.Each agent gets its own identity, and Keycard verifies the agent making the request and where it runs. (source, checked 2026-10-02)
Tokens issued to an agentNo grant issues a token to an agent on its own: the token endpoint grants only authorization_code and refresh_token. There is no client-credentials, token-exchange or ID-JAG grant.Yes: after a policy check, a short-lived authorization token scoped to the task at hand. (source, checked 2026-10-02)
Access policy for agentsAPI keys bound to an agent carry a fixed capability and scope. No runtime policy engine evaluates an agent's requests.Cedar policy as code, managed with Terraform and evaluated on each request. (source, checked 2026-10-02)
Relationship to your identity providerObelisk is the identity provider: an OpenID Connect provider and a SAML 2.0 IdP that your apps sign in with.Sits on top of the identity provider you already run and adds policy and token issuance. (source, checked 2026-10-02)
RevocationOwners rename agents, rotate their keys, transfer them and revoke them. Revoking an agent also revokes the agents it delegated to and kills their bound keys.Revoke a credential instantly, and later events are denied wherever it applies. (source, checked 2026-10-02)
Third-party check of agent authorizationRegistering, approving, transferring or revoking an agent writes a receipt to Obelisk's hash-chained ledger. Anyone holding a receipt's hash can fetch its position in the chain and a Merkle inclusion proof at /api/proof/<hash>, with no account.Every authorization event, denials included, carries full attribution and exports to your SIEM or an S3 bucket. The cited page describes no proof a third party could check without Keycard. (source, checked 2026-10-02)

Why teams choose Obelisk

The differences below aren't cosmetic — they're structural choices that move security from "trust us" to "verify it."

  • Agent identities with public Proof Links. Agents enroll with their own runtime-held key (Obelisk never receives it), a passkey-holding owner stays accountable, and anyone can inspect the bounded live evidence at an opaque, revocable proof link. Reading a Proof Link needs no Obelisk account.
  • Tamper-evident, hash-chained receipts. Every sign-in, token, and grant emits a hash-chained receipt, anchored under an ES256-signed tree head you can check against our published JWKS. The chain can't be quietly rewritten, so the audit trail is something you can verify, not just trust.
  • Sender-bound tokens (DPoP, RFC 9449). Access tokens can be bound to a client-held P-256 key with a per-request signed proof — a leaked token replayed without the key is inert. Bearer theft, the agent era's dominant token threat, simply stops working.
  • CAEP / Shared Signals propagation. Revocations and credential changes reach relying parties as signed Security Event Tokens — push or poll — instead of waiting for the next token refresh to notice.
  • A live public MCP tool server. Obelisk answers trust questions to the software that increasingly does the checking: read-only MCP tools at POST /mcp, rate-limited and account-free — the same checks a human runs on the website, callable by any assistant.

Together these make the login the strongest part of your stack, with a posture anyone can check. See the full trust case →

Frequently asked questions

Is Obelisk a Keycard alternative?

Only in part. Keycard sits on top of the identity provider you already run and issues short-lived, policy-checked credentials to agents at runtime. Obelisk is itself the identity provider, and it does not issue tokens to agents. Where the two differ most is the record: Obelisk writes agent lifecycle events to a hash-chained ledger, and anyone holding a receipt's hash can fetch its inclusion proof with no account.

Does Obelisk evaluate agent requests against a policy?

No. API keys bound to an agent carry a fixed capability and scope. No runtime policy engine evaluates an agent's requests. If you need a policy decision on every agent request, that is the problem Keycard addresses.

See it for yourself

Still weighing options? Head back to the full comparison hub to see Obelisk against every provider at a glance.