thunder-id/thunderid: ThunderID is a high-performance, open-source identity stack designed for developers to secure and manage access for humans, AI agents, and machines through fully composable identity flows.
Introduction
In the earlier article, we touched briefly on the idea that ThunderID treats AI agents as first class identities. This article slows down and looks at that idea in much more detail. What does it actually mean for an AI agent to “have an identity”? How does permission work when there is no human physically typing a password? And what happens when something goes wrong?
This is written for someone who already understands the basics of logging in with a username and password, but has not yet thought deeply about what happens when the thing logging in is a piece of software acting on its own.
Why AI Agents Need Their Own Identity System
For most of the history of computing, identity systems were built around one simple assumption. Ahuman sits down, proves who they are and then uses an application. The application is just a window the human looks through.
AI agents break that assumption. An agent might check your calendar every morning without you touching a keyboard. It might book a flight, reply to an email or move money between accounts, all while you are asleep. The agent is not just a window anymore. It is acting.
This creates a real problem. If the agent uses your saved password or your personal login token to do all of this, then from the system’s point of view, there is no difference between you and the agent. If the agent makes a mistake, or is tricked into doing something harmful, there is no way to separate “the user did this” from “the agent did this while pretending to be the user.”
ThunderID was built specifically to close this gap.
The Old Assumption That Broke
In the old world, identity systems only had to answer one question. Is this really you? In the new world, they have to answer a second question just as often. Which agent is acting right now and what exactly did you allow it to do?
The Four Pillars
The first pillar carries most of the weight for our purposes, so we will spend the most time there. The other three each solve a problem that only becomes obvious once agents are involved.
Pillar 1: Agent-Native Identity
This is the foundation. It has four parts worth separating, because people often collapse them together and then wonder why the result feels unsafe.
Every agent gets its own record
The starting point is simple but important. In ThunderID, an AI agent is not a hidden feature of a human’s account. It is its own identity, stored and managed separately, the same way a human user account is stored and managed.
This might sound small but it changes everything downstream. Once an agent has its own record, the system can:
- Give the agent its own permissions, separate from the human’s full permissions
- Track the agent’s actions on their own, without mixing them into the human’s history
- Turn the agent off completely, without touching the human’s account at all
- Apply different security rules to agents than to humans, since agents behave differently (they can act constantly, at machine speed, without ever getting tired)
This is what “first class” means in practice. The agent is a real, trackable entity with its own identifier, owner, credentials, attributes and lifecycle, not an invisible extension of a person.
Delegated authority, not impersonation
This is probably the single most important idea in the whole system, so it is worth explaining carefully.
When you let an agent act for you, there are two very different ways this can happen underneath the surface.
Impersonation. The agent is given something that makes it indistinguishable from you. It uses your login, your token or a copy of your identity. From the system’s point of view, “the agent” and “you” are the exact same thing.
The risk here is obvious. If the agent does something wrong, damaging or simply unexpected, it is very hard to separate that from something you did yourself. This also means the agent silently has access to everything you have access to, not just what it needs for its task.
Delegation. The agent keeps its own separate identity, but is granted specific, limited permission to act for you. The system always keeps a clear line between “you” and “the agent acting for you.”
ThunderID is built around delegation, not impersonation. This is the core design decision that makes everything else, permissions, tracking and safety, possible.
It is worth seeing how this looks in practice, because it is more concrete than it sounds. When an agent acts for a user, the access token it carries names both parties. The user appears in the standard subject field and the agent appears in a separate actor field. A service receiving that token can read both at once. It knows which user authorized the action and which agent actually carried it out, without either one being hidden behind the other. That single detail is what separates delegation from impersonation in the actual data, rather than just in intent.
ThunderID gives an agent three distinct ways to act and they are deliberately kept separate. On its own behalf, on behalf of a signed-in user or delegated to it by another agent. An agent starts out able to act only as itself, and acting for a user is something you switch on explicitly.
Why this matters in practice. Imagine you allow an agent to check your calendar and suggest meeting times. With impersonation, that agent technically also has the power to read your private messages, delete files, or make payments, because it is “you.” With delegation, the agent only has the calendar permission you actually granted it. Even if the agent is compromised or behaves unexpectedly, the damage is limited to what it was actually allowed to do.
Consent aware access
Delegation only works if permission is actually given on purpose, not assumed.
Think about how a mobile phone asks “Allow this app to use your camera? Yes or No” the first time an app tries to use it. ThunderID applies the same basic idea to AI agents, but in a more structured way, since an agent might need many different types of access over time, not just one.
The important word here is “specifically.” Broad, one time consent (“yes, this agent can do anything forever”) defeats the purpose. Consent aware access is meant to work at the level of individual permissions, so a human can say yes to “check my calendar” while still saying no to “read my private messages,” even if both requests come from the same agent.
Traceability
Even with careful delegation and consent, things can still go wrong. A permission might be misused, a bug might cause unexpected behavior or an agent might be tricked by malicious input from somewhere else. When that happens, the question becomes what actually happened and who is responsible?
Because the agent has its own identity and the token names both parties, the system can record
- Which agent performed the action
- Which human it was acting on behalf of
- What permission it used to do it
- What it actually did
That last row matters just as much as the successful ones. A record of a denied action, an agent trying to do something it was not allowed to do is often the earliest warning sign that something needs attention.
This audit trail is what turns “we hope the agent behaved correctly” into “we can prove, exactly what the agent did and did not do.” Note that it is only possible because of the first three parts. Without a separate identity, there is no agent to name. Without delegation, there is no second party to record. Without consent, there is no specific permission to point at.
Pillar 2: Post-Quantum-Safe by Design
This is a more technical pillar, but it has a direct consequence for agents.
Future, much more powerful computers, called quantum computers, may eventually be able to break some of the encryption methods used today. For an ordinary login system this is a slow-moving concern, because a stolen password can simply be changed.
Credentials issued to agents are different. They may need to stay valid and trustworthy for a long time and other systems may be making decisions based on the assumption that such a credential cannot be forged. A signature that becomes forgeable in ten years is a problem for anything signed today that is still expected to be trusted then.
ThunderID is built with what is called a crypto agile foundation , meaning the signing and encryption algorithms it uses are configurable rather than baked in. This is not a future plan. ThunderID already supports ML-DSA, one of the post-quantum signature algorithms standardized by NIST, for signing the tokens it issues alongside the classical RSA and ECDSA algorithms in use today.
In simple terms the security promises can keep holding up even as computing power changes and the change can be made by configuration rather than by rebuilding the system.
Pillar 3: Decentralized Identity
The pillars so far describe trust inside one system. This one is about trust between systems that do not share a database.
Imagine an AI agent built by your company needs to talk to a completely different company’s service. How does that other service know the agent is legitimate and not some random piece of software pretending to be your agent?
The traditional answer is to call back and check every single time, which is slow and creates a lot of extra traffic between systems. ThunderID supports a different approach, based on something called a verifiable credential.
What a verifiable credential actually is
A simple way to think about it is a digital, tamper proof certificate. Instead of a service having to ask “is this real?” every time, the agent can simply present a credential that was already signed by a trusted issuer. Anyone who receives it can check the signature and know immediately that it is genuine, without contacting the original issuer again.
This pattern has a name in the identity world. The issuer, holder, verifier model. The agent is the holder, storing the credential in something like a digital wallet. ThunderID can play either of the other two roles. It issues credentials and it can also act as the verifier that checks a credential presented to it. That second half matters because a service using ThunderID does not have to implement any credential protocol itself.
The two standards behind this
ThunderID supports two emerging open standards for this process
- OpenID4VCI (OpenID for Verifiable Credential Issuance): the process of ThunderID creating and handing a credential to an agent’s wallet.
- OpenID4VP (OpenID for Verifiable Presentations): the process of an agent showing that credential to another service and that service checking it is valid.
The important idea is simply this. Credentials let trust travel with the agent, instead of requiring a phone call back to headquarters every time trust needs to be established.
Thinking beyond one central system
Verifiable credentials connect to a bigger idea. In a traditional identity system, one central authority is the only source of truth and everyone has to check with it directly. Decentralized identity spreads that trust using ideas like
- Decentralized identifiers: a way of identifying something (a person, an agent, an organization) that is not tied to any single company’s database.
- Digital wallets: a place, controlled by the agent or the person, where credentials are stored and reused across many different services.
- Trust registries: lists that say which issuers are actually trustworthy, so a verifier can check not just “is this credential real” but also “was it issued by someone I should actually trust.”
This matters more and more as AI agents start working across company boundaries, not just inside one organization’s walls.
Pillar 4: Lightweight Runtime with GitOps Support
The last pillar sounds like an operations concern rather than an identity one. For agents, it turns out to be both.
ThunderID is written in Go and runs as a small, headless, API-first service. Headless means the console interface, the SDKs and the end-user login screens all sit on top of the API rather than being welded into the core, so they can be replaced.
The GitOps half is the part that matters for agents. Identity configuration in ThunderID is declarative. Agents, applications, organization units, flows and users can all be defined as YAML files and applied to a running system. That makes identity configuration reviewable the same way application code is.
Consider what this means when the thing being configured is an agent
An agent’s permissions are exactly the kind of thing you want a record of. Answering “who gave this agent the ability to spend money and when?” becomes a version control question rather than an archaeology exercise.
There is a second connection worth noting. Agents in ThunderID are not only identities the system manages. They are also actors that can interact with the system itself. Core identity operations are exposed through standard APIs and through MCP, the protocol AI tools increasingly use to call external capabilities. An agent can therefore discover and invoke identity functions programmatically, with a human in the loop. The same headless, API-first design that makes GitOps possible is what makes this possible too.
Putting It All Together: A Worked Example
Let us walk through a realistic scenario using everything above.
Imagine you have a personal AI assistant that manages your work travel.
None of these ideas work well alone. Together they let an AI agent act with real independence, while still staying safe, limited and accountable.
Where ThunderID Fits in the Bigger Picture
ThunderID is not meant to exist alone. It is designed to drop into the infrastructure a company already runs, which is why it ships deployment paths for Docker, Kubernetes and OpenChoreo, WSO2’s open source internal developer platform, where it can be provisioned declaratively as a platform resource.
It is also not trying to replace WSO2 Identity Server for traditional human login. It is solving a problem those older systems were never originally designed for.
The core shift ThunderID represents is a change in what “identity” even needs to mean. It is no longer enough to ask “is this really you?” Increasingly, systems also need to ask “which agent is acting, on whose behalf, with what permission and can it prove that?”
The four pillars are how it answers. Agent-native identity gives every agent its own record, favors delegation over impersonation, requires specific consent and records what happened. Post-quantum-safe design keeps those records trustworthy over time. Decentralized identity lets an agent carry proof of itself beyond the system that issued it. And a lightweight, GitOps-friendly runtime keeps the whole arrangement reviewable rather than improvised.
Taken together, they form one of the clearer early blueprints for how AI agents can operate with real autonomy without operating in the dark.
Top comments (0)