AI Agent Credentials: Non-Human Identity, Scopes, and Revocation

A new hire’s first day ends with a login that has their name on it. An agent’s first day usually ends with somebody else’s. The engineer who wired it up pasted in a token, the token worked, and the agent has been that engineer ever since: the same reach, the same name on every log line, and the same off switch, which nobody will pull because pulling it locks the engineer out too.

AI agent credentials are the second of the six AI operator security controls. The control is that the agent acts under its own scoped identity, never a borrowed human login. This guide unpacks that sentence for the buyer: what a non-human identity is, why the borrowed login fails, what short-lived tokens and revocation have to look like, and what to put in the RFP. AI agent permissions covers the first control, whose allow-list is attached to the identity this one supplies.

The series rests on one idea. AI operator security is being safe from the AI agents you operate. Most AI security protects you from someone else’s model. AI operator security protects you from your own agents. The essay that introduced the term is AI operator security; the AI agent security checklist is the index this guide hangs from.

Why a Borrowed Login Fails

The fastest way to connect an agent is to give it a credential that already works: an engineer’s API key, an admin’s OAuth session, the integration token nobody rotated after the last project. Each was issued to someone else for some other purpose, and each works on the first try, which is the whole problem.

In April 2026 a Cursor agent at PocketOS, working on a routine task in staging, hit a credential mismatch. It did not stop. It went looking, found a Railway API connection it could reach, and deleted the production volume and its backups in nine seconds. The API had nothing to do with the task. The backups were on the same volume. Railway later recovered more recent data, and the founder’s account of the cause fits in two lines that belong in every RFP: no confirmation step, no environment scoping.

Nobody had decided the agent should be able to delete a volume. Nobody had decided it should not. The credential decided, because it was the only thing in the room with an opinion about reach, and its opinion was everything the account can do. That is what a borrowed login is. Not a security hole, exactly. A delegation nobody signed.

Three things go wrong at once. Reach: the agent inherits every permission the person has, including the ones the person forgot. Record: every call lands in the log under the person’s name, so when the agent deletes something, the first suspect is an employee. Revocation: you cannot switch the agent off without switching the person off, so nobody does. The OWASP Top 10 for LLM Applications files the mistake under excessive agency, names excessive permissions as a cause, and warns specifically against an extension that reaches downstream systems with a generic high-privileged identity rather than as a specific user with the minimum privileges necessary. The prevention is the minimum scope, issued to the thing doing the work.

A narrow credential is also what limits what a prompt injection can reach, the argument of the fifth control, prompt-injection defense for AI agents: the attacker who talks the agent into exporting the table still needs a credential that can.

The Agent Is a Service Account

The fix is not new. Enterprises solved this for software long before agents arrived, and the solution has a boring name: the service account. NIST SP 800-53 lists service accounts among its example account types and asks the same things of every account: a named manager, documented access authorizations, monitored use, a periodic review, and alignment with termination and transfer. None of that was written with agents in mind. All of it applies.

A non-human identity for an agent is exactly that: an account in your directory, or the vendor’s for your tenant, that belongs to software rather than a person. It has an owner, who is a person and accountable. It has a type, so the directory knows it is not an employee. It has scopes, which are the job and nothing else. It has credentials with a lifetime, and an off switch that affects it alone. Its own name, its own scopes, its own off switch. Four of the ten entries in the 2025 OWASP Non-Human Identities Top 10, improper offboarding, overprivileged identities, long-lived secrets, and human use of a non-human identity, describe the borrowed-login problem from one side or the other.

One distinction matters, because vendors will raise it. An assistant that acts for a person, reading that person’s inbox or filing that person’s expenses, should act with that person’s authorization. That is still the agent’s own credential: a token issued to the agent’s client on the user’s consent, with named scopes, revocable by the user or an admin without touching the user’s own login. OAuth exists for this, and the MCP authorization specification (current revision, 2026-07-28) builds on it. The borrowed login is the other thing: the person’s own secret, a password, a personal key, or a copied session, in the agent’s hands and indistinguishable from the person. The test that separates the two is short. Can you revoke the agent without revoking the person, and can the log tell them apart? Two yeses and the agent has an identity. One no and it has a disguise.

The right-hand column is the directory entry, and it is the artifact. A vendor who can export it for your agent has the control; one who answers with the name of the engineer who set it up does not.

Scopes per Resource, Verb, and Sensitivity

Scopes are where this control meets the first one. The allow-list in AI agent permissions is the set of tools the server exposes to the agent; the scopes on the credential are the operations the token may authorize. Two lists, one job. When they drift apart, the wider one is what the agent actually has.

The design rule is the one in MCP auth and security, and this guide will not repeat the taxonomy: a scope per resource, a verb within each resource, and a separate line for anything that deletes, exports, merges, or pays. Buyers do not design it; they read it, with three questions. Is there more than one scope? A single scope called access is a master key with a label. Are reads separate from writes? Does anything irreversible share a scope with anything routine? A tickets:write scope that quietly covers delete is not narrow, however short the list looks. OWASP’s entry on overprivileged non-human identities puts the prevention in one line: each identity gets only the permissions essential for its specific tasks, and administrative privileges only when absolutely necessary. For an agent, absolutely necessary is almost never.

Scopes also decay. A tool list grows, a scope is widened for the new tool, and nobody narrows it when the tool is retired. The fourth control, MCP tool versioning, is the notice that the tool list changed; the scope review is what you do when the notice arrives, on the same quarterly cadence your security team already runs for service accounts.

Short-Lived Tokens and Three Revocation Paths

A credential has two clocks. One is how long it works on its own. The other is how fast you can stop it. Buyers ask about the first and assume the second. The second is the control.

