Give your agents an identity!

The rise of agentic systems raises a new architectural question: knowing who acts is no longer enough. We also need to know on whose behalf, with what authority, in which context and for how long.

A few weeks ago, we used the image of a building in these pages.

With eBPF, we looked at the turnstile: the very concrete point where a security rule stops being an intention and becomes an enforced control. A register may state perfectly clearly that a door must remain closed; there still needs to be a mechanism capable of preventing it from opening.

Then, with SPIFFE, we looked at the badge. In a distributed system where Pods disappear, instances move between machines and IP addresses no longer provide a reliable identity, recognising a service means separating what it is from where it runs. A workload's identity must survive changes to its environment.

Both questions remain relevant with the arrival of AI agents.

But a third now joins them.

What happens when the entity presenting the badge is no longer simply a program following predetermined logic, but a system capable of choosing some of the actions needed to fulfil a mission?

The distinction may seem subtle. Yet it changes the problem profoundly.

A payment service has an identity because it is a component of the enterprise information system. An agent also has a technical identity, but it can receive a mission from a user, select tools, query several data sources, call other agents and compose a sequence of actions that was not necessarily determined when it was deployed.

The question is therefore no longer simply:

Which workload is calling this API?

It is gradually becoming:

Which agent is acting? On whose behalf? For which task? With what authority? Until when? And how much of that authority can it delegate in turn?

A trust architecture for agentic systems is beginning to take shape around these questions.

An instruction to the model is not a security boundary

As long as agents remain confined to demonstrations or text generation, this question may seem theoretical.

It immediately becomes practical when we open the doors of the enterprise information system to them.

Email, SharePoint, CRM, document repositories, GitHub, ERP, databases or cloud infrastructure: as an agent acquires tools, the nature of its potential errors changes. A bad answer is no longer merely inaccurate text. It can become an action.

Research into agent security has already highlighted this difference.

The AgentDojo benchmark, presented at NeurIPS 2024, studies agents that can use tools in scenarios resembling real applications. It shows, in particular, that information consulted by an agent — an email, a page or a tool response — can itself contain a hostile instruction and redirect its behaviour.

Agent Security Bench, published at ICLR 2025, extends this analysis to different environments, tools and attack vectors. Here too, vulnerabilities are not confined to the model: they emerge in the way the agent processes context, uses its tools or stores information.

These studies do not demonstrate that agents are inherently uncontrollable.

They remind architects of something much more useful:

a decision produced by a model is not an authorisation decision.

An agent may reasonably conclude:

“To complete this task, I need to modify this resource.”

That does not mean:

“I am authorised to modify this resource.”

This seemingly simple distinction should become a founding principle of agentic systems.

It also brings us back to the problem discussed in our article on eBPF: defining a rule and having a mechanism capable of enforcing it are two different things.

With agents, we now need to add an intermediate step: deciding whether the proposed action should actually be authorised.

NIST is beginning to formalise the problem

This development is no longer being discussed only in laboratories or by software vendors.

In February 2026, NIST's National Cybersecurity Center of Excellence opened a consultation on the identity and authorisation of software and AI agents. More than 600 contributions were received from industry, government and academia.

The summary of comments, announced on 29 September 2026, is particularly interesting because it does not outline a new IAM product. Instead, it reveals a degree of continuity with existing architectures.

Contributors largely favour reusing established mechanisms: workload identity, OAuth, authorisation policies, Zero Trust, short-lived credentials and contextual decisions.

In other words, the arrival of agents does not make existing IAM investments obsolete.

It puts them to the test.

This is an important distinction for businesses.

The issue is not necessarily to create an “agent directory” isolated from the rest of the information system. It is to allow existing identity infrastructure to represent relationships it has so far modelled imperfectly: delegation, the context of a mission, the duration of an authorisation, or the chain connecting a user to the action ultimately performed.

This summary reports contributions and prepares a demonstration project; it is not a final standard.

This development directly extends the Zero Trust movement.

In its work on cloud-native architectures — SP 800-207A, NIST already recommended shifting trust from network location to service or workload identity. This was precisely the subject we explored with SPIFFE: no longer treating an IP address or execution node as sufficient proof of identity.

The agent now adds another dimension.

Knowing its identity is not enough.

We need to know the authority it carries.

From the badge to the mandate

This is probably the best way to extend the image used in our previous article on SPIFFE.

SPIFFE gives the workload something resembling a verifiable badge.

It answers the question:

Who are you?

But when an agent arrives at a business application, that information is not always enough.

We also need to answer:

Why are you here?

On whose behalf are you acting?

What are you allowed to do within this specific mission?

The badge now needs to be accompanied by a mandate.

This development also appears in the SPIFFE roadmap of 18 August 2026. The project is working on mechanisms for carrying context throughout a transaction: the origin of a request, the principal on whose behalf an operation is performed, and its purpose.

This is significant.

SPIFFE initially helped address a difficulty in distributed architectures:

how do we consistently recognise a workload in an infrastructure where everything is ephemeral?

Agentic architectures now raise a complementary question:

how do we preserve the history of authority as an action passes through several workloads and agents?

This is the transition from identity to delegated authority.

