Governance Before the Tool Call

The useful question around AI agents has changed.

For the first wave of adoption, the question was whether an agent could do the work. Could it read the ticket, search the files, draft the reply, inspect the code, update the CRM, summarize the invoice, or coordinate the next step? That question still matters, but it is no longer the limiting one. The market has already seen enough agents that can move.

The harder question is what happens just before movement becomes consequence.

Microsoft’s public preview Agent Governance Toolkit states the problem in unusually plain language. Once agents call tools, browse the web, query databases, and delegate to other agents, operators need answers to three questions: “Is this action allowed?”, “Which agent did this?”, and “Can you prove what happened?” Those are not abstract governance questions. They are the first questions a real operator asks after an agent touches a live system.

The same README draws the line even harder: prompt-level safety is “a polite request to a stochastic system.” That phrasing matters because it strips away the comforting illusion that a strongly worded instruction is the same thing as a control. If an agent can still reach the tool, the database, the email sender, the payment system, or the deployment pipeline, the business has not removed the dangerous path. It has asked the agent not to walk down it.

That is not governance. That is hope with nicer formatting.

The prompt is upstream of behavior, not downstream of consequence

Prompt instructions are useful. They shape behavior, set expectations, and describe the job. A good prompt can keep an agent focused, prevent obvious confusion, and make the output easier to review. In a low-risk workflow, that may be enough to make the agent helpful.

But prompt instructions are not the place to enforce business authority. Authority has to live closer to the action than the model does.

This distinction becomes obvious if you translate the agent into a human workflow. A manager would not hand a new employee a policy manual, give them unrestricted access to payroll, banking, customer records, and production systems, and call the company controlled. The manual matters, but the controls are elsewhere: access rights, approval limits, separation of duties, review gates, audit trails, and escalation paths.

Agents need the same separation. The instruction layer tells the agent what job it is trying to do. The governance layer decides what the agent is technically capable of doing once the job produces an action.

Those are different layers. Confusing them is how teams end up with impressive demos and brittle operations.

Before-the-wire governance is the missing unit

The practical control point is before the wire.

That means the agent’s proposed action is intercepted before it reaches the outside system. The email is not sent yet. The table is not changed yet. The file is not deleted yet. The API has not accepted the request yet. The ticket has not moved to the customer-facing state yet. The payment has not entered the batch yet.

At that moment, the business can still decide.

A before-the-wire control asks a small set of questions. Which agent is acting? What action is being requested? What system will be touched? What authority is required? What policy is active? Does this action need approval, denial, sandboxing, or escalation? What record will prove the decision later?

This is the difference between reviewing a consequence and governing an action. After the wire, the business can log, apologize, reverse, investigate, or discipline. Before the wire, it can prevent.

The Agent Governance Toolkit describes this as deterministic application code intercepting “every tool call, message send, and delegation” before the model’s intent reaches the wire. The important word is deterministic. The model may be probabilistic. The enforcement layer cannot be.

A governed agent is not one that has been asked nicely to avoid bad behavior. A governed agent is one where certain bad actions are structurally unreachable.

Provenance enters before the action does

Runtime policy is only half the story. The other half is capability provenance.

NVIDIA’s May 19 post on verified agent skills makes that point from the capability side. Open models, MCP-connected tools, and portable skills make agents easier to extend, but NVIDIA argues that scaling agent use with “structural transparency and operational integrity” requires teams to understand and trust the skills an agent is using. Their verified skills are cataloged, scanned, signed, and documented with machine-readable skill cards describing ownership, dependencies, limitations, risks, mitigations, and verification status.

That is not just supply-chain hygiene. It is agent governance moving one layer earlier.

If a skill is a portable instruction set that gives an agent a new capability, then the business needs to know what capability is entering the workflow before the agent ever runs it. What does the skill claim to do? Who owns it? What access does it imply? What risks were found? What limitations are known? Has it been modified since publication?

Without that record, the runtime policy is forced to inspect actions from a weaker position. It may know that an action is being requested, but it has less context about the capability package that produced the request. With that record, the system can govern both the capability entering the workflow and the action leaving it.

This is where agent operations starts to look less like prompt writing and more like real production management. Work enters through named capabilities. Actions leave through policy gates. Evidence connects both sides.