On the first clock, the standard is settled. The MCP authorization specification’s security considerations say authorization servers should issue short-lived access tokens to limit the damage from a leaked one, and require refresh tokens to be rotated for public clients. Our own bar, in the builder’s guide, is an hour or less, and fifteen minutes for high-sensitivity scopes. Refresh makes that livable: the agent’s client trades a longer-lived grant for a new short token before the old one expires, and the grant is the thing you revoke. OWASP’s long-lived secrets entry catalogs the alternative: keys and tokens with expiry dates far in the future or none at all. Ask the vendor for the number. A credential that never expires is a key under the mat.

The MCP authorization rules cover servers reached over HTTP; for local servers run over standard input and output, the specification says, in so many words, to retrieve credentials from the environment. The environment is an engineer’s laptop, and what lives in it is whatever that engineer exported. Local agents, the kind that run inside an IDE, are where borrowed logins hide. For every local server the agent runs, ask what credential is in that environment, and whose.

On the second clock, three paths have to work, and the buyer tests all three.

The admin path matters most, because it depends on neither the person who set the agent up nor the vendor picking up the phone. It is also the one a borrowed login makes impossible: disabling the engineer’s account disables the engineer. Revocation that waits for the next token rotation is not revocation. If a disabled identity keeps working until its token expires, the token lifetime is your revocation latency, and an hour is a long time for an agent that works in nine seconds. Immediate is the bar, and a vendor who has tested it can show you the timestamps.

Offboarding is revocation on a schedule. NIST asks that account management align with termination and transfer; OWASP’s improper offboarding entry describes the orphaned identity, still active after its owner has left. A borrowed login fails here twice. Tied to the engineer’s account, the agent dies the day the engineer leaves, and the outage is how you learn what depended on it. A personal key that outlives the account keeps the agent running under the name of someone who no longer works for you.

What the Log Can and Cannot Tell You

When the agent shares a person’s identity, the log is still complete. It records the tool, the arguments, the result, and the time. What it cannot record is who. The engineer and the agent are one principal, and nothing downstream can tell them apart.

OWASP lists the mirror case, a human using a non-human identity, as a top-ten risk for exactly this reason: actions logged under the service account obscure accountability, and human and automated activity become indistinguishable. Run that sentence the other way and you have the agent on a borrowed login. One identity, two actors, and a record that believes the name it was given.

The consequences are practical. You cannot filter the log to the agent’s calls, so you cannot review them. You cannot alert on the agent without alerting on the person, or rate-limit one without the other. And when something is deleted, the investigation starts with a person, which is unfair to the person and slow for the investigation. With the agent’s own identity each of those becomes a query, and a delegated token carries both names: the person who authorized and the software that acted. The fields themselves are the sixth control, AI agent audit log requirements, and the approval recorded under the third, AI agent approval gates, only means something when it names the agent that asked and the person who said yes.

How to Verify AI Agent Credentials

The vendor says the agent has its own identity. Four steps turn the sentence into evidence, and each produces one of the four artifacts.

First, the identity in the directory. Ask for the agent’s account exported from the directory that holds it, with its type, its owner, and its creation date. If the type is a person, or the owner is whoever pasted the token, stop there. Second, the scopes. Read the scope list on the identity next to the tool allow-list from the first control, and ask to see the scopes on a live token, from the authorization server’s grant record or the token itself, not from a slide. The two lists should describe one job. Third, the token lifetime. Read it from the authorization server’s configuration, then watch it: have the vendor hold a token past its lifetime and show the server refusing it, and show that refresh issues a new token rather than extending the old one. Fourth, the revocation. Have the agent make a call at a noted time, disable its identity through the admin path, and have it make the same call again within a minute. The second call should fail, and the log should show both calls, the identity, and the timestamps. Then repeat through the user path if the client offers one.

A vendor who can only demonstrate revocation by rotating a key the engineer holds has the credential in the wrong place. A vendor who can do all four in front of you has the second of the six controls, and the artifacts for the auditor: the directory export, the scope list, the token lifetime, and two timestamped log lines, one that worked and one that did not.

Failure Modes

They share one symptom. Ask who can switch the agent off, by itself, right now, and the answer is a person who would rather not or a timer that has not run out.

The Contract Term and the RFP Question

Why a control that lives only in the demo does not survive is covered in the checklist. The term for this one has four parts. The agent acts under an identity of its own, named in the agreement, with its scopes attached as an exhibit. The buyer holds an admin revocation path that works without the vendor and takes effect on the next call, not the next rotation. Changes to the scopes come with notice, like changes to the tool list. And on termination, the vendor confirms in writing that the identity and every credential issued to it are revoked, with the log entry to prove it. Pair it with the record-is-yours term from the hub, because a revocation you cannot see in your own log is one you are taking on faith. The security terms in SaaS vendor security due diligence are where all of this belongs.

Conclusion

An agent on a borrowed login is a contractor wearing an employee’s badge. The door opens, the camera records the employee, and the day something goes missing the wrong person is in the room. None of this is a model problem, and none of it is new. Service accounts were the answer for software before agents existed. The agent is software. Give it the account.

Its own name, its own scopes, its own off switch. Then the log can finally tell you what the agent did, and you can finally tell it to stop.

Related Guides

• AI Agent Security Checklist – The six AI operator security controls, with the artifact to request for each
• AI Agent Permissions – Control 1: the tool allow-list the scopes on the credential should match
• AI Agent Approval Gates – Control 3: the gate that a scoped identity makes legible
• AI Agent Audit Log Requirements – Control 6: what the record must contain beyond the identity
• MCP Auth and Security – The builder’s view: OAuth 2.1, scope taxonomy, token lifetimes, and revocation
• SaaS Vendor Security Due Diligence – The contract stage these terms belong in