An agent in human's clothing

June 5, 2026 8 min read

Enterprise security already knows how non-human identity goes wrong.

A service account gets created for a workflow. The original owner changes teams. The credential survives. Months later, the account can still read data, write to systems, and call APIs no one remembers authorizing.

That was already a hard problem when the non-human identity was deterministic automation.

Agents make it harder because they are not just scheduled jobs or static integrations. They decide what to do next.

These autonomous agents should not borrow identities from other humans. They need governed non-human identities that inherit from humans, narrow by task, and expire by default.

TL;DR

• Agents are non-human identities, but not ordinary service accounts. A service account executes a known workflow. An agent chooses a path through tools, data, and permissions.
• Borrowed identity creates overreach. An agent that inherits a user's full token, a shared API key, or a standing service account breaks least privilege the moment the credential is handed over.
• Good agent identity is scoped, delegated, and just-in-time. The agent should have its own governed identity, tied to a human owner, constrained by task, runtime, policy, and time.

Service accounts were built for automation, not agency

The classic non-human identity model was built around automation that was predictable enough to pre-authorize.

A CI job publishes an artifact. A backup service reads a bucket. A billing integration writes invoices. Even when the permissions are too broad you know exactly how they will be used.

Agent workflows are different.

A coding agent starts with "fix the failing test" and may read the repo, inspect environment variables, install packages, and run shell commands.

A support agent starts with "resolve this escalation" and may read a ticket, query account records, and update CRM notes.

The new permission question is what access should this agent have...

• for this human
• in this task
• from this runtime
• at this moment

The failure mode is borrowed access

Most agent deployments start with borrowed access because it is the quickest way to get started.

The agent uses the user's browser session, a broad OAuth token, or it writes through a service account that already has access to the downstream system.

The result is a familiar pattern:

human delegates work to agent
  -> agent borrows broad credential
  -> credential unlocks more than the task requires
  -> downstream systems see the borrowed identity
  -> policy cannot tell what the agent should have been allowed to do

This creates two problems at once.

First, the agent is overprivileged. It can reach whatever the borrowed credential can reach, even when the task only needs a narrow slice of that access.

Second, the agent is under-identified. The downstream action may look like the user, the service account, or the app integration. It does not clearly look like a governed agent operating under constrained delegation.

That is the worst of both worlds: too much access and not enough control.

What good agent identity requires

A governed agent identity has to control what the agent can do before it acts, while still giving it enough access to actually get the task done.

1. A dedicated agent identity

Each meaningful agent should have its own identity, separate from the human, the device, and the downstream service account.

That identity does not replace the human. It gives security teams a stable control surface for the agent itself: its integration family, owner, runtime, tools, policy set, risk tier, and lifecycle.

"Maya using CRM" and "Maya's refund agent using CRM" should not collapse into the same security object.

2. Human binding

Agent identity still needs a human anchor.

An agent may be non-human, but enterprise accountability is not. A human launched it, configured it, scheduled it, approved it, or owns the workflow it performs.

That human binding matters for delegation, review, education, access inheritance, and ownership. Without it, the organization is back to orphaned service accounts, just with more autonomy.

3. Least-privilege cascade

An agent should never be able to do more than the human it acts for. The responsible human's entitlements are the ceiling, and delegation can only narrow from there, never expand.

That ceiling caps what is possible. What the agent actually receives should be only what the task in front of it needs, which is usually a small fraction of what the human could do. A support agent resolving one refund needs to read and adjust that single account, even though the human can export every account in the system. A research agent summarizing a document needs read access to that document, even though the human can also write to the source it came from.

The model has to enforce both bounds: the human caps what is possible, and the task sets what is actually granted.

4. Short-lived, just-in-time credentials

Long-lived credentials are how non-human identity sprawl becomes permanent.

Agents should prefer just-in-time (JIT) credentials: temporary and scoped, minted when the task starts and expired when it ends or when the approved window closes. If a credential has to persist, it should have a clear owner, purpose, rotation path, and kill switch.

The lifecycle is part of the control. Creation, use, refresh, rotation, revocation, and retirement should all be visible.

5. Runtime-aware enforcement

Identity cannot ignore where the agent is running.

An agent running inside a managed endpoint with current controls should not be treated the same as an agent running in an unknown local environment. A hosted sandbox, CI runner, developer laptop, browser extension, and MCP server all have different trust boundaries.

Good policy asks not only who the agent is, but where it is acting from.

6. Action-level policy

Finally, agent identity has to reach the action layer.

It is not enough to say this agent can access the CRM. The question is whether this agent, for this user, in this task, from this runtime, can perform this action on this data.

That is where identity becomes governance instead of inventory.

The access loop has to scale past humans

Scoping access this tightly raises an obvious question, and the answer decides whether the model holds at scale. An agent that only takes access when the task needs it will ask for access constantly. A coding agent fixing a bug might need a new repo, a staging credential, and a read scope on an internal service inside a single run. Multiply that across thousands of agents working at once, and the requests arrive faster than any person can review.

There are two ways that goes. Either every request routes to a human, the approvals back up, and the work stalls. Or, the more common ending, teams hand agents broad standing access so the requests stop, throwing away least privilege exactly where autonomy makes it matter most.

Keeping least privilege at agent scale means automating the grant. Most in-scope requests should be approved by policy on their own: this agent, for this human, on this task, may take this scope, for this long. The uncertain ones escalate to a person, every grant expires by default so automation never quietly rebuilds standing access, and humans stay in the loop only where the decision is genuinely in doubt. Least privilege survives because the granting finally keeps pace with the agents.

The counterargument: just use delegated authorization

There is a reasonable counterargument: agents do not need their own identity because they should simply use delegated user authorization. The user grants access. The agent acts through that grant. Downstream systems keep their existing permission model.

Delegated authorization is necessary. It is not sufficient.

Delegation answers whether the user is allowed to let something act on their behalf. It does not fully answer what kind of actor is receiving that delegation, how that actor behaves, or which tools it can chain together.

An agent identity does not have to replace delegated user authorization. The two should work together:

user delegation says what the human may delegate
agent identity says what this agent may do with it
policy says whether this action is allowed now

That distinction is what prevents agent access from becoming a dressed-up user session.

Closing

Agents are identities that act.

They are not just prompts. They are not just apps. They are not just service accounts. They are delegated, tool-using actors operating inside enterprise systems that were not designed for autonomous work.

The old non-human identity model was:

service account -> standing permission -> automated action

The agentic identity model has to be:

human -> governed agent identity -> task scope -> just-in-time credential -> policy decision -> action

That is how enterprises get the productivity of agents without recreating the worst parts of service-account sprawl.

Agents should be allowed to work. They just should not borrow identity invisibly.

If you're building toward governed agent adoption and want to compare notes, we would be glad to talk.