The operator protocol is simple

A business does not need to begin with a giant governance platform. It needs to begin by naming the first consequential actions.

Pick one workflow. Do not start with “AI strategy.” Start with the exact work the agent is allowed to touch. A sales inbox. A support queue. A document review path. A pull request flow. An invoice-matching process. A legal intake form. A scheduling call. A procurement request.

Then list the actions that create consequence. Sending an email. Changing a system of record. Exposing customer data. Making a recommendation that sounds like advice. Creating or deleting a file. Updating a price. Approving a refund. Opening a pull request. Merging code. Moving money. Triggering another agent.

For each action, assign one of four states.

Allowed means the agent can do it automatically because the risk is low, the evidence is clear, and the action is reversible.

Review means the agent can prepare the action, but a named human must approve it before it reaches the system.

Escalate means the agent should stop and route the case with context because the action is high-risk, ambiguous, regulated, emotional, expensive, or outside the normal pattern.

Deny means the agent cannot take that action at all.

The power is not in the labels. The power is in placing the labels at the action boundary. If the rule lives in a document but the agent can still call the tool, the rule is advisory. If the rule is evaluated before the tool call executes, the rule is operational.

That is the line.

The execution trail is part of the product

Once actions are governed before the wire, the proof layer becomes much cleaner.

The business should be able to reconstruct an agent action without becoming a forensic analyst. The record should show the agent identity, requested action, source context, policy decision, approval state, affected system, result, and owner of the next step. It should be short enough for an operator to read and complete enough for an auditor, manager, or customer-facing leader to trust.

This is where “Can you prove what happened?” becomes a product requirement, not a compliance afterthought.

A vague log entry saying an agent used a tool is not enough. A shared API key is not enough. A Slack summary after the fact is not enough. The evidence has to connect the proposed action, the authority decision, and the final outcome.

That execution trail also improves the system over time. If the same action is repeatedly approved with no changes, perhaps it can move from review to allowed. If the same action is repeatedly denied, perhaps the agent’s job card or skill should be changed. If escalations pile up, the workflow may not be ready for more autonomy. The trail becomes feedback into the operating model.

The goal is not to freeze the agent. The goal is to make autonomy adjustable without losing accountability.

The human mirror is permission

Good human teams already work this way.

A junior employee may draft a client email but not send pricing without review. A bookkeeper may prepare a payment batch but not release funds. A developer may open a pull request but not deploy to production. A clinician may document an observation but not cross certain decision boundaries without qualification and supervision. A support rep may offer standard remedies but escalate anything that creates legal, financial, or reputational risk.

Nobody experiences those controls as strange when the workflow is mature. They are the lanes that let people move quickly without pretending every action has the same blast radius.

Agents make the hidden lanes visible. If the business cannot tell an agent where it may move, where it must pause, and where it cannot go, the business may not have had an operating model. It may have had experienced humans compensating for one.

That is why agent governance is not merely a security function. It is a management function. It forces the organization to name authority, consequence, evidence, and ownership in a form the system can actually enforce.

Bottom line

The next durable layer of AI-agent work will not be better prompt warnings. It will be before-the-wire control.

Skills need provenance before they enter the workflow. Actions need policy before they reach the tool. Decision records need to prove what happened without a scavenger hunt. And unsafe paths need to be removed, not merely discouraged.

That is the operating difference between an agent that is instructed to behave and an agent that is built so certain failures cannot happen.

Sources

• Microsoft, “Agent Governance Toolkit” README, public preview, accessed May 27, 2026, https://raw.githubusercontent.com/microsoft/agent-governance-toolkit/main/README.md
• NVIDIA Technical Blog, “NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents,” May 19, 2026, https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/
• Forbes, “Do Your AI Agents Have Governance? Most Don’t, And They’re Live,” May 21, 2026, https://www.forbes.com/sites/sandycarter/2026/05/21/do-your-ai-agents-have-governance-most-dont-and-theyre-live/
• KPMG, “Enterprise AI agents strategy: Where CIOs should deploy—and where to exercise discipline,” accessed May 27, 2026, https://kpmg.com/us/en/articles/2026/enterprise-ai-agents-strategy.html

Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.