Agent Identity

Agents are becoming real software actors, not just chat sessions. Once they act on systems, the core problem shifts from capability to

April 17, 2026
work

Agent Primitives Need Identity First

Everyone building agents eventually reaches the same list.

  • Memory.

  • Tool use.

  • Schedulers.

  • Sandboxes.

  • Observability

  • Permissions.

  • Gateways.

  • Auth.

All of them matter.

But one of them sits underneath the rest.

Identity.

Not personality. Not naming. Not anthropomorphic fluff.

Operational identity.

The kind that answers:

  • who is acting

  • on whose behalf

  • with what authority

  • under what constraints

  • against which systems

  • with what audit trail

  • until when

That is the primitive.

Most people only realize this once the agent starts touching real systems.

The shift

A lot of the current agent stack is still shaped by demo-era thinking.

The model is treated as the product.

Everything around it is treated as plumbing.

That breaks the moment agents become long-running, asynchronous, and tool-using.

Then the hard problem stops being capability.

It becomes authority.

Not can the model do this?

But:

  • should this agent be allowed to do this?

  • is it acting for a user, a team, or itself?

  • where did that permission come from?

  • how is it bounded?

  • how do we revoke it?

That is not a prompt problem.

It is an identity problem.

The market is solving thinner slices

One part of the market handles auth plumbing and tool connectivity.

Nango is the cleanest reference point. Composio, Arcade, Pipedream Connect, and Merge Agent Handler sit nearby. They help agents connect to external systems without everyone rebuilding OAuth in a dark basement. Useful. Necessary. Still only one slice.

Another part handles secrets and credential brokering.

OneCLI and dotenvx are examples. Their core idea is simple: do not hand raw credentials to agents any more than necessary. Encrypt them, broker them, inject them at the edge. Better hygiene. Still not identity.

A third part is forming around MCP gateways and control planes.

Runlayer, MintMCP, Portkey, TrueFoundry, Smithery Connect. These products show up once people want centralized access control, policy, and audit over tool use. Important layer. But identity often appears here as a gateway feature, not the underlying abstraction.

Then there is the more interesting category: identity and authorization proper.

Okta, WorkOS, Aembit, and increasingly 1Password are all circling the same idea: non-human actors need first-class policy, lifecycle, and audit. Clawvisor points at the runtime side of the problem: not just can the agent connect, but should this exact action be allowed right now for this purpose.

That is much closer to the real problem.

Credentials are not identity

This is where a lot of systems go wrong.

They confuse access with actorhood.

A token can tell you that something is allowed to call an API.

It cannot tell you:

  • which agent is using it

  • whether it is acting for a user

  • whether the action matches the approved task

  • whether that authority should still exist

  • what runtime boundary it crossed

Credential management matters.

But it is downstream of identity.

It tells you how access is exercised.

It does not tell you how authority is modeled.

Every serious primitive depends on identity

Scheduling

A scheduler is not just “run this later.”

It is “run this later as whom.”

If an agent wakes up tomorrow and sends an email, updates a document, or mutates production state, the execution needs a durable identity context.

Without that, scheduling is just delayed privilege.

Observability

Logs are useless when the actor is vague.

A real audit trail needs to answer:

  • which agent took the action

  • on whose behalf

  • through which runtime

  • with which delegated scope

  • using which downstream identity

  • under what policy

Without identity, observability becomes structured confusion.

Tool use

Most systems stop at connection-time authentication.

The harder question is runtime authorization.

Not “can this agent connect to GitHub?”

But:

  • can it read but not write?

  • can it draft but not send?

  • can it access this data only in this workflow?

  • can it escalate when it exceeds its authority?

That is where identity meets policy.

Orchestration

The problem gets sharper in multi-agent systems.

If one agent invokes another, what propagates?

  • user identity

  • task scope

  • runtime context

  • approval state

  • permission boundary

  • audit lineage

Without identity, delegation is just distributed ambiguity.

The missing abstraction

The underbuilt part of the market is a clean model for:

user → agent → runtime → tool/account → action

That is the chain production systems actually need.

A user authorizes an agent.

The agent runs somewhere.

That runtime reaches a downstream system.

An action happens.

Most products solve one edge of that graph:

  • token storage

  • OAuth orchestration

  • secrets brokering

  • tool calling

  • gateway policy

  • enterprise governance

Very few model the full chain well.

That is why the category feels active but still unsettled.

There is plenty of product motion.

The abstraction is still forming.

Why this matters now

For a while, agents could live in a low-stakes world.

Prompt in.

Response out.

Maybe a tool call in the middle.

That world is ending.

Agents are increasingly:

  • asynchronous

  • persistent

  • event-driven

  • tool-using

  • production-facing

Once that happens, human identity models start to look incomplete.

Not useless. Incomplete.

A user session is not enough.

A service account is not enough.

A long-lived API key is definitely not enough.

Agents need operational identity that can express delegation, context, runtime boundaries, and revocation.

The reframe

The cleanest way to think about agent primitives is:

  • memory stores context

  • tooling exposes capability

  • observability records behavior

  • schedulers carry intent across time

  • identity stores authority

That last one is the binding layer.

Without it, the rest gets harder to reason about.

With it, auth, policy, audit, and delegation start to compose cleanly.

Agent primitives are not just things that make models more capable.

They are the pieces that make software actors legible.

And the primitive that makes an actor legible is identity.

Not because it is fashionable.

Because the moment an agent can act, identity becomes the thing that tells the rest of the system what that action means.