[ ZERO TRUST ]

Every agent is an identity. Every request is checked.

AI agents hold credentials, move money and call production APIs. 1Claw treats each one like any other workload in a zero-trust network: it proves who it is with OIDC instead of a stored key, gets only the access a human granted, is re-checked on every request, and leaves a tamper-evident trail.

Read the zero-trust docsTalk to a security engineer
No static keysOIDC workload identityOIDC federationZero access by defaultShort-lived tokensImmediate revocationHash-chained auditNo static keysOIDC workload identityOIDC federationZero access by defaultShort-lived tokensImmediate revocationHash-chained audit

[ PRINCIPLES ]

Zero trust, applied to agents

The three NIST SP 800-207 tenets, and what each one means inside 1Claw.

Verify explicitly

No request is trusted by where it came from

Every call carries a JWT or a scoped key (1ck_, ocv_, plt_). There is no open read path and no trusted network. Tokens are checked for signature, expiry, revocation, vault binding and scope before any policy runs.

Least privilege

Agents start with zero access

A new agent can read nothing until a human writes a policy for specific paths. Scopes are derived from those policies and baked into the token as a ceiling, so a token can never exceed what it was issued for.

Assume breach

A stolen credential reaches very little

Tokens live minutes, not months. Signing agents never see private keys. Secrets are encrypted per secret under an HSM-held key, so a database copy is ciphertext. Revocation applies on the next request.

[ IDENTITY ]

A verified identity for every principal

Humans, agents and the platforms that act for them each authenticate differently, and each gets its own identity in the audit log.

Humans

  • Password plus TOTP or passkey MFA
  • Passkeys bound to the 1Claw domain (WebAuthn)
  • Step-up auth (passkey or re-auth) before treasury send, swap and export
  • Password change invalidates every existing session

Agents

  • OIDC client credentials: present your platform's workload token, store nothing
  • mTLS: bind a client certificate your terminator verified
  • Or a one-time API key (ocv_), Argon2-hashed at rest, exchanged for a short-lived JWT
  • Per-agent Ed25519 identity key and P-256 key-agreement key

Platforms

  • Platform keys (plt_) act only through a connection a user approved
  • Each connection resolves to one end user and one org
  • Agents a platform creates live in the user's org, not the platform's
  • Every platform action is attributed to the app in usage and audit

[ OIDC IN ]

Bring your workload identity, not a stored API key.

An agent can authenticate with the token its own platform already mints for each job or pod. 1Claw verifies it against the issuer you registered and returns a short-lived agent token. Nothing long-lived is stored where the agent runs.

What 1Claw checks

  • The issuer and client ID come from the agent record, never from the presented token.
  • The issuer's discovery document must name itself and publish an https JWKS.
  • A validly signed token from another issuer, or for another audience, is refused.
  • The resulting agent JWT carries the agent's scopes and expires in minutes.
GitHub ActionsGitLab CIGoogle CloudKubernetes service accountsAny OIDC issuer signing RS256
OIDC and mTLS agent authentication
register a CI agent, then exchange the job's token
# once: tie the agent to your repo's OIDC identity
1claw agent create ci-deployer \
  --auth-method oidc_client_credentials \
  --oidc-issuer https://token.actions.githubusercontent.com \
  --oidc-client-id https://github.com/acme/checkout

# every run: the job's own token in, a short-lived agent JWT out
curl -X POST https://api.1claw.co/v1/auth/agent-token \
  -H "Content-Type: application/json" \
  -d '{"agent_id":"<uuid>","oidc_token":"'"$OIDC_TOKEN"'"}'

[ OIDC OUT ]

1Claw as your agents' OIDC issuer, so cloud keys never sit on disk.

1Claw publishes a standard OpenID Connect issuer at api.1claw.co with discovery and JWKS. Register it once with your cloud or model provider, and agents trade their 1Claw identity for that provider's short-lived credential.

01

Agent asks 1Claw for a federated token

RFC 8693 token exchange at /v1/auth/federated-token, naming the audience it needs.

