Name the Agent Before It Calls a Tool

Someone on your team has an agent with a production token right now. It plans. It calls tools. It acts. Nobody wrote its name down, because it never went through procurement. That is the fire. It is not a model that answered a question badly. It is an agent that already moves state in production, and that nobody inventoried.

I have been writing the same argument in pieces: one row per agent, the sandbox as a trust boundary, allow or deny at the tool call. Those pieces only help if someone actually fills the row. So I published a Grok Bot that does the walkthrough. Import it, answer the questions, leave with a named agent and a board-readable decision log instead of another PDF.

You cannot write policy for an unnamed agent

Policy language assumes a subject. "The agent may read customer records for support and must not send data off-network" is unenforceable if you cannot point at the process, the credential, and the human who owns both. Shared service accounts, folder names, and "the Cursor thing Dave uses" are not subjects. They are how ungoverned agents hide in plain sight.

The first move is still inventory. Not a platform. Not a twelve-page standard. One row per agent that already runs, and one per agent someone is about to ship. The rows you cannot complete are ranked exposure. An agent you cannot describe is an agent you do not control.

This is the same logic as shadow AI, pointed at a different object. A scribe app that transcribes visits is a tool. A coding agent that can write to the production database is an actor. Tools wait. Actors do not.

One row, five columns

Five fields carry the weight. If you cannot fill them, stop the agent until you can.

Identity. Its own credential and a named human who owns that credential. No shared account standing in for three agents. When the token authenticates somewhere new, that owner is the person who gets asked whether it was expected.

Highest data class. Public, internal, confidential, or regulated (PHI, PCI, CJIS). That is blast radius on the data side. If the agent can read regulated data, someone set that on purpose and can say why.

Allowed actions, by reversibility. Read-only on a named scope. Write to non-production. Write to production, send external, or move value, which always needs a named human in the loop. Scope by what happens when the action is wrong, not by feature name. Creating a draft ticket and closing a customer complaint through the same API are not the same risk.

The HITL line. The exact event the agent cannot cross alone. "Sensitive actions" is not a line. "Any write to the production customer table" is. If you cannot write it as a specific event, you do not yet understand what the agent does.

A tested stop. Revoke the token, disable the endpoint, kill the session. Named owner, known time to halt. An untested stop is a hope. Hopes fail at the worst moment.

Blank cells are not a gap in the template. They are the list of agents you should not let run.

The paper version of this table is the Agent Privilege Matrix in the AI Governance Toolkit. It is CC BY 4.0. Copy it, delete what does not apply, and fill what remains. The Bot asks the same questions in order and will not let you skip a blank.

The sandbox is a trust boundary

If the agent is a coding agent, treat the sandbox as a wall, not a scratch directory. Three things sit on the other side of that wall, and they carry almost all of the risk.

The host filesystem. SSH keys, cloud credentials, shell history, other repositories. One directory traversal away if the wall is soft.

The network. Outbound HTTP is exfiltration and inbound tooling. Internal addresses mean the agent is inside the perimeter by definition.

Inherited credentials. Environment variables, tokens, a cloud role that belongs to you. An agent that inherits your authority does not need to escape. It already has it, sitting in env, for as long as it runs.

Prompt is not a wall. "Stay in the working directory" is a request. Enforcement is a sandbox, an allowlist, or a process that cannot see the path. If a sandbox escape for this tool were reported tomorrow, who owns the patch, and on what clock? That clock should look like an authentication bug, not a backlog item for next sprint.

I wrote the longer version of this as Your Coding Agent's Sandbox Is a Trust Boundary, Not a Convenience. The Bot's job is to make you name those three surfaces for this agent, this week.

A policy PDF cannot decide the next tool call

An agent thirty calls deep is about to make the thirty-first. The only question that matters is whether this call, with these arguments, should run right now. The document in the governance folder cannot see the call. It was written months ago by someone who never saw this payload.

Policy is a claim. Runtime is a control. Before the tool executes, something that can see the tool name and the arguments has to return allow or deny. After it decides, it has to write a record a board can read: tool name, argument hash, decision, which rule fired, and a one-line note on whether the call still serves the original goal. Individually allowed calls can still add up to an agent that went off-task at call nineteen. The log that only says "permitted" is an alibi. The log that marks the detour is oversight.

That is a small amount of code in front of the tool-calling layer, not a GRC suite. The allowlist is the matrix row turned into a function. The decision log is proof the row was honored. I unpacked the five fields of that log in Is This Tool Call Allowed? Answer It at Runtime, Not in a Policy PDF. The Bot will not pretend a PDF is the control. It will ask you how allow or deny happens on the next call, and where the log lives.

The Bot is a walkthrough, not a wall

Agent Governance Officer is a public Grok Bot template. Import it. It interviews you the way I would in a working session: name the agent, name the owner, name the data class, name the actions by reversibility, write the HITL line, name the stop and whether you have tested it, name what the sandbox can actually reach, then say how the next tool call gets an allow or deny and where that decision is logged.

What you get back is a filled row and a decision-log shape, not a certificate. It will not connect to your production systems. It will not approve an agent. It will not substitute for counsel, a BAA, or a security review. Anyone with the share link can read the configuration. Do not paste customer names, tokens, or internal URLs into it.

Treat it the way we treat the toolkit. A starting point you can adapt, including commercially, with the same spirit as the CC BY templates: show the work, keep the judgment. If the Bot saves you an afternoon of staring at a blank matrix, use that afternoon to test the stop.

If you sell a product whose deal stalls when a buyer asks who owns the agent, this is the conversation they are already having. A named row plus a runtime log ends it faster than a policy binder. If you want help fitting that row to a live product in public safety tech, fintech, or healthcare, that is the work.