Your AI agent is about to act for someone. Who checked that someone?

An agent is working a support queue at two in the morning. A request arrives: this person is locked out, reset their MFA enrollment. The agent has the credentials to do it, the API is well documented, and the instruction is clear. Nothing in that sequence establishes who sent the request.

The agent’s own credential is not the gap. That part is usually handled: a token exists, it is scoped, someone can point at where it lives. What the token proves is that the agent is allowed to perform the reset. It says nothing about the human whose account is being reset, or about whether that human asked for any of this.

Delegated authority arrives with a hole in it. An agent acting on someone’s behalf inherits their permissions immediately and inherits no way to confirm them.

Two different questions, and only one of them is being asked

There is a serious and growing body of work on non-human identity: discovering agent credentials, scoping them, rotating them, giving each one an owner. Trusona has written about that gap too, in Your AI Agents Have Credentials. Nobody Verified Who They Are. All of it is necessary.

It answers a different question from this one.

Who is the agent? is a question about the software. It gets answered with credential hygiene, attestation, and a registry of what is running where.

Who is the person the agent is acting for? is a question about a human being, and no amount of credential management touches it. An agent with immaculate identity hygiene, a freshly rotated token and a named owner will carry out an impersonated request as faithfully as a legitimate one, because from inside the agent the two look the same.

That second question is the one that decides whether an account gets taken over.

The help desk already ran this experiment

None of this is new. It is the help desk problem with the human removed from the middle of it.

For a decade, attackers have skipped the authentication stack entirely and called the people who can turn it off. CISA documents the pattern in its advisory on Scattered Spider, which describes posing as employees to convince help desk staff to reset passwords and move MFA to attacker-controlled devices (CISA, advisory AA23-320A). Mandiant found voice phishing involved in 23% of cloud intrusions, the leading vector in that category, and in 11% of intrusions overall (Mandiant, M-Trends 2026). Those denominators are different and both are worth knowing.

The reason it worked is that a human agent was making an identity judgment from signals that can be faked. A voice sounded right. A caller knew the answers. The story was urgent and plausible.

Software agents change two things about that, and neither is an improvement.

They remove the pause. A help desk analyst who feels that something is slightly off can stall, ask another question, or escalate. That instinct is unreliable and it is not nothing. An agent executing a well-formed instruction has no equivalent.

And they scale. A social engineering campaign against human agents is limited by how many calls a person can place. A campaign against an agent endpoint is limited by rate limits.

Why the obvious controls do not fit

The reflexes a security team reaches for here mostly fail on contact with how agents actually work.

Put a human in the loop. This is sound for the highest-risk actions and it dissolves the reason the agent was deployed if applied to everything. It also relocates the problem rather than solving it, because the human now approving the action is making the same unverified identity judgment a help desk analyst was making, with less context.

Rate-limit what the agent can do. Velocity caps and spending limits bound the damage of a successful impersonation, which is worth having. They do not reduce how often one succeeds, and an attacker patient enough to stay under the cap gets everything the cap allows.

Ask the user something only they would know. Knowledge-based verification was already failing against humans with breach data. Against an attacker who is running a language model, a question answerable from public records and leaked databases is not a control. The model in the loop is at least as good at that quiz as the person it is impersonating.

Ask for a selfie. Generative AI defeats face-match and liveness checks, which is why Trusona does not offer them by default and says so publicly. Adding a biometric step to an agent workflow adds a permanent record of someone’s face and does not answer the question.

What survives is checking the person against a record held by an authority outside your organization, and outside the agent’s reach.

What the check has to look like to be usable by an agent

A verification step that only exists as a web page a person clicks through is not available to an agent. It has to be something the agent can call, wait on, and branch from.

That means a small number of concrete properties.

It has to start from an instruction, not a click. The agent creates the verification itself as a step in its own workflow.

It has to resolve. The agent needs to poll the check to a terminal state and receive a result it can act on, rather than a page it would have to interpret.

The result has to be something the agent can branch on. A verdict with a risk signal attached, rather than a document it would have to parse and interpret.

It has to check against an authority. The whole point is a source the requester does not control. A government-issued ID queried against the state that issued it over the AAMVA network, plus carrier records for the phone number, gives an answer that an attacker with a convincing story cannot influence.

Credentials must not accumulate. An agent workflow that writes a bearer token to disk has traded one exposure for another.

What Trusona built for this

The ATO Protect Agent Skill is open source under Apache 2.0, and it exists so that identity verification becomes one of the operations an agent knows how to perform.

