The Three Questions You Can Answer for an Employee and Not for Your Agents

Here is a test that is hard to argue with. If you cannot answer three questions about an agent the same way you can for a human employee, you are not ready for the autonomy you have already given it. What can this thing do. On whose behalf does it act. Who approved that. For a person on your payroll you can answer all three from memory. For the agents your team shipped last quarter, most organizations cannot answer any of them.

That gap is not academic. An agent that plans, calls tools, and writes to production is doing employee-grade work at machine speed. You would never let a new hire touch the customer database on day one without a manager, a scope, and a paper trail. Yet a developer wired an agent into that same database last Tuesday with a token that read everything, and no one signed off because no one was asked. The autonomy arrived. The record did not.

Why a display name is not an identity

The first instinct is to treat the agent like a user: give it a login, maybe a row in the directory, and call it identified. That misses what identity is for. Identity is not a name, it is the thing that lets you answer the three questions later. A human named Dana has an identity because Dana maps to a role, a manager, an approval, and a set of actions someone decided Dana could take. A display name that says "Support Bot" maps to none of that. It is a label, not an accountable identity.

This is where most agent inventories stop and why they fail. They list the agents by name and feel complete. But the name tells you nothing about blast radius. Two agents both called "assistant" can differ by everything that matters: one reads a public FAQ, the other moves money. The unit of governance is not the display name. It is the answer to the three questions, written down before the agent runs.

The one-page agent inventory

The artifact that closes the gap is small enough to fill in this week. One row per agent in production, and one per agent about to ship. Five columns, and each one is a question you should already be able to answer about anything acting on your systems.

Name. What you call it. This is the only column most teams have, and on its own it governs nothing.

Acting identity. The credential the agent actually authenticates with, and whether that credential is its own or borrowed. This is the honest answer to "on whose behalf." An agent running under a shared service account is acting on behalf of everyone and no one. When something goes wrong, you cannot tell which agent did it, and you cannot revoke one without breaking three. Every agent gets its own credential or the second question has no answer.

Scopes. What the agent is allowed to do, written by blast radius rather than by feature. Read-only on a named source. Write to non-production such as drafts, staging, or a ticket queue. Write to production, send external, or move value. The point of scoping by blast radius is that the third tier is where a human always belongs in the loop, and naming the tier forces you to decide that on purpose instead of by accident.

Approver. The named human who signed off on the scope above. Not a team, a person. "Platform approved it" is how no one approved it. When the agent's reach later turns out to be wider than anyone remembers deciding, the approver is the person who either says yes that was the call, or says no I never agreed to production write, which tells you the scope drifted.

Verifier. The named human who checks that the agent is still doing what the row says, and how often. This is the column almost no one has, and it is the one that keeps the inventory from rotting. An approval is a moment. A verifier is a standing job. Without one, the row is true the day you write it and slowly false every day after.

The rows you cannot complete are not a flaw in the template. They are your real exposure, already ranked. An agent you cannot describe in five columns is an agent no one owns, and an agent no one owns is the one that will surprise you.

Approver and verifier are not the same person on purpose

The instinct is to collapse the last two columns. The person who approved it can check that it is behaving, right. Keep them separate and you will see why they are two columns. The approver decided the scope was acceptable. The verifier's job is to catch the day reality no longer matches that decision, which includes catching the approver's own optimistic call. When one person both grants the authority and confirms it is being used correctly, there is no one positioned to notice when the grant was too generous. This is the oldest control in the book, separation of duties, and it applies to agents for the same reason it applies to people who both write and approve their own expense reports.

For a human employee this separation is so normal you forget it exists. A manager sets what you can do, and audit, security, or a lead checks that you stay inside it. Agents deserve the same structure, and the inventory is where you write down who holds each seat.

From the table to something that runs

A table in a wiki drifts the week after you write it, so bind it to a signal. The narrow, high-value trigger is an agent credential authenticating to a resource it has never touched before. Take the identity-and-resource pairs each agent used across a clean baseline window, and alert on anything new. That is the earliest sign an agent has stepped outside the scope its row claims, whether from a prompt injection, a misconfiguration, or a developer quietly widening its reach without updating the record. Route that alert to the verifier from column five, the one person who can say in seconds whether the new access was expected. If it was, the row is out of date. If it was not, you caught the agent at the first hop.

The inventory columns are not a parallel governance track. Each one is the one-page expression of a control that already belongs in a real program: agent registration, identity, scoped authorization, human sign-off, and standing oversight. I keep the worked template, with the extra example rows and the first-seen detection rule, in the CarbeneAI AI Governance Toolkit under CC BY 4.0. Copy it, delete what does not apply, and fill in the rows you can.

The judgment to map those rows to your regulated data, your real approvers, and the agents your own people are already running is the work that matters. If you want help doing it, that is what CarbeneAI does. Reach out at carbene.ai.