wif.tax

Keycard

B Keycard (identity and access for AI agents)

A deployed agent can authenticate to a Keycard zone with a token from any OIDC issuer, pinned by issuer and subject, and the zone is itself an issuer that Snowflake and Anthropic can trust. The management API that Terraform uses still needs an Admin-level client secret. Many SaaS connectors need your own OAuth app secret, a PAT or an API key.

Docs: docs.keycard.ai · Checked 2026-10-13 · source YAML · dispute via PR

Inbound A

How a workload running anywhere authenticates to this product.

Workload Identity credential on an Application: register any OIDC issuer that publishes a discovery document as a Provider, pin the credential to that issuer and an exact (or trailing-wildcard) subject, and the SDK presents the platform's token as a jwt-bearer client assertion on each token exchange at the zone.

Issuers
any

Graded on the zone token endpoint, which is where agents, MCP servers and other workloads authenticate at runtime and the core of the product. Worked guides exist for Render and Fly.io; the SDKs also read EKS, AWS web-identity, Azure federated and GCP metadata tokens, and the Providers page names AWS, Azure, Google Cloud, Vercel and GitHub Actions. Trust is pinned by issuer and subject only: no audience or extra-claim constraint is documented, and the Render walkthrough reuses the token Render mints for AWS, so Keycard does not appear to require its own audience. That is the weak part of this A. The management API (Terraform provider, admin scripts) is a separate plane and accepts only service-account OAuth2 client credentials (client ID + secret exchanged at /service-account-token for a short-lived token), which on its own would be a C; those secrets carry the full organization Admin role. Applications can also use client ID + secret (Keycard recommends against it) or URL/CIMD key-based assertions. No on-prem collector to grade; the Keycard CLI and SDKs authenticate the same way as Applications.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

The zone is an OIDC issuer that downstream providers can trust (Snowflake External OAuth, Anthropic WIF, any service that verifies zone JWTs), and AWS audit-log export uses a cross-account IAM role with an External ID; most SaaS catalog entries need a client ID/secret from an OAuth app the customer registers, and others take a PAT or vendor API key stored in Keycard Vault.

Connectors checked: Anthropic and Snowflake (keyless, they trust the zone as issuer; any custom API built with a Keycard SDK likewise); AWS (audit-log export to S3 via cross-account AssumeRole with External ID and an aws:PrincipalOrgPaths condition, keyless); catalog one-click entries such as Linear MCP where Keycard sets up trust itself (keyless); GitHub API (customer's own OAuth App client secret, or a PAT); Google Workspace Calendar/Drive (customer's own Google OAuth client secret; no domain-wide delegation to a Keycard service account); API-key MCP servers and anything else via Keycard Vault (static key). Autonomous agents acting as themselves through a Gateway can only reach vaulted static-key upstreams. Okta, Entra ID, Auth0, Ping and Google appear only as user sign-in IdPs (customer pastes an OIDC client secret), which is human SSO and out of scope. No GCP or Azure connectors and no Slack or M365 data connectors were documented beyond OAuth app setups. Graded B: keyless for some connectors, static keys or customer-managed secrets for many others.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
No expiry field or org policy is documented for service-account or Application client secrets; they live until deleted.
  • docs.keycard.ai checked 2026-10-13
    “Console shows the Client ID and Client Secret once. Copy both into your automation's secret store now. The secret cannot be retrieved later; if you lose it, delete the credential and create a new one.”
✓ Rotation via API
Credentials are created with POST and deleted with DELETE under /service-accounts/<id>/credentials.
  • docs.keycard.ai checked 2026-10-13
    “With an Admin token you can automate the steps above.”
  • docs.keycard.ai checked 2026-10-13
    “The client_secret is returned only by the POST that creates the credential; later reads return metadata only.”
✓ Scoped keys
Split result. An Application's client secret belongs to a purpose-built machine principal limited by its declared dependencies and Cedar policies, which passes. Service-account secrets for the management API are always full organization Admin and cannot be scoped.
  • docs.keycard.ai checked 2026-10-13
    “Dependencies only permit access when an application is acting on its own behalf.”
  • docs.keycard.ai checked 2026-10-13
    “Tokens issued to a service account carry the organization Admin Role. There is no per-account Admin, Manager, or Viewer selector.”
✓ Last-used visible
Documented for service-account credentials. Application credential activity is visible via the Application's Activity feed and the Audit Log.
  • docs.keycard.ai checked 2026-10-13
    “The credentials table shows each credential's Client ID, when it was Created, and Last Active At: the last time the credential authenticated at the token endpoint.”
✗ Leak revocation
Keycard does not appear on GitHub's secret scanning partner list.

Notes

Docs are public, with an llms.txt index; nothing was gated. Keycard also brokers user-delegated OAuth tokens and vaulted static keys for downstream tools; tokens it issues live 24 hours by default unless a Resource sets a shorter lifetime. The grade would hold firmer if workload identity credentials could pin an audience, and the management API would stop being the weak spot if service accounts accepted the same workload identity credentials or could take a role narrower than Admin.

Badge

wif.tax grade B

[![wif.tax grade](https://wif.tax/badge/keycard-agent-identity.svg)](https://wif.tax/p/keycard-agent-identity/)