Digital Identity: 68% Cannot Tell Humans From AI Agents

Here's a number that should stop you mid-scroll:

68% of organizations can't tell whether a human or an AI agent performed a given action inside their own systems.

Not "struggle to tell." Cannot tell. Two-thirds of companies now running AI agents have no reliable record of who — or what — actually clicked the button.

TL;DR: Digital identity for an AI agent isn't one login — it's three separate checks (who's acting, who approved it, and what it's allowed to do), and skipping any one of them is how a helpful assistant quietly becomes an unaccountable one.

Most of us think about digital identity the same way we think about a house key. If you have the key, you're in. Your password proves you're you, you log in, and from that point on, anything that happens under your account is assumed to be you doing it. That logic has worked fine for twenty years of humans clicking buttons. It falls apart the moment the thing clicking the button isn't a human anymore.

Why digital identity for an AI agent means more than one login

An AI agent — the kind that can book your flight, cancel a subscription, or move money between accounts — isn't a person sitting at a keyboard. It's software acting *for* a person, sometimes making dozens of small decisions a second, often without anyone watching in real time. According to

NIST

, this is exactly why treating an agent's access like a regular user login creates a dangerous blind spot: the agent needs its own **digital identity**, separate from yours, so systems can tell "this action came from the agent working on Sarah's behalf" apart from "this action came from Sarah herself."

Sit with that stat for a second. It's not that companies haven't gotten around to fixing this yet. It's that the tools most of them built for identity — passwords, logins, session cookies — were never designed to answer the question "was this a person or a piece of software pretending to be one?" That gap is what NIST's new work on agent identity is trying to close, and it's why European telecom companies are converging on the same idea: before an AI agent does anything, the system needs three separate proofs, not one.

Digital identity verification for machines works differently than for people

For a person, identity verification usually means proving a face, fingerprint, or password matches a record on file. For a machine, it means something closer to issuing a badge: a unique, verifiable credential that says "this specific piece of software, running this specific task, was authorized by this specific person, and expires at this specific time." No badge, no access — and the badge doesn't get reused for the next task.

---

It helps to define the term precisely. A digital identity is the bundle of identity attributes — digital identifiers, credentials, and permissions — that lets a system recognize one actor among millions of identities. Your digital identity answers who you are; an agent's digital identity answers what software is acting, for whom, and under which digital verification it was admitted. Two identities, two records, and the moment they blur, accountability blurs with them.

That separation matters for privacy as much as for security. When agent identities and human identities share one login, every log entry mixes your information with the software's actions, and no privacy review can untangle them later. Separate digital identities keep the information trail clean: the person's identity stays private, the agent's identity stays auditable, and identity security stops depending on guesswork.

Digital identity verification for a machine leans on the same building blocks the rest of our digital services use — cryptographic keys, signed credentials, short-lived tokens — but assembles them differently. A human proves identity once per session; an agent proves identity per task. Financial services, healthcare services, and government services are all converging on this per-task digital verification because their regulators ask the same question: which identity did this, and who authorized it?

Notice what this does to identity verification at scale. Instead of one long-lived digital id that unlocks everything, the agent carries disposable identities — one per errand. If a credential leaks, the exposed access expires in minutes, the identity trail shows exactly what information was touched, and the blast radius stays small. That is identity security working as designed rather than as an afterthought.

The three-part trust chain behind every safe AI agent action

Let's walk through what actually has to happen, step by step, before an AI agent can safely act for you. This is the part almost nobody sees, which is exactly why it's worth understanding. **Step one: identity.** The system has to know *what* is asking to act. Not "Sarah's account," but "the specific agent process running on Sarah's behalf, right now." Researchers writing on identity management for agentic systems have proposed something called an On-Behalf-Of pattern — basically a formal, traceable way for software to say "I am acting for this person" instead of just impersonating them silently, according to a paper published on

arXiv

. Right now, a lot of agents skip this step entirely — they log in by scraping a screen or reusing a saved password, which means from the outside, there's no way to tell the agent apart from the actual person. **Step two: authorization.** Knowing *who* the agent is doesn't tell you *who approved it to act*. This is a separate check — did a real human actually say yes to this specific task? Without it, an agent could theoretically approve its own actions, or another piece of software could grant it permissions nobody meant to grant. Think of authorization as the signature on the form, not the form itself. **Step three: scope.** This is the one people forget entirely. Even a fully identified, fully authorized agent shouldn't get a blank check. It should get exactly enough access to do the one task you asked for — and nothing else. Security researchers call this "least privilege," (giving software only the smallest amount of access it needs, and no more) and NIST's concept paper specifically pushes toward permissions that are task-scoped and short-lived rather than broad and permanent, based on the framework detailed by

NIST's Computer Security Resource Center.

Run the three checks against a concrete errand. You ask an agent to cancel two subscription services. Identity: the system records the agent's digital identity, not yours, performing the cancellation. Authorization: your one-time approval is attached to the request. Scope: the agent's access covers those two services and expires when they're done. Three answers, three separate identities of proof — and the 68% problem disappears for that transaction.

Now run it without the chain. The agent reuses your password, so its identity IS your identity. No separate authorization exists, so consent can't be shown. No scope exists, so the same access that cancels a subscription could empty a wallet. Every piece of information the agent reads gets logged as you reading it. Multiply that by thousands of agent identities across an organization and the audit trail becomes fiction.

Digital identity for agentic AI: why login and authorization aren't the same thing