Alice, her agent and the ERP

Let us take a much more concrete example.

Alice works in procurement. Her company provides an agent that can analyse approved quotations, check certain information and prepare the corresponding purchase orders in the ERP.

Alice asks it:

“Prepare the purchase orders for the quotations approved today.”

The simplest technical solution would be to let the agent use Alice's identity or credentials directly.

The system would work.

But a fundamental piece of information would have disappeared.

When the ERP received the request, it would see Alice.

It could no longer distinguish an operation she performed herself from one selected and executed by software acting on her behalf.

Yet these two situations are not equivalent.

The architecture should preserve several layers of identity:

Alice
   │
   │ assigns a mission
   ▼
Procurement Agent
   │
   │ runs as
   ▼
Workload procurement-agent-prod
   │
   │ receives temporary authority
   ▼
ERP

Alice remains the principal who initiated the request.

The Procurement Agent is the actor entrusted with a mission.

The workload represents the software instance that actually executes the operation.

Finally, the credential used with the ERP embodies the authority granted for that particular action.

This distinction is less exotic than it may appear.

Through RFC 8693 on Token Exchange, OAuth already provides a way to distinguish the subject, on whose behalf an operation is performed, from the actor, who actually performs it.

In other words, part of the vocabulary needed for agents already exists.

This is also the idea behind the IETF's recent work on AIMS — AI Identity Management System: rather than building an entirely new identity stack specifically for agents, compose existing workload identity and delegation standards.

AIMS is currently an Internet-Draft of the WIMSE working group, rather than a published RFC.

For a CTO, this is an important conclusion.

Introducing agents into the enterprise information system does not necessarily mean rebuilding IAM.

Above all, we need to stop conflating the user, the agent and the workload that runs the agent.

An identity may last; its power should last much less

This distinction leads to a second principle.

An agent's identity may be relatively stable.

Its authority should often be ephemeral.

A procurement-agent-europe may exist for years. The company can associate it with an owner, a purpose, a version, a security policy or a responsible team.

By contrast, the authorisation allowing it to read three quotations and prepare a purchase order has no reason to persist for months.

This is precisely one of the points emerging from NIST's recent work: combining a durable identity anchor with much shorter-lived credentials and permissions.

For our Procurement Agent, the authorisation might conceptually look like this:

Agent       : procurement-europe
Principal   : Alice
Mission     : preparing purchase orders for 6 October
Resource    : ERP / purchase orders
Action      : creating a draft
Limit       : €20,000
Expiration  : 09:17, Paris time

At 9:18, this authority is no longer valid, provided the enforcement point actually checks the expiration before authorising the operation.

The agent still exists.

Its power no longer does.

This way of thinking may seem more complex than the traditional service account with a permanent role. Yet it is much better suited to systems capable of acting with a degree of autonomy.

Here again, the primitives are not all new. OAuth already allows us to restrict a token to a particular resource — RFC 8707 or express authorisation requests richer than a generic scope — RFC 9396. Interpreting and enforcing them remains the responsibility of the relevant authorisation servers and applications.

Agents do not always create new mechanisms.

Above all, they make it much more costly to misuse those we already have.

When agents delegate to other agents

The difficulty increases when one agent calls another.

We recently discussed a different risk in multi-agent architectures through semantic drift: two agents may each reason correctly according to their own representation of a problem, yet still produce an incorrect collective decision as their interpretations gradually diverge.

Identity clearly does not solve this semantic difficulty.

But it can prevent uncontrolled permission propagation from making it worse.

Let us return to our scenario.

The Procurement Agent prepares a purchase order, then calls a Finance Agent to check whether the cost centre has sufficient budget.

The Finance Agent has no reason to inherit the right to create a purchase order.

The chain should instead look like this:

Alice
   ↓
Procurement Agent
Prepare a purchase order ≤ €20,000
   ↓
Finance Agent
Read the relevant budget
   ↓
Finance ERP
Read only

At each delegation, authority narrows.

The summary of comments published by NIST uses the term attenuation to describe this property: a sub-agent should not automatically receive every privilege held by the agent calling it.

This rule seems obvious.

Yet it is absent from many current systems, where the same secret or technical account circulates between several components.

The arrival of agents turns previously tolerated architectural debt into a much more visible risk.

For a company considering multi-agent systems, a very simple question therefore becomes revealing:

When an agent delegates its task, does it also delegate all its permissions?

If the answer is yes, the problem is probably architectural before it is even related to AI.

The model proposes; the architecture decides

This is where we return to the turnstile.

An agent can build a line of reasoning, determine that an action appears necessary and call a tool.

But it should never be the judge of its own authorisation.

The model proposes.

A policy decides.

An enforcement mechanism applies that decision.

This separation is probably one of the most important patterns in agentic architectures.

In particular, it preserves a deterministic component in a system whose reasoning may be probabilistic.

Imagine an agent wants to delete a test database.

The model can explain why the operation seems appropriate.

But the policy can simply state:

DELETE database
IF environment = production
THEN deny

No reasoning by the model should be able to turn this prohibition into an optional recommendation.

This is what makes recent work on NVIDIA OpenShell interesting.

