How to give AI agents their own identity: ownership, lifecycle and on-behalf-of delegation

AI agents have moved from demos into real work. They read tickets, draft invoices, query internal APIs and call tools for the people who use them. In most organisations they do it on borrowed identity: a shared API key, a service account created for the proof of concept, or a copy of the user’s own token.

That works until someone asks three questions. Which agent did this? For whom? And how do we stop it without breaking everything else? This article describes the building blocks that answer those questions with open standards, and how we built them into HelixIAM.

Why shared keys and service accounts fail for agents

Service accounts were designed for software with one fixed job, such as a nightly export. An agent is different: what it does depends on the prompt, the data and the person it is helping. Borrowed identity breaks down in three ways.

• No accountable owner. A key in a secrets store does not say which agent used it, or which person answers for it. When the project lead moves on, the key stays.
• No principal. When an agent replays a user’s token, the API sees only the user. Every action carries all of that person’s rights, and the log cannot tell the agent’s actions from the person’s.
• No safe off-switch. To stop one misbehaving agent you rotate the shared key, and every other system that uses it stops with it.

The fix is to treat each agent as an identity in its own right, not as a credential.

Building block 1: its own identity, with an accountable owner

Every agent gets its own identity in the realm (the tenant it belongs to). It has a name, a purpose, its own least-privilege roles, a bound OAuth client to obtain tokens with and, optionally, an expiry date. It also has an owner: a named person who answers for it.

The owner is the person you call when the agent misbehaves, and the person who confirms that it is still needed. Everything else rests on it. Because the agent has its own name, it appears in every token it uses, so APIs and logs can tell agent activity from human activity. Because it has its own roles, an agent can be given less than the people it works for.

Building block 2: a lifecycle and owner review

Agents are created quickly and forgotten just as quickly. A lifecycle makes the forgetting visible. In HelixIAM an agent is always in one of four states:

Ownership is checked too. A review classifies every agent’s owner against the realm’s users, so agents whose owner no longer exists surface for an administrator. When a person is disabled or deleted, the agents they own that are still active are suspended, and each suspension is audited. Nobody leaves the company and leaves live, unattended agents behind.

Building block 3: on-behalf-of delegation with RFC 8693

Most agents act for someone. The agent drafting an invoice does so for Alice, and the invoice API should apply Alice’s rules, not a blanket service account. The standard way to express this is OAuth 2.0 token exchange, RFC 8693.

The agent sends two tokens to the standard token endpoint: Alice’s access token as the subject_token and its own access token as the actor_token. Its client authenticates the request, just as for any other grant. HelixIAM verifies both tokens, checks that the actor is a registered agent that is still active, and issues a new token:

POST /realms/acme/oauth2/token
# the agent's own client authentication
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=eyJ…  # alice's access token
subject_token_type=urn:ietf:params:oauth:token-type:access_token
actor_token=eyJ…  # the agent's own access token
actor_token_type=urn:ietf:params:oauth:token-type:access_token
scope=invoices:read
resource=https://api.acme.example/invoices

{
  "iss": "https://id.acme.example/realms/acme",
  "sub": "alice",  1
  "act": { "sub": "agent:invoice-assistant" },  2
  "aud": "https://api.acme.example/invoices",  3
  "scope": "invoices:read",  4
  "realm_access": { "roles": ["invoices-reader"] },
  "iat": 1793352000,
  "exp": 1793352300  5
}

Three properties matter here.

• Both names are in the token. sub stays the user and act names the agent, as RFC 8693 defines it. Any OAuth-aware API can read the act claim, log it and apply its own policy, for example “agents may read invoices but never approve them”. When one agent calls another, the actors are nested, so the whole chain stays visible.
• Authority only narrows. The roles in the delegated token are the intersection of what the user may do, what the agent may do and the requested scope. They are never the union, and never the owner’s roles. An agent with read-only roles stays read-only, even when it acts for an administrator.
• The token is bound to its audience. With a resource indicator (RFC 8707) the token is valid for one API only. Sender-constrained tokens with DPoP can tie it to the agent’s key as well, so a leaked token is of little use to anyone else.