02

1Claw checks and signs

Federation must be on for that agent and the audience on its allowlist. The JWT is signed RS256 by a KMS HSM key.

03

The provider verifies against our JWKS

Anthropic, Google Cloud or AWS validates iss, aud, exp and kid from api.1claw.co's published keys.

04

A short-lived provider credential comes back

No Anthropic key, GCP service-account key or AWS access key is ever stored.

Where it works

  • AnthropicWorkload Identity Federation for the Claude API
  • Google CloudWorkload Identity Federation pools
  • AWSIAM OIDC identity providers and AssumeRoleWithWebIdentity
  • Your own servicesAny relying party that validates a JWKS

Guardrails

  • Off by default: a human enables federation per agent
  • An empty audience allowlist denies everything
  • 15-minute default lifetime, 60-minute hard cap
  • Every token has a jti and can be revoked
  • Every mint is written to the audit hash chain
  • Rate limited
api.1claw.co/.well-known/openid-configuration
{
  "issuer": "https://api.1claw.co",
  "jwks_uri": "https://api.1claw.co/.well-known/jwks.json",
  "id_token_signing_alg_values_supported": ["EdDSA", "RS256"]
}
federated token claims
{
  "iss": "https://api.1claw.co",
  "sub": "agent:9f8e7d6c-...",
  "aud": "https://api.anthropic.com",
  "org": "3b1c...",
  "scopes": ["keys/**"],
  "exp": 1767225900,
  "jti": "c0ffee..."
}
Set up OIDC federation

[ IAM ]

Least-privilege access, in layers

Every layer has to pass. A request that clears authentication still needs a vault binding, a matching scope and a policy that grants the exact permission.

requestauthenticatevault bindingscopepolicy + conditionsconsensusallow

Vault binding

A token can name the vaults it may touch. Anything else is refused from the JWT alone.

Scopes

Path globs derived from policies at issue time. A ceiling the token can never exceed.

Policies

Explicit read, write, delete, rotate and list grants on path patterns, per agent or user.

Conditions

IP and CIDR allowlists and time windows, evaluated on every request.

Policy as code

Cedar on Team and OPA on Business for rules beyond paths, including transaction policy.

M-of-N approval

Consensus gates on signing, key export, policy changes and member changes.

Agents that sign never hold keys

With the Intents API on, an agent cannot read private keys even with a read policy. It submits transactions, and 1Claw checks destination allowlists, per-transaction and daily caps, chains, sanctions screening and approvals before signing on its behalf.

[ CONTINUOUS VERIFICATION ]

Trust is re-earned on every request

Access is never granted once and left alone. Tokens expire quickly, revocation is immediate, and every decision is recorded.

Short-lived tokens

Agent JWTs default to one hour and can be set to minutes. SDKs and the MCP server refresh them before expiry.

Revocation on the next request

Changing or deleting an agent's policy revokes all of its live tokens. Deactivating an agent stops new ones. Rotating a key kills the old one.

Sender-constrained tokens

Optional DPoP binds a JWT to the client's key pair, so a copied token is useless without that key.

Tamper-evident audit

Every access, token exchange, federation mint and policy change is HMAC hash-chained. Verify the chain with GET /v1/audit/verify.

[ ENTERPRISE ]

Fits the identity stack you already run

1Claw is also an OAuth 2.0 / OIDC provider (authorization code with PKCE), so your own apps can offer Sign in with 1Claw. For workforce sign-in, enterprise SSO over SAML and OIDC through WorkOS is available on request.

Workforce SSO

SAML / OIDC via WorkOS, on request

Workload identity

OIDC client credentials, mTLS

Federation

OIDC issuer with RS256 and EdDSA JWKS

Encryption, HSM key custody, TEE attestation and compliance are covered on the security architecture page.

Take the static keys out of your agent fleet

Walk through your identity architecture with our team, or start with the OIDC docs and the free tier.

Talk to a security engineerOIDC federation docs

Questions? Reach us at ops@1claw.co