No accountable owner
A shared service account cannot tell you which agent acted, or which person is responsible for it.
HelixIAM AI Identity · sovereign by design
Know which agent did what, for whom — and stop it.
Give every AI agent its own identity with an accountable owner and a lifecycle. When an agent acts for a user, the token names both, and its authority only ever narrows. Workloads get identity without stored secrets.
Sovereign by design · your infrastructure in Europe · your keys · a Dutch vendor
Request · agent acting for alice
POST /realms/acme/oauth2/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=eyJ… # alice actor_token=eyJ… # agent: invoice-assistant scope=invoices:read
Issued access token · decoded
{
"sub": "alice",
"act": { "sub": "agent:invoice-assistant" },
"scope": "invoices:read",
"aud": "https://api.acme.example/invoices",
"iss": "https://id.acme.example/realms/acme"
}actThe agent is named in every token; the user stays the subject.scopeAuthority narrows to what the agent needs. It never widens.ownerSuspend the agent and it gets no new tokens.
The problem
Agents are running on borrowed identities.
Shared API keys and copied user tokens leave three questions without an answer: who did this, for whom, and how do we stop it without breaking everything else?
No principal
When an agent reuses a person's token, every action looks like the person did it — with all of their rights.
No safe off-switch
Rotating a shared key to stop one agent breaks every other system that uses it.
How it works
Owner, delegation, limits, off-switch.
- 01
Register the agent
Each agent is its own identity in a realm, with an accountable owner, a purpose, roles of its own and an expiry date.
- 02
Delegate with token exchange
The agent exchanges the user's token for a new one through standard OAuth token exchange (RFC 8693):
subis the user,actis the agent. - 03
Narrow the authority
Delegated authority is the intersection of what the user and the agent may do, restricted to the requested scope and audience. It never widens.
- 04
Review and suspend
Agents whose owner has left are flagged for review. Suspend an agent and it gets no new tokens; resource servers that introspect see it at once.
Sovereign by design
Why not the cloud giants?
Microsoft, Okta and Auth0 all sell AI-agent identity, and they do it well. They deliver it as cloud services operated by US-headquartered companies. HelixIAM gives you agent identity on your own infrastructure in Europe, with tokens signed by keys you hold.
| Criterion | Cloud agent-identity services | HelixIAM AI Identity |
|---|---|---|
| Products | Microsoft Entra Agent ID; Okta and Auth0 for AI Agents | HelixIAM, commercial software from KubeDNA B.V. |
| Where it runs | Cloud services operated by the vendor (Auth0 also lists a private deployment option on its Enterprise plan) | Self-hosted on your own infrastructure: you choose where it runs |
| Vendor | US-headquartered companies | KubeDNA B.V., a Dutch company |
Based on the vendors' public documentation, checked October 2026: Microsoft Entra Agent ID, Okta Agent SSO, Auth0 for AI Agents, Auth0 plans. Product names are trademarks of their owners.
Workload identity
Keyless identity for Kubernetes and CI.
Your pods and pipelines already carry a token signed by their platform. HelixIAM verifies it against the issuer you trust and returns a short-lived HelixIAM token bound to the roles of one application. Nothing to store, nothing to rotate.
- Issuer, subject and audience must all match a registered credential
- Sender-constrained tokens with DPoP
- Audience-restricted tokens with resource indicators
Request · CI job presents its platform token
POST /realms/acme/workload-identity/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=eyJ… # signed by the CI platform
Issued token · decoded
{
"sub": "service-account-deploy-pipeline",
"realm_access": { "roles": ["deployer"] },
"exp": 1798732800,
"iss": "https://id.acme.example/realms/acme"
}issTrusted issuer, subject and audience must all match, or the request is refused.expShort-lived, bound to the roles of one application.secretNothing to store or rotate in the pipeline.
Governance
One inventory of every agent.
Owners, status, bound applications and last use in one console screen, next to the users, applications and keys of the same realm. Every agent token issued or refused — direct or delegated on behalf of a user — lands in the searchable audit log, together with lifecycle changes, admin actions and workload token issuance, and you can stream the log to your SIEM over HTTPS.
Built on standards
Ready for MCP and the tools your agents call.
Protected-resource metadata
Ready for MCP: OAuth protected-resource metadata (RFC 9728) tells AI tool servers' clients where to get tokens.
Standard token exchange
Delegation uses RFC 8693, so any OAuth-aware resource server can read the act claim.
Dynamic client registration
Register clients through the standard API, with admin-controlled policy.
Deployment pattern
Runs alongside the identity provider you have.
You don't need to replace your workforce IdP. People keep signing in where they do today and are brokered into HelixIAM over OpenID Connect or SAML; HelixIAM governs the agents and workloads that act for them, on infrastructure and keys you control.
- Broker sign-in from other OIDC, SAML and social identity providers
- Self-hosted on your Kubernetes with a Helm chart
- Keep signing keys in your HSM or Vault / OpenBao
Questions from platform and security teams
Our identity provider already has agent features. Why HelixIAM?
Several hosted identity providers now offer agent identity. HelixIAM is for teams that want it on their own infrastructure, with their own keys, next to keyless workload identity and European eIDs — and it runs alongside your current IdP.
What happens to tokens when we suspend an agent?
The agent gets no new tokens, and resource servers that introspect tokens see the suspension at once. Tokens that APIs validate locally stay valid until their short expiry, so keep agent token lifetimes short.
Do we have to self-host?
Yes, HelixIAM runs on your infrastructure. KubeDNA offers deployment and operations support on your own or a European cloud, with the scope set per contract.
Which standards does delegation use?
OAuth 2 token exchange (RFC 8693). The issued token carries the user as
sub and the agent as act.Early access/now onboarding launch partners
See an agent act for a user — and stop it.
A paid pilot on your own Kubernetes: a few real agents or MCP tool servers registered with owners, one delegated user journey, keyless identity for one pipeline, a suspension drill and audit export to your SIEM. Then a production plan.