Building block 4: suspension, and what it really does

When an agent misbehaves, you suspend it, in the console or through the admin API. It helps to be precise about what happens next.

• The agent gets no new tokens: no direct ones and no delegated ones. The exchange checks the agent’s status at that moment, so a token it obtained before the suspension cannot be used to start a new delegation.
• Resource servers that introspect tokens (RFC 7662) see the suspension at once, because introspection checks the agent’s live status.
• APIs that validate JWTs locally accept a token until it expires. That is how self-contained tokens work, in any identity system.

The practical rule follows from the last point: keep agent token lifetimes short, a few minutes rather than hours, and let APIs that guard sensitive actions introspect. Then a suspension takes effect within one short token lifetime everywhere, and at once where it matters most.

Audit: every agent token, issued or refused

In HelixIAM every agent token issued or refused, direct or delegated on behalf of a user, lands in the searchable audit log. Each event records the realm, the agent, its client, the user it acted for, the scope, the audience and the outcome, with the reason when a request was refused. Lifecycle changes and admin actions are in the same log, and you can stream it to your SIEM over HTTPS with HMAC-signed webhooks.

That answers the first two questions from the start of this article with a query instead of a meeting: which agent did this, and for whom.

MCP tool servers: tell clients where to get a token

Many agents reach their tools through the Model Context Protocol (MCP). An MCP tool server is an OAuth resource server, and it can describe itself with OAuth protected-resource metadata (RFC 9728): which authorization server issues its tokens and which scopes it understands. An MCP client reads that document and knows where to ask for a token.

{
  "resource": "https://tools.acme.example/mcp",
  "authorization_servers": ["https://id.acme.example/realms/acme"],
  "scopes_supported": ["invoices:read", "tickets:write"],
  "bearer_methods_supported": ["header"]
}

HelixIAM can host this metadata for a realm, or on behalf of an MCP server that points its clients to it. Together with dynamic client registration and resource indicators, an MCP client can find the authorization server, register under admin-controlled policy and obtain a token bound to that one tool server. The agent’s tool calls then run on the same identities, delegation rules and audit log as every other API call.

Workload identity for the agent’s runtime

An agent also runs somewhere: in a pod, a job or a pipeline. That runtime should not carry a long-lived secret either. With workload identity federation, a Kubernetes or CI workload presents the token its platform already signs for it, and HelixIAM exchanges it for a short-lived token. The trusted issuer, the subject and the audience must all match a registered credential, or the request is refused. There is no secret to store, copy or rotate.

The point is not that keyless workload identity is new; it is that people, agents and the workloads that run them now share one issuer, one audit log and one key policy.

Why it matters where agent identity runs

Large vendors offer agent identity too: Microsoft Entra Agent ID, Okta and Auth0 for AI Agents. They offer it mainly as cloud services, operated by US-headquartered companies, and for many organisations that is a fine choice.

For others it is not, because agent identity is becoming part of the core of how an organisation controls its systems. HelixIAM is sovereign by design:

• it runs on your own infrastructure in Europe, and you decide where the data lives;
• tokens are signed with keys held in your own HSM over PKCS#11, or in HashiCorp Vault or OpenBao Transit;
• the software comes from KubeDNA B.V., a Dutch company, which also offers deployment and operations support on your own or a European cloud, with the scope set per contract.

Agent identity then becomes one more thing you keep under your own control, next to the sign-in of your people.

How to start

You do not need to replace the identity provider you have. People can keep signing in where they do today and be brokered into HelixIAM over OpenID Connect or SAML, while HelixIAM governs the agents and workloads that act for them.

1. A technical demo. Our engineers register an agent, issue a delegated token, inspect it and suspend the agent, on a running system.
2. Your use case. We map the agents, tools and APIs you have to owners, roles and delegation rules.
3. A paid pilot. If it fits, a pilot on your own infrastructure with success criteria agreed up front.

HelixIAM is in early access, and we are now onboarding launch partners. If your agents are running on borrowed identities, a demo is a good place to start.