Agent Credentials vs. Human Credentials

Overview

An AI agent occupies an odd spot in the identity model most enterprises already run. It is not a person, so the human toolkit doesn't apply to it in any way that still means what it's supposed to mean: there's no one to prompt for MFA, no device posture to check, no conditional-access rule written with it in mind. It is not an invisible background job either, because it takes actions with real consequences, sometimes on its own initiative.

Most teams solve the access question the fast way. Point the agent at a human's login, or drop it onto a shared service account that's already lying around. Both choices get an agent working by lunchtime. Neither survives the first serious question a security reviewer asks about it.

This is the definitional question underneath the rest of the credential-management family: rotation schedules, vaults, and monitoring dashboards all assume the credential they're operating on already belongs to one agent and no one else. Skip that assumption and the machinery built on top of it stops meaning what it's supposed to mean.

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, user access policies. All of it assumes 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 mistake is reusing the human toolkit for the non-human case. Controls designed for a person, layered onto a credential standing in for something that isn't one, don't fail loudly. They just quietly stop proving anything.

The Borrowed-Access Problem

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

Take a hypothetical 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. It's really impersonation. The system can't tell the difference, so your controls can't either.

The Shared-Account Problem

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

Picture 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 is the thing standing in your way.

log shows the human -----> unanswerable |-- share one service account -> log shows "svc-account" -> unanswerable |-- issue its own identity ----> log shows agent + user --> answerable, scoped -->

Figure 1 — Three ways to give an agent access, and what each one leaves behind in the log.

Distinct Identity, Preserved Context

A better model gives each agent its own distinct identity and credentials, while still preserving the human context when it 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:

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.

We're not aware of a way to get a trustworthy audit trail without that separation. It's 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.

Take a hypothetical procurement intake agent that drafts purchase orders from approved requisitions. It doesn't 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 can't escalate into approving payments, because the credential never carried that power in the first place.

• Human scope follows the role. It's broad by design, because people handle exceptions and edge cases.
• Agent scope follows the workflow. It's 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 hypothetical security log-triage agent that gets replaced by a newer version doesn't generate an HR event. Its keys don't expire on their own. If the credential was its own managed object, it can be explicitly revoked the moment the agent is decommissioned. If it was a borrowed human login or a shared service account, there's 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.

Revoking is also not the same everywhere at once. Killing a credential in your own identity system stops your systems from presenting it, but if the underlying token was ever handed to a downstream provider directly, that provider may keep honoring it until something also tells it to stop. Treat "revoked here" and "revoked everywhere" as two different claims, and only assert the second one when you've actually checked.

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. If it somehow had, the record would still 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 separate from human identity. Agent scope separate from human scope. Agent lifecycle separate from human lifecycle.

In plain terms: agents shouldn't silently borrow human access, and they shouldn't 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. Everything downstream, storage, rotation, monitoring, only works once that foundation is in place.