Last week I was at the Cyber Security & Cloud Expo in Amsterdam, on a panel about the AI risk stack, and two days later I gave a talk at the first AI Salon Eindhoven at the AI Innovation Center on the anatomy of an agent. In conversations during both events, the notion of “agent identity” came up frequently. People wanted to know who an agent is, how to authenticate it, and how to give it credentials of its own. At this moment many people, and many vendors, are working on this problem, and at first glance it seems like a totally sensible thing to want. However, the more I talked about it, the more I started to doubt whether identity is what we are after; this blog post simply explores some of these ideas.

For completeness, I start with some of the more technical definitions. Identity is a stable handle for a (persistent) thing. Authentication is the check that the thing in front of you is the holder of that handle. Authorization is what the holder of a handle may do, and in most systems policies are attached to the handle. Accountability is the record of what was done under which handle, so that someone can answer for it afterwards.

That’s the technical part; let’s see how this plays out in practice.

Where do we draw the box?

In my view, to give something an identity, we have to say what the something is, and it should have some (temporal) persistence that is meaningful. Technically, an AI agent is a model coupled with a harness, the code that turns model output into actions, plus a set of tools, a system prompt, and often some memory. Now, which of these is the agent? In other words, around which of these various parts do we draw a “box” that receives the identity?

A few options are reasonable, depending on the context, but all seem flawed when thinking about long-lived, complex agentic workflows:

• If the identity belongs to the harness, then the same identity runs a different model after the provider updates it, and uses different tools after someone adds an MCP server. Thus, its behaviour might change significantly over time.
• If the identity covers harness, model version and tool set, then pretty much every change produces a new agent, and the identity is gone before anyone has learned to trust it.

So, a “small box” (harness only) is too variable in behaviour, and a “big box” leads to a large number of identities. And it quickly gets even more complex if the agent can modify its own code or tools, something coding agents do routinely and self-modifying agents do by design. In such a case the “box” is being redrawn from the inside.

Depending on the context some “boxes” might suffice, but I think finding a fully satisfying box is very hard. So, taking a step back, I started to wonder whether we really need the box at all. Why do we want agent identity in the first place?

What we use identity for

Leaving the technical definitions at the top of this post aside, in everyday use we by and large rely on identity for two things. First, we use it to know who is responsible, and second, we use it to decide what someone is allowed to do, usually on the basis of implicit expectations about how they will behave in the future.

The first use is, obviously, the technical notion of accountability. When something goes wrong, we want to know who answers for it. That is a real need, but the handle it requires is in my view not the agent’s. I am myself responsible for what my agent does, whichever model it ran that day, so the handle can be the operator or the organisation. We have very little notion of what accountability for an AI system should look like beyond that, and I will leave the question for another post.

The second use is authorization, which relies on authentication, and it is the one that interested me in our discussions. Simply put, when I know who someone is, I have expectations about what they will do, often without ever explicitly stating them, and I grant permissions accordingly. In that use, identity is a proxy for future (allowed) behaviour.

Consider the electrician who comes to rewire a part of your house. You let a stranger into your home and leave them alone with your fuse box, because they are a registered electrician, they came through a company you looked up, and they are the same person tomorrow as today. From that identity you infer a set of behaviours. You expect that they will not touch your laptop or open your mail, and that they will do the wiring to code, because they were trained to and because their registration depends on it.

This proxy works for humans because the thing behind the identity changes slowly. A person’s skills, habits and incentives are roughly the same next month as they are today. Thus, the “box” is stable, and identity carries information about behaviour for a long time.

Why the proxy breaks for agents

For an agent, as discussed above, the thing behind the identity does not change slowly. The box is not stable, and hence some of the common “human” functions of identity break down: either we are left with too many identities, or we end up with identities whose behaviour is unstable.

This means that even if we draw a box (we give some part of the agent system an identity) and authenticate it well, the inference from identity to behaviour is likely to decay quickly. Knowing that this is the same agent as yesterday tells me much less about what it will do today than knowing that this is the same electrician. For a general and changeable agent, identity does not give us a reliable expectation about behaviour, which is what we wanted it for.

Flipping it around

Now, in the limit, if identity is solely a proxy for behaviour and that proxy fails, then perhaps we should state the behaviour we expect explicitly rather than infer it. Instead of asking who an agent is and what we can therefore expect from it, we say what we expect at some specific point in time and ask the agent to prove that it is held to it.

Concretely, that means writing down the rules an agent has to follow when it acts on my behalf or inside my organisation. For example, it may read customer records, but after it has read them it may not send anything outside our domain without approval; it may run code, but not change its own configuration; it may call a given API, but not more than a given number of times. These are statements about behaviour, and they do not depend on which model is behind the agent or which tools were added this morning.

This replaces the proxy only if the rules are checked at the point where behaviour happens, which is the harness, before each action runs, and only if the agent can prove that the rules were active, so that the other party does not have to take its word for it. When both hold, I think we no longer need to know who the agent is in order to know what it will do, because I wrote down in advance what it may do and the check is in place.

In more technical access-control terms, authorization is normally attached to the identity in advance; if the identity will not hold still, we can attach the authorization to the task instead, at the moment the agent starts working for us. In some sense, popular short-lived access tokens already do this for a single request, by granting scopes for a session rather than trusting a long-lived identity. The difference is that a token is checked request by request, by each service separately, while the rules we would want for an agent are about the full sequence of its actions within a task, which only the harness sees, and for which the harness would thus have to prove compliance.

What we build at Kyvvu

This is, perhaps in hindsight, more or less what we build at Kyvvu. A manifest is our name for a set of behavioural policies: rules over the ordered actions of a task. The Kyvvu engine (kyvvu-engine) evaluates every action the harness is about to take against the manifest and the history so far, and blocks or gates it before it runs, without involving a model in the decision. The trace of the task records which manifest was active and what was decided. The actions themselves are described in the Agent Action Grammar, an open vocabulary, so that the same manifest applies to an agent built with LangChain, a CrewAI crew or a coding agent, and so that anyone can check what an integration covers.

Today this works for agents you build or run yourself. The step we are working towards is the one the electrician example asks for, in which an organisation writes its rules once and imposes them on any agent it interacts with, including agents built by someone else. For that, the agent builder includes kyvvu-engine in their harness and lets the end customer supply the manifest. We have started building the integrations and the test structure that make this possible, and we will write about it when it is further along. But one interesting way to think about it, after all the discussions, is that we remove identity from the problem and swap it for proven, “just in time” compliance with a set of behavioural rules.

Now, I am not arguing that identity is useless. Accountability still needs a handle, and we still need to know who operates an agent. But for authorization, the sense of control we are really after, I think we might be asking the wrong question. The question is not who this agent is, but which rules it runs under and whether it can prove it.