Agent Credentials vs. Human Credentials

Overview

An AI agent should not be treated exactly like a human user. But it should not be treated like an invisible background script either. It sits somewhere in between — an autonomous actor that takes real actions against real systems, on its own initiative or on behalf of someone else.

Nowhere does this in-between status matter more than with credentials. The keys, tokens, and accounts an agent uses to reach enterprise systems determine what it can touch, what gets recorded when it acts, and whether anyone can answer the question that always comes later: who did this, and were they allowed to?

The fastest way to get an agent working is to hand it a human's credential or a shared service account. It is also the fastest way to lose the ability to govern it. This post explains why agent credentials and human credentials are fundamentally different, and what a healthier model looks like.

Two Kinds of Credentials

Human credentials are tied to people. They live inside an identity stack that has matured over decades — login systems, single sign-on, multi-factor authentication, device posture checks, conditional access, and user access policies. All of these assume there is a person on the other end who can be challenged, verified, and held accountable.

Agent credentials are tied to non-human actors. In practice they take the form of API keys, OAuth tokens, service accounts, or delegated credentials that let an agent authenticate to enterprise systems and act. None of the human assumptions hold. There is no one to prompt for MFA, no device to inspect, no person whose behavior the access policy was written around.

The Borrowed-Access Problem

When an agent uses a human's credential directly, the agent inherits everything that person can do — and every action it takes is recorded as if the person performed it.

Consider a financial close assistant that runs under a controller's account because that was the simplest way to give it access to the general ledger. The agent can now post journal entries, reclassify accounts, and pull bank reconciliation data — the full surface of a senior finance role. When the entries it posts are reviewed three weeks later, the ledger shows the controller made them. There is no way, from the records alone, to tell which entries were human judgment and which were the agent acting on a rule it inferred.

This creates two problems at once:

• It weakens auditability. You cannot separate what the human did from what the agent did, because both wear the same identity.
• It expands risk. The agent can perform everything the user can perform, including actions far outside the narrow task it was built for.

Borrowed access feels like delegation, but it is really impersonation. The system cannot tell the difference, which means your controls cannot either.

The Shared-Account Problem

The other common shortcut is the opposite of borrowing a person's identity: giving many agents one shared service account. This is appealing because a single set of keys is easy to provision and rotate, and it sidesteps the question of agent identity entirely.

Imagine a data platform where a half-dozen analytics agents — one summarizing pipeline health, one refreshing dashboards, one flagging anomalies, one backfilling tables — all authenticate to the warehouse with the same service account. One night, a destructive query truncates a production table. The warehouse logs show the action came from svc-analytics. Which agent issued it? Nobody can say. The shared account that made provisioning easy has made attribution impossible.

Shared credentials collapse many distinct actors into one. The moment you need to attribute an action, scope a blast radius, or revoke one misbehaving agent without breaking the others, the shared account becomes the thing standing in your way.

Distinct Identity, Preserved Context

A better model gives each agent its own distinct identity and credentials, while still preserving the human context when an agent acts on someone's behalf. These two ideas work together rather than against each other.

The agent has an identity of its own, so its actions are never mistaken for a person's. But when it acts for a user — pulling a record that user is entitled to see, or submitting a request the user initiated — that user context travels with the action. The result is an audit trail that can express the full picture:

For example, an HR onboarding agent provisioning a new hire's accounts should show in the record as the onboarding agent, acting on behalf of the HR coordinator who triggered the request, exercising a provisioning permission scoped to onboarding. None of that detail survives if the agent simply logs in as the coordinator. All of it survives when identity and context are kept separate but linked.

This is what gives an enterprise both traceability — the ability to reconstruct who did what — and control — the ability to allow or deny based on the real actor.

Scoping Agents Differently

Agent credentials should also be scoped on a different basis than human credentials. A person typically holds broad access because of their job role — a procurement manager can view every supplier contract, raise purchase orders, and approve invoices below a threshold, because the role demands range and judgment across many situations.

An agent has no comparable need for breadth. It exists to perform a specific workflow, so its credential should grant only the access that workflow requires — nothing more.

A procurement intake agent that drafts purchase orders from approved requisitions does not need to read every contract in the repository or approve invoices. It needs to read the requisition, look up the relevant vendor, and create a draft order for a human to approve. Scoping its credential to exactly that surface means a prompt injection or a logic error cannot escalate into approving payments — because the credential never carried that power in the first place.

• Human scope follows the role. It is broad by design, because people handle exceptions and edge cases.
• Agent scope follows the workflow. It is narrow by design, because the agent does one defined job.

Applying a human-shaped role to an agent gives it far more reach than its task justifies. Scoping to the workflow keeps the credential's power proportional to the work.

A Different Lifecycle

Agent credentials also need different lifecycle controls, and this is where reused human credentials quietly become a liability.

When an employee leaves, their access is offboarded through familiar machinery — HR records a termination, the identity system disables the account, downstream entitlements fall away. The trigger is a person walking out the door, and the process is well rehearsed.

When an agent is retired, no person is leaving the company. A security log-triage agent that gets replaced by a newer version does not generate an HR event. Its keys do not expire on their own. If the credential was its own managed object, it can be explicitly revoked when the agent is decommissioned. If it was a borrowed human login or a shared service account, there is often nothing that clearly says this access existed only for that agent and can now be removed — so it lingers, an unowned set of keys with real reach into your systems.

In Practice

Translating the principle into operational terms, an agent credential carries a few traits that a borrowed or shared one cannot:

• •
  Unique to the agent. One credential maps to one agent, so every action is attributable to a single actor.
• •
  Scoped to the workflow. Permissions match what the task needs, not what a comparable human role would hold.
• •
  Context-aware. When acting for a user, the user's identity rides alongside the agent's, so the record shows both.
• •
  Independently revocable. The credential can be killed when the agent retires, without touching any person's access.

Concretely, the gap shows up in the audit record. Compare what each model can prove about the same warehouse query:

# Shared service account — attribution lost
actor: svc-analytics
action: DELETE FROM prod.orders WHERE ...
on_behalf_of: (unknown)
permission: (account-level, unscoped)

# Distinct agent identity — attribution preserved
actor: agent:anomaly-detector-v3
action: DELETE FROM prod.orders WHERE ...
on_behalf_of: user:dpatel@enterprise (data-eng)
permission: analytics.read-only   # <- denied: write not in scope
result: blocked

The same scoping that makes the action attributable also makes it preventable. With a workflow-scoped, read-only credential, the destructive query never executes — and if it had, the record would name the agent, the user behind it, and the policy that should have applied.

The Principle: Separation

The thread running through all of this is separation. Agent identity should be separate from human identity. Agent scope should be separate from human scope. Agent lifecycle should be separate from human lifecycle.

In plain terms: agents should not silently borrow human access, and they should not hide behind shared credentials. They should have managed, scoped, and auditable credentials of their own — provisioned deliberately, scoped to the task, and revoked when the agent's job is done.