It ships runnable scripts rather than documentation to read. The agent creates a verification, polls it to a result, and can run a driver-license match against DMV and carrier records, calling the same APIs Trusona runs in production. The bearer token is read directly into the Authorization header and never written to disk, and a doctor.sh check validates the setup locally before a live credential is used.

It is packaged as a Claude Skill and it is portable beyond that, because the body is plain Markdown plus bash. It runs anywhere an agent can read files and execute a shell. Setup is cloning the repository into a skills directory and setting two environment variables, one of which points at AuthCloud, the verification engine the product runs on.

The repository is public at github.com/trusona/atop-agent-skill, and the ATO Protect Agent Skill page covers the exposed capabilities and the install steps.

A note on the word “agent”

The word is doing two jobs in this industry and the collision causes real confusion, including inside Trusona’s own material.

ATO Protect – Agent Verify is about human help desk agents. It handles reverse social engineering, where an attacker calls an employee while posing as IT. The real agent generates a single-use, time-limited Verify Code and the employee confirms it on an internal page before acting. That is a different product solving a different problem, and it is covered in agent verification.

This piece is about software agents verifying the humans they act for. When you read a vendor claim about “agent verification”, check which sense is meant, because the two have almost nothing in common beyond the noun.

Where this runs out

The check answers one question at one moment: is the human behind this request who they claim to be. It does not establish that the request itself is a good idea, that the agent interpreted it correctly, or that the permissions behind it were scoped sensibly. Those remain separate problems with separate owners.

It also requires the person to hold a government-issued identity document and to be reachable in the moment. An asynchronous agent working a queue overnight cannot verify someone who is asleep, which means the design question is which actions are worth waking someone up for. That is a policy decision and it is not one a vendor should make for you.

And the honest limit: this is a new area. Agents taking consequential actions on behalf of people is a pattern maybe two years old at production scale. The verification discipline behind it is much older, which is the argument for applying it here rather than waiting for something purpose-built to emerge.

Questions worth asking

• When our agents act for a user, what confirms the user is who they claim to be?
• Is that confirmation a step the agent can execute, or a screen that assumes a person?
• What is the check made against: our own records, or an authority outside our control?
• Which actions should require it, and which are low enough stakes to skip it?
• Where does the credential for that check live while the agent is running?
• If an attacker had our agent’s token today, what could they do that verification would have stopped?

The last one is the useful one to take into a design review. It separates the controls that would have mattered from the ones that only look like security.

ATO Protect verifies a person against the authority that issued their government ID, in real time, with no pre-registration and no selfie. The ATO Protect Agent Skill makes that check callable from an agent workflow, and it is open source under Apache 2.0. All user PII from the verification session is deleted. Trusona verifies to NIST IAL2 and runs on SOC 2 infrastructure. See the ATO Protect Agent Skill, or ATO Protect use cases for the human-facing deployments.

Frequently asked questions

How does an AI agent verify a person’s identity? By calling an identity verification service as a step in its own workflow. The agent creates a verification, polls it until it reaches a terminal state, and receives a result it can act on. Trusona’s ATO Protect Agent Skill packages this as runnable scripts, so the check is an operation the agent performs rather than a page a human visits.

Isn’t verifying the agent’s own credentials enough? No. A credential establishes that the agent is authorized to take an action. It carries no information about who asked for the action. An agent with well-managed credentials will execute an impersonated request exactly as it executes a legitimate one.

Why not use knowledge-based questions? Because the answers circulate in breach data, and because an attacker driving a language model is at least as capable of answering them as the person being impersonated. Knowledge checks were already weak against human social engineering and they are weaker here.

Why no selfie or liveness check? Generative AI defeats those methods, so Trusona does not offer them by default. A face check also creates a permanent biometric record, which is a cost with no matching benefit when the underlying question can be answered against an authoritative source instead.

Is this the same thing as Agent Verify? No. ATO Protect – Agent Verify is about human help desk agents, and lets an employee confirm that the person calling them from “IT” is genuine using a single-use Verify Code. This piece is about software agents verifying the humans they act for.

What does the skill actually run on? Bash, curl and jq. The body is Markdown plus shell scripts, so it works as a Claude Skill and anywhere else an agent can read files and run a shell. It is Apache 2.0 and the source is public.

What happens to the identity data afterwards? All user PII from the verification session is deleted. Trusona runs on SOC 2 infrastructure, and its trust portal is at trust.trusona.com.

Your agent’s credential says it is allowed to act. Only a verification says the person it is acting for ever asked.