OpenShell seeks to move certain controls outside the agent process: access to files, processes or the network can be restricted by the runtime environment itself.

The Policy Prover addresses another problem in parallel: checking certain properties of the defined policy. Its guarantees are limited to the behaviours and features represented in its model; a verified policy alone does not prove that the runtime environment correctly enforces it.

This brings us back to the reasoning we began with eBPF:

describing a permission, checking that it satisfies certain constraints and actually enforcing it are three different functions.

Conflating them would mean treating a “no entry” sign and a locked door as equivalent guarantees.

What about an existing enterprise information system?

This is probably the most important question for a business leader.

Ideal architectures are relatively easy to draw when everything is modern: cloud-native workloads, OAuth everywhere, well-designed APIs, centralised policies.

But real enterprise systems rarely look like that.

They contain old ERPs, SOAP applications, databases protected by technical accounts, historical scripts, SaaS applications, several directories, API gateways and sometimes multiple successive generations of architecture.

Waiting for all of this to be modernised before introducing agents would be unrealistic.

The most pragmatic path is therefore to modernise the boundaries before modernising the entire application estate.

Take a legacy application that can only accept a technical account.

The mistake would be to hand that account directly to the agent.

Instead, we can introduce an intermediary:

Agent
   │
   │ identity + delegation
   ▼
Identity / Access Broker
   │
   │ policy
   │ credential translation
   ▼
Legacy application

The broker understands the agent's modern identity and the mission entrusted to it.

It checks authorisation.

Then, behind that boundary, it uses the credential expected by the legacy application.

The agent never directly accesses the legacy secret.

This approach has a considerable advantage: the legacy application does not itself need to become “agent-compatible”.

It remains what it is.

Modernisation first concentrates on the points of passage.

For many businesses, this pattern could provide a much more realistic path than immediately replacing legacy applications.

The next problem: explaining afterwards why the action was permitted

Once identity and authority are properly separated, another difficulty appears.

After an incident or during an audit, knowing that:

“The Procurement Agent created the purchase order at 9:12”

will probably no longer be enough.

We will need to reconstruct the full history:

• who initiated the request;
• which agent received the mission;
• which workload executed it;
• which authority was delegated to it;
• which policy authorised the operation;
• and in which context that decision was made.

This is where identity challenges gradually meet the questions of provenance and attestation that we have also begun exploring in our work on CI/CD chains.

We had already encountered a comparable distinction there.

Producing a signature or an attestation is not enough if nobody verifies it before using the artefact. Likewise, knowing an agent's identity is not enough if we cannot demonstrate under which authority it performed an operation.

In both cases, trust does not rest on an isolated object.

It rests on a chain of evidence.

Agent identity is gradually bringing together disciplines long treated separately: IAM, workload identity, authorisation, runtime security, observability, provenance and attestation.

That convergence probably deserves an article of its own.

What a CEO or CTO should really ask

At this stage, a business leader does not need to choose between SPIFFE, OAuth Token Exchange or different policy engines.

The technology can come later.

The first question is much simpler:

If we allow an agent to act in our enterprise information system tomorrow, can we still explain precisely what power we have given it?

A CTO should be able to follow a readable chain:

user or organisation → agent → workload → delegation → permission → action.

And that chain must remain intelligible when several agents are involved.

Can we distinguish the agent from the user it represents?

Can we revoke the agent without blocking the user?

Do its permissions disappear when the mission ends?

Does a sub-agent receive fewer permissions than its parent?

Can a sensitive application refuse an operation despite the agent's decision?

Can we explain afterwards why the operation was authorised?

These questions are useful beyond future AI projects.

They also provide an excellent indicator of the current state of the enterprise information system.

Shared technical accounts, persistent secrets, excessively broad permissions, an inability to identify the actual actor behind an API: agents do not necessarily create these weaknesses.

They make them much harder to accept.

From the turnstile to the chain of authority

Our reflection began with doors.

With eBPF, we sought the point where a policy could actually become a control.

With SPIFFE, we added the badge that lets us recognise a workload in a constantly changing environment.

Agentic systems now require another piece of information to be added to that badge:

the mission.

Who acts?

On whose behalf?

For what purpose?

With what authority?

And until when?

The work currently being conducted by NIST, the IETF and SPIFFE does not yet amount to a universal architecture for agent identity. The field is young, standards are evolving and several technical choices remain open.

But a structure is gradually emerging:

IDENTITY
    ↓
DELEGATION
    ↓
AUTHORISATION
    ↓
ENFORCEMENT
    ↓
EVIDENCE

None of these building blocks is really new.

Workload identity, OAuth, mTLS, policy engines, gateways, attestations and runtime controls existed before agents.

The novelty lies elsewhere.

We now need to make them work as a coherent chain.

With cloud-native systems, we gradually learned to stop inferring a system's identity from its position on the network.

Agents now require us to take another step:

to stop inferring its authority from its identity alone.

Knowing who acts will remain essential.

But in a system where software can receive missions, delegate tasks and make some of its own decisions, that will no longer be enough.

We will also need to know where its power comes from, how far it extends and who can stop it.