Here's the misconception almost everyone carries into this conversation, and honestly, it's a reasonable one: if you know my password, you can log in as me — so logging in *is* proving who you are *and* proving you're allowed to do whatever you're doing. Those feel like the same moment. They're not. **Authentication** answers "are you who you say you are?" **Authorization** answers "are you allowed to do this specific thing?" With humans, we blur these together constantly because a person typing a password is usually the same person who should be allowed to act — there's no gap between the two. But an AI agent breaks that assumption completely. The agent might prove its identity perfectly (yes, this is definitely the scheduling bot Sarah set up) and still have no business booking a $4,000 international flight, because Sarah only ever approved it to check her calendar. This is why identity proofing alone — the process of confirming who or what something is — was never built to answer the harder question of what that identity is *allowed* to do. **Identity management** systems that treat these as one and the same are exactly the systems producing that 68% accountability gap. It's not that the technology is broken. It's that we're asking a system built to answer one question to also answer a totally different one.

---

What does digital identity verification look like for an AI agent versus a human user?

For a human, identity verification usually checks a face, a password, or a code sent to a phone. For an AI agent, verification checks a cryptographic credential — a digital certificate proving which specific software instance is making the request, issued fresh for each task rather than reused indefinitely, so a stolen or copied credential expires quickly instead of granting permanent access.

The loss and misuse of static and long-lived tokens have been the root cause of numerous, substantial security incidents over the years — but the ubiquity of AI technology has put pressure on many organizations to deploy agentic functionality with little regard for identity best practices.

— findings summarized from NIST's identity and authorization research, as reported by

NIST's National Cybersecurity Center of Excellence

Think about **power of attorney** — the legal document that lets one person act for another. Handing an AI agent your password is like handing someone your entire house key and hoping they only use it for the one errand you mentioned. Real delegation looks nothing like that. A proper power of attorney names exactly who can act, exactly who authorized them, exactly what they're allowed to do — open one safe deposit box, not sell the house — and exactly when that authority runs out. If the person holding it tries to do something outside those lines, there's a paper trail leading straight back to what you actually signed. That paper trail is the whole point. Without it, you can't prove what you meant to allow versus what actually happened.

Old model: shared login	New model: scoped digital identity
Agent reuses your password or session	Agent has its own verifiable identifiers
Access lasts until you manually revoke it	Access is task-scoped and expires automatically
No record of what the agent decided versus what you approved	Every action traces back to a specific authorization
Impersonation is invisible to outside systems	Delegation is explicit and auditable
One credential covers every task, forever	Permissions are narrow, temporary, and one-time by design
Privacy of the human's information	Blended into one shared login	Kept separate — the person's digital identity is never lent out
Audit across digital services	One identity, no way to split human from agent	Distinct identities per actor, an information trail per task

Digital identity, trust, and the accountability gap in agentic AI

This is where the picture gets a little unsettling, and also where it gets genuinely fascinating. If an agent is impersonating a user through screen-scraping or a reused session — instead of using a proper delegated credential — the systems on the other end have no idea an agent is even involved. They just see "Sarah logged in." That's not a small technical detail. It's an **accountability** black hole. If the agent makes a mistake, cancels the wrong subscription, or gets tricked by a scam email into approving a payment, there's no clean record showing where the human's decision ended and the software's decision began. I spend a lot of time thinking about this same fracture point in facial recognition work at CaraComp — the moment where a system correctly matches a face (identity, confirmed) but still has to separately decide whether that person should be let into a building, cleared through a checkpoint, or granted access to a record (authorization, a completely different question). It's the same split, just wearing a different costume. **Verification** answers "who is this." Access control answers "what should happen next." Confusing the two is how airports, banks, and now AI agents all end up with the same kind of blind spot — mistaking a correct match for a green light to act.

How organizations handle AI agent permissions with just-in-time access

Rather than giving an agent standing access it keeps forever, some organizations now issue temporary, task-specific tokens — a credential valid for one job, for a short window, then automatically dead. It's the difference between giving someone a permanent office key and buzzing them in for one meeting, then locking the door behind them the second it ends.

So here's the inversion that should genuinely surprise you, because it flips the instinct almost everyone starts with. You don't make an AI agent safer by handing it more of your identity — your password, your session, your account. You make it safer by giving it *less* of your identity: a narrow, temporary, single-purpose credential that says exactly what it can touch and exactly when that permission dies. **Identity** was never supposed to be the whole trust chain. It's the first link. The next time you let an AI assistant handle something for you, ask yourself the question that actually matters — not "did I log it in," but "what, specifically, did I just tell it never to do?"

Where does this leave digital identity as a discipline? Moving from a password world to an identity world. The old model asked one question at the door; the new model treats identity, authorization, and scope as three continuous digital verification checks. NIST's concept work, the European telcos' agent registry, and the arXiv On-Behalf-Of proposal are three drafts of the same architecture: verifiable digital identities for software, issued like badges, logged like transactions, and retired like visitor passes.

For businesses the checklist is short. Give every agent its own digital identity — never a shared human login. Bind each identity to a named approver, so authorization is provable. Scope access per task, with expiry measured in minutes. Log agent identities separately from human identities, so privacy reviews and security reviews read clean information instead of a blended stream. And prefer vendors whose digital services expose biometric authentication or strong customer verification for the human half of the approval.

For individuals it is even simpler: treat any assistant that wants your actual password as a red flag, because it is about to borrow your whole digital identity rather than carry its own digital id. The safe pattern looks like connecting a bank to a budgeting app — a scoped, revocable grant tied to your identity but distinct from it. That single design choice preserves your privacy, your security, and your ability to prove which identity — human or software — actually clicked the button.

One more habit worth adopting: review the digital identity inventory quarterly. List every agent identity, its scope, its approver, and its last access; retire identities that no service has verified in ninety days. A digital identity nobody remembers issuing is the exact place an attacker hides, and a clean inventory turns identity security from a yearly scramble into routine information hygiene — the same discipline every digital verification program already applies to human identity records.

digital identity: Frequently Asked Questions