ZeroID: Give Every AI Agent Its Own Identity, Delegation Chain, and Kill Switch

When an AI agent commits code, calls an API, or moves money, the audit log should answer three questions: which agent did this, on whose authority, and with what permissions. Too often today it cannot, because the agent acted with a borrowed human login or a shared service account. ZeroID is open source identity infrastructure built for exactly that gap. It gives every agent its own cryptographically verifiable identity, lets agents delegate a narrowed slice of their authority to sub-agents, and revokes an entire delegation chain in real time when something goes wrong.

Key Takeaways

ZeroID is identity infrastructure for autonomous agents, not a human login system and not a general workload identity platform.

Each agent gets a stable WIMSE/SPIFFE identity URI, and delegation uses RFC 8693 token exchange with automatic scope attenuation.

Revoking a parent credential invalidates the whole downstream chain immediately, instead of waiting for tokens to expire.

It is built on OAuth 2.1, WIMSE/SPIFFE, RFC 8693, DPoP, CIBA, and the OpenID Shared Signals Framework, with SDKs for Python, TypeScript, and Rust.

At the time of writing it has 209 stars, 24 forks, and 329 commits, is Apache 2.0 licensed, and was created on 2026-03-17.

It runs as a Go service backed by PostgreSQL, locally with Docker Compose or hosted at auth.highflame.ai, so trying it is a small setup, not a platform migration.

Watch the 30-second repo signal

What ZeroID Actually Is

ZeroID, by Highflame, describes itself as "Identity Infrastructure for Autonomous Agents" and as an Autonomous Agent Identity Management System (AAIMS). In plain terms, it is the server that issues short-lived, scoped credentials to agents, records who authorized them, and can take them away again.

The distinction the project insists on matters. ZeroID says it is not a human identity system such as Okta, Entra, or Clerk, and not a general workload or non-human identity platform such as SPIFFE/SPIRE, cloud IAM, or a secret manager. Those ecosystems are mature, and ZeroID builds on their primitives, including WIMSE/SPIFFE URIs, OIDC, and RFC 8693, and federates with them. What it adds is the agent-shaped layer they do not model: per-agent identity, attenuated delegation across agent chains, a trust tier derived from attestation, the on-behalf-of act chain, and real-time revocation with cascade.

That framing lines up with the problem statement in the OpenID Foundation whitepaper on Identity Management for Agentic AI, published in October 2025, which ZeroID quotes directly: "User impersonation by agents should be replaced by delegated authority. True delegation requires explicit 'on-behalf-of' flows where agents prove their delegated scope while remaining identifiable as distinct from the user they represent." When an agent impersonates a user, the log shows the user. When it acts under delegation, the log shows both the user and the agent, and that difference is the whole product.

The project is also already in production use by its own maker. The README says Highflame has used ZeroID to power its Agent Control and Governance Platform for several months and contributed it to open source to advance the field. Independent coverage agrees on the basics: Help Net Security reported on 2026-04-13 that ZeroID is an open source identity platform for autonomous agents and multi-agent systems, built around RFC 8693 delegation chains and real-time revocation through the OpenID Shared Signals Framework. Business Wire covered the April 2026 launch on the same terms, noting the Apache 2.0 license and the hosted option at auth.highflame.ai.

Why Service Accounts and Plain OAuth Break Down

The README's comparison table is blunt, and it is the fastest way to see the argument.

Service accounts are the worst case: shared, opaque, and with no delegation trail at all. If five agents share one service account, revoking one agent means rotating a credential the other four still need, and the audit trail cannot tell them apart. OAuth and OIDC work well for a human signing in, and partially for a single agent inside one trust domain, but the model breaks when agents operate asynchronously, spawn sub-agents, or cross organizational boundaries. A token minted for a human does not naturally carry "this agent, acting for that human, at delegation depth 2, with only these tools".

ZeroID's answer is to make the agent a first-class principal. Every agent gets a stable, globally unique identity URI in the form spiffe://{domain}/{account}/{project}/{type}/{id}. Every token carries that URI, plus the full on-behalf-of chain: who authorized it, what scope was granted, and how deep the delegation goes. Any system the agent calls can verify that chain cryptographically instead of trusting a shared secret.

How Delegation Works, Step by Step

The core flow is a chain, and each hop narrows what the next agent can do.

Two enforcement details make this more than a naming scheme. First, scope ceilings: an identity's allowed_scopes is the absolute ceiling of what its tokens can carry, credential policies only narrow within it, and a grant whose layers leave nothing is refused rather than minted without scopes. Second, depth caps: a credential policy sets a maximum delegation depth, and the default token profile caps the nested act chain at 16 agents, so a runaway chain cannot grow without bound.

The project also covers the flows around that core. A fully autonomous agent can use an API key with no human in the loop. A human can authorize once, and the agent then runs autonomously. A long-running agent can refresh its token without re-authenticating. For the moments that genuinely need a person, OpenID CIBA lets an agent request out-of-band approval, with the user approving or denying through email, Slack, or mobile push, and the agent collecting the token by poll, ping, or push. For high-risk agents, DPoP sender-constrained tokens bind a token to the client's key, so a stolen token alone is not enough to use it.

For coding agents specifically, ZeroID ships a scope vocabulary that keeps teams consistent: tools:read, tools:write, tools:execute, tools:network, tools:agent, and tools:vcs, plus personas such as a read-only reviewer with depth 1, a code editor with depth 2, and a full-autonomy agent with depth 5. That vocabulary is also what an MCP server can check at the tool boundary, which is where a prompt-injected instruction meets a credential that cannot authorize the write.

What You Get Beyond the Token

