Give every AI agent a secure identity

Many AI agent security tools focus on discovering or monitoring agents across SaaS apps, browsers, or cloud environments. Agent Identity Kit focuses specifically on giving agents verifiable identity and scoped access, then connecting that identity to users, workloads, devices, credentials, and audit trails.

It's an identity layer purpose-built for AI agents. It gives each agent a verifiable, short-lived credential tied to a specific workload identity: no hardcoded secrets, no shared API keys. The kit ships as an SDK, a code-signed local broker, and a set of CLI commands that integrate with your existing IdP.

Human Delegated agents act on behalf of a named user — coding agents and copilots fall here. Machine Bound agents act on behalf of a workflow or job, not a person — CI/CD bots and provisioning pipelines are the right fit. Fully Autonomous agents operate independently without a human principal and are the most complex to scope. If your agent needs access that traces back to a user, start with Human Delegated. If it's a pipeline job, use Machine Bound.

A workload identity is a URI that uniquely names your agent as a software process rather than as a person — for example, spiffe://acme.com/agent/coding. It lets your authorization server issue tokens to the agent's process directly, without a human login step. Without one, agents typically reuse a service account or a hardcoded key, which can't be scoped, rotated cleanly, or revoked in isolation.

Token Exchange is the OAuth grant that lets an authorization server swap one token for another: a user’s access token, for example, becomes a narrower, agent-scoped token that records which agent is acting on the user’s behalf. The user's original token proves delegation; the new token proves which agent is acting. It's what makes Human Delegated architecture possible without re-authenticating the user on every agent action.

DPoP (RFC 9449) sender-constrains a token to the agent's ephemeral key pair. Even if an access token is intercepted, an intercepted token is worthless without the matching private key. For agents running autonomously, often without a human watching, this eliminates a whole class of token-theft attacks.

WIMSE (Workload Identity in Multi-System Environments) is the IETF working group standardizing workload identity across systems: what SPIFFE pioneered is now on an IETF standards track. The core specification is stable enough to build against today; the Agent Identity Kit is aligned with it, and we’ll track any breaking changes as the standard finalizes.

Human Delegated tokens inherit the user session lifetime by default but are scoped down to the delegated audience. Machine Bound tokens are short-lived; 10-minute lifetimes are the default from op agent identity issue. Fully Autonomous tokens use continuous evaluation (CAEP) and can be revoked mid-flight if the authorization server detects anomalous behaviour.

Yes, provided your IdP supports standard OAuth 2.0 flows. The kit wraps RFC 8693 (Token Exchange) and RFC 9449 (DPoP), both of which are supported by major IdPs including Okta, Entra, and Ping. The local broker handles the key management and token binding so you don't have to patch your IdP.

The broker is a code-signed process that runs on the developer machine or in the execution environment. It holds the ephemeral key pair that DPoP requires, mints short-lived assertions, and exposes a local socket that your agent SDK calls. It means your agent never touches a long-lived credential directly; the broker handles the cryptographic operations and disposes of the material at the end of the session.

Yes, for Human Delegated flows where the platform supports OAuth. The Kit issues a delegated token scoped to the agent's audience; the platform presents it to the downstream API. For platforms that don't support OAuth natively, the Machine Bound architecture (using SPIFFE JWT-SVIDs) is the recommended path until the platform adds standard token support.

No. The Agent Identity Kit layers on top of your existing 1Password vaults and SDK setup. Secrets that agents need at runtime — API keys, database credentials — are still fetched from vaults using the SDK. The kit adds identity and token management on top of that secrets foundation.