Skip to content
Pyrana
For AI and data leaders
AI governance
Agent control planes

Governance is not a dashboard

Control towers inventory and observe agents. They do not decide whether a specific call may run. The difference between governance above the system and governance in the path of the call, and what to ask a vendor to prove which one they have.

Eric Tarnowski
September 9, 2026
6 min read

You are the person who signs off on the agent program. The vendor walked you through the control tower: every agent inventoried, each tagged with a risk tier, usage charted by department, the acceptable-use policy attached as a PDF. It is a good dashboard. Then an agent moved 41,800 USD to the wrong vendor account, and the question in the incident review was "what decided that call could run?" The dashboard did not. The dashboard found out afterward, like everyone else.

I have sat in that review. The difference that matters is between governance that sits above the system and governance that sits in the path of the call. Only the second kind could have answered the question.

What the control planes do

Microsoft Agent 365, Salesforce Agent Fabric, ServiceNow AI Control Tower, and Kore.ai's Agent Management Platform all sell some version of the same thing: a registry of the agents in your estate, whoever built them, with observability, risk classification, and policy management on top. I want to be fair to them. Inventory is real work, and most companies do not have one. Knowing which agents exist, who owns them, and what they touched last week is the precondition for everything else.

But a registry describes. It does not decide. When an agent inside a vendor's product calls a tool, the control plane learns about it from a trace after the tool has run. The decision about whether that call was allowed was made somewhere else, by whatever authorization the tool happened to have, or by nothing.

Why the gap shows up in production

Gartner said in May that by 2027, 40 percent of enterprises will demote or decommission autonomous agents because of governance gaps found only after production incidents. Analyst Shiva Varma put the cause plainly: "Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure." The two failure modes are over-restriction of simple agents, which pushes teams into shadow development, and under-restriction of autonomous ones. The remedy Gartner recommends is proportional governance, with agents classified by autonomy level and each level carrying its own controls (Gartner, May 26, 2026).

Read that against what a dashboard can do. A dashboard can classify an agent by autonomy level. It cannot make the agent's third tool call on Thursday behave differently from its second because the amount crossed a threshold. Proportional governance happens per call, on the arguments, or it does not happen.

Deloitte surveyed 3,235 business and IT leaders and found 21 percent with mature governance for agentic AI. The three gaps it named were decision boundaries between what an agent may decide and what needs a person, real-time monitoring, and audit trails (Deloitte, April 24, 2026). Two of those three are in-path mechanisms. A decision boundary is a check before dispatch. An audit trail is a record written at the moment of the decision. Only monitoring lives above the system, and monitoring is what the control towers already sell.

IBM's study of 2,000 technology executives found that two-thirds of CIOs and CTOs are held accountable for AI systems they do not fully control, and that 11 percent consider themselves fully ready for the agent deployment they expect in the next year (IBM Institute for Business Value, June 2026). That is your position, and I respect it. You own the outcome of calls you did not admit.

Gravitee's survey of 750 technology leaders has the detail that worries me most. Stated confidence in agent visibility rose from 82.6 percent to 91.8 percent in four months. Monitoring coverage over the same period stayed at 52 percent (Gravitee, State of AI Agent Security Report 2026). Confidence went up. Coverage did not. That is what a good dashboard does to a room.

Governance above versus governance in the path

Here is the distinction I would put on one slide.

Governance above the system: an inventory of agents, a policy document, a risk tier per agent, a dashboard of what happened, a review meeting. All of it useful. None of it touches a call.

Governance in the path: a check every call passes before it runs, which resolves who is calling, under what authority, on which data, and whether this specific set of arguments needs a person. A policy over those arguments, rather than a flag on the tool. An audit record written before dispatch, so a refused call leaves the same evidence as an admitted one. And a frozen copy of the proposed action while a person decides, so what they approve is what runs.

The test for which kind you have is simple. Ask for the record of one call that was refused. Governance above the system cannot produce it, because it never refused anything. It only watched.

How we handle it

At Pyrana every call into an Agentic App, through any of the five doors (App UI, chat, API, MCP, schedules and events), passes one admission check before anything runs. Admission authenticates the caller and keeps the whole actor chain: the person, the agent acting for them, the workflow that started it. It resolves the App's active version, the caller's access profile, the target operation, the exact resources named, the scope, and the current policy. It claims an idempotency identity so a retry rejoins the original rather than running twice. It writes the audit record. Then it dispatches. Any uncertainty in that sequence is a refusal. There is no fallback in which either the old permission check or the new one may allow the call.

Every admitted call produces one AppExecution record. It contains:

  • the actor chain: the initiating person or principal, and every intermediate caller;
  • the App, and the content digest of the version that governed the call;
  • the operation, the access profile, and the scope;
  • the exact resource versions touched;
  • the policy outcome, including any approval obligations and who satisfied them;
  • the effects performed, with receipts, and the idempotency identity;
  • the context used, accounted as retrieved, injected into the prompt, and cited in the output.

Approval is a policy over typed arguments: thresholds, membership, existence, compound rules. Policies compose restrictively. A platform-level floor (any payment above 25,000 USD needs finance, say) cannot be loosened by an App or an agent setting. An App can only tighten it. Above threshold, the invocation, arguments, scope, and evidence freeze into a durable proposal that the waiting agent cannot alter. Each named approval lane gets an independent obligation. Reviewer eligibility is checked when the reviewer acts. The frozen invocation is revalidated before dispatch, and an ambiguous provider outcome goes to reconciliation rather than a blind retry.

Refusals do not disclose. A caller without rights to a resource sees it absent from listings and gets not-found on a direct request. The refusal is in the audit record. It is never in the response.

Status, because you will ask. The authorization model, App versioning, extensions, and the execution lanes are live. Per-invocation admission with the AppExecution record is built and merged; making it the sole authoritative path is a per-installation cutover. Approval as policy with frozen invocations is built and enabled per App. I would rather tell you that than say GA and have you find out in the review.

Here is the 41,800 USD call again, run through the path. An agent in a financial services firm's close App proposes a journal entry of 41,800 USD. The App's policy sets a 25,000 USD threshold with two lanes, controller and treasury. Admission freezes the invocation and raises two obligations. The controller approves at 10:40 a.m. A treasury reviewer approves at 11:15 a.m., and her approval is rejected because her treasury group membership was revoked the day before. A second treasury reviewer approves at 11:52 a.m. Admission revalidates the frozen invocation against current policy and dispatches once. The provider times out. The call enters reconciliation, finds JE-88213 already posted, and closes without a second posting. The AppExecution record shows all of it, including the rejected approval. The dashboard, if you have one, gets a clean trace to display.

What to ask a vendor

Ask every vendor, including us, for four things.

  1. Show me the record of one call that was refused, and what the caller saw.
  2. Show me the same operation called from the UI, from chat, and from a schedule, and the three records side by side.
  3. Change the approval threshold while a request is waiting, and show me what happens to the request.
  4. Revoke an approver's group membership, then have them approve.

If the answers are screenshots of a dashboard, you have a registry. Keep it. It is useful. Then go find the thing that decides.

Sources

Continue the Conversation

Building production-grade agentic AI requires context, orchestration, and human-in-the-loop design. We'd love to show you how Pyrana delivers it end to end.

Request a Demo