ZeroID is a fuller server than a token minter, and the feature list shows it.

The attestation piece deserves a note, because it is how trust becomes earned rather than asserted. Verifiers for software, platform, and hardware attestation sit behind a fail-closed contract, and the shipped OIDC verifier covers GitHub Actions, GCP Workload Identity, and Kubernetes projected service account tokens, with per-tenant attestation policies for issuer allowlisting and claim binding. An agent that cannot prove what it is does not get the higher trust tier, whatever it claims.

Running It: Small Setup, Real Dependencies

Trying ZeroID does not require adopting Highflame's commercial platform. The open source server is a Go service backed by PostgreSQL.

That last row is the operational caveat to respect. The README's API reference marks admin endpoints as "protect at network layer", which means a careless deployment that exposes them is a deployment mistake, not a product feature. The same applies to the signing keys the local setup generates and to the API keys issued at registration: they are the root of the whole chain, so they belong in a secret store, not in a repo or a chat log.

The Standards Stack, and Where It Is Still Emerging

ZeroID's pitch is that it implements existing standards rather than inventing a proprietary protocol, and the README's standards table is unusually complete.

Honesty requires the other half of that table. WIMSE is an IETF draft, not a finished standard, and the README itself maps ZeroID against the CoSAI and OASIS ODIS draft and lists requirements it does not yet meet. Agent identity standards are being written right now, which is both the opportunity and the risk: adopting ZeroID means adopting a stack that may shift as WIMSE, ODIS, and the OpenID agentic work finalize. The counterweight is that the stack is built from widely deployed pieces, OAuth 2.1, JWT, and token exchange, so the bet is on composition, not on a single new protocol.

The Limits to Keep in View

ZeroID solves identity, delegation, and revocation. It does not solve everything around agents, and the project is clear about its scope. It is not a human identity provider, so it does not replace your existing login system. It is not a general workload identity platform, so teams already running SPIFFE/SPIRE or cloud IAM will use it alongside those systems, federated, not instead of them. It also does not, by itself, make an agent's actions safe: a correctly identified agent with a properly scoped token can still do something foolish inside its scope, which is why scope ceilings, tool vocabularies, and MCP boundary checks matter as much as the token.

Scale is another honest limit. At 209 stars and 24 forks, ZeroID is a focused project with real traction for its age, not a mainstream identity platform with a decade of operational history. The 329 commits and 106 releases show active development, but a team adopting it should expect to read the docs, run it in staging first, and watch the standards it tracks. The planned work, a human-in-the-loop approvals API, a dedicated CLI, and a GitHub Actions OIDC upstream validator, also shows which pieces are still coming.

If you run agents that already touch production systems, the related question is what those agents are allowed to find and report. For a specialist security angle on giving an AI tool a defined job, see CVE MCP Server: Turn Claude Into an Automated CVE Analyst. Identity tells you who acted; a scoped security tool tells you what it was allowed to look at.

Who Should Try It, and Who Should Wait

ZeroID makes the most sense for teams already running multi-agent systems where the audit question has started to hurt: orchestrators spawning sub-agents, agents crossing team or organizational boundaries, or long-running agents that outlive any single human session. If your agents still run as one service account behind one API key, and you have ever struggled to say which agent did what, this is the tool that makes that question answerable.

It is also a good fit if you like the design constraints: short-lived tokens instead of long-lived shared secrets, scope that only narrows down a chain, depth caps, and a revocation path that does not wait for expiry. Those are the properties that turn "we have an agent problem" into "we have an agent identity system".

You should probably wait, or run it only in staging, if your agents are still single, short-lived, and internal, if you have no delegation chains to audit, or if your organization requires finished, ratified standards before adopting identity infrastructure. In that case, keep the concepts, per-agent identity, delegated authority instead of impersonation, and cascade revocation, and revisit ZeroID as WIMSE and ODIS mature.

The shift it represents is simple to state and hard to retrofit later. Stop asking agents to borrow a human's identity. Give each agent its own name, a credential that proves it, a chain that shows who authorized it, and a kill switch that works in real time. Everything else in agent security gets easier once that is true.

Frequently Asked Questions

Is ZeroID a replacement for Okta, Entra, or Clerk?

No. ZeroID says explicitly that it is not a human identity system. It builds on human identity primitives and federates with them, but its subject is the agent, not the person signing in.

Does ZeroID replace SPIFFE/SPIRE or cloud IAM?

No. Those are general workload identity systems, and ZeroID says it is not one. It uses WIMSE/SPIFFE URIs and federates with workload identity, while adding the agent-specific delegation and attestation layer on top.

What happens when an orchestrator's credential is revoked?

The whole downstream chain is invalidated immediately through cascade revocation, with no waiting for token expiry. Continuous access evaluation signals through the OpenID Shared Signals Framework can trigger the same revocation when risk signals fire.

Can a sub-agent get more permission than its orchestrator?

No. Delegation uses RFC 8693 token exchange with automatic scope attenuation, and scope ceilings cap what any identity's tokens can carry. A grant that would leave no scope is refused rather than minted empty.

Do I need Highflame's commercial platform to use ZeroID?

No. ZeroID is Apache 2.0 licensed and runs as a Go service with PostgreSQL, locally via Docker Compose or hosted at auth.highflame.ai. Highflame's commercial platform adds enforcement, observability, and policy management on top of the same identity layer.

Is ZeroID production-ready?

It is in production use inside Highflame's own platform, and its standards stack is largely established, but WIMSE and ODIS are still drafts and some features, including a dedicated CLI and an approvals API, are planned. Run it in staging first and track the standards it implements.

Baca versi Bahasa Indonesia dari artikel ini