AI Agent Visibility vs. Governance: Monitoring and Enforcement

TL;DR

Most "governance programs" turn out to be visibility with a written rule stapled to the front, and the size of the gap is now measurable rather than anecdotal.

Palo Alto Networks' 2026 Identity Security Landscape, a survey of more than 2,900 security decision-makers, puts machine identities at 109 per human in the enterprise, up from 82:1 the year before. Among the organizations running agents, it reports that "only 37% can revoke an AI agent's credentials" and "only 30% have immutable audit logging for what those agents do."

The common reading is that watching is the hard part. It isn't. Observation is what vendors sell and what actually ships. The decision about what an agent may do, wired to something capable of stopping it, is the part that stays on a slide.

We are not arguing that visibility is wasted money. NIST's zero trust tenets put continuous collection at the centre of the architecture, and nobody can compare behaviour against a rule they cannot see. Visibility is a precondition that keeps getting mistaken for the finish line.

What to do today: take one agent, write down the single action it must never perform, and go find the code that would stop it. If that code does not exist, what you have is visibility.

Overview

An agent exports a customer table it was never supposed to touch. Someone notices, eventually, and a postmortem gets scheduled. The reviewer pulls up the written rule for that agent's data access and finds it already sitting there: no row-level customer data leaves the warehouse without sign-off. The rule is clear and correct. It also did nothing, because nothing in the agent's request path was checking whether it held.

This post is about one distinction: observing an action is not controlling it. Monitoring tells you a call happened. Enforcement decides whether it happens at all, and the two are separate systems that get bought as one. If the prior question is what visibility even means, that is the definition and its three parts; if an incident is already open and you need the evidence, that is which systems to query, in what order.

The seam matters because the two get funded as one line item. A dashboard demos well to a board. A request refused before it reaches the SaaS API is invisible when it works, which makes it a bad demo and a good control. So the sensor layer arrives first, the loop never quite closes, and the organization spends a year believing it has governance because it can see.

Observing an Action vs. Controlling It

Visibility answers what is happening. Governance answers what is permitted, and then refuses the rest.

A visibility answer is satisfied by an accurate, current picture. This analytics agent queried the revenue warehouse eleven times yesterday, exported two result sets, and authenticated with a service token issued in March. Nothing in that sentence says whether any of it was acceptable.

A governance answer needs two parts, and teams routinely ship only the first. There is the decision, a rule somebody wrote down: analytics agents may read aggregated tables and may not export row-level customer data. And there is the mechanism that acts on it, the code path that receives the export call and returns a refusal. A rule without the second part is a preference.

Table 1 — The six questions people lump together as "agent oversight", sorted by which layer can answer them.

The split predicts where your work goes. The visibility rows are a data problem: collection, normalization, retention, query. The governance rows are a placement problem, and placement is the whole difficulty. A decision written in a document beside the request path is not a control. The same decision inside the request path is. The taxonomy grades that placement, from aact:enforcement-point/in-prompt up to aact:enforcement-point/gateway.

Monitoring: The Sensor Layer

Visibility is the continuous stream of signal about what agents are and what they are doing: identity, tool calls, credentials used, data touched, behaviour over time.

Take a procurement agent triaging vendor invoices. Good visibility says plainly what it does. It reads incoming invoices, matches them against open purchase orders, updates status in the ERP, attempts payment approvals under a threshold, and authenticates with a shared service account that also holds write access to the vendor master record. That last clause is what the sensor layer exists to surface. It does not judge. It reports.

The sensor layer now has a published vocabulary for all of this: OpenTelemetry's generative-AI semantic conventions, whose span and attribute names are set out in full in the definition post. The one thing worth repeating here is that the whole set sits at Development stability, so the names are a moving target rather than a contract. None of which changes what the sensor layer is for. It reports; it does not decide.

MCP pushes the same way from the server side. Its 2026-07-28 revision tells clients to "Log tool usage for audit purposes", and specifies that a server's advertised tool set "MUST NOT vary per-connection or as a side effect of other requests on the connection" while it "MAY vary by the authorization presented on the request". That second clause is a sensor requirement in disguise. If the tool list is a function of the caller's scopes, recording which tools were offered matters as much as recording which were called.

Four things are worth capturing per call, and usually only one survives a first pass. The agent identity. The human identity it is acting for. The tool and arguments. And the decision, refusals included. All four together are aact:audit-granularity/per-action-with-principal-chain; without the acting human it is only aact:audit-granularity/per-action. Most audit trails keep successes and drop denials, which is a smoke detector that logs only the fires it missed.

Enforcement: The Control Layer

Governance takes the signal the sensor layer produces and makes it consequential. Which agents are sanctioned to operate at all, which permissions are wider than observed behaviour justifies, which credentials are stale, and what happens the moment a boundary is crossed.

NIST SP 800-207 worked this architecture out for human and device access, and the shape transfers. It splits the control plane into a component that makes the decision and a component that carries it out, and its seventh tenet is blunt about why the sensor layer exists: "The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture." Collection feeds the decision. That is the loop, written down in 2020.

For the procurement agent, governance is the decision that it should never have held write access to the vendor master record, that payment approvals above a small amount route to a person in finance, and that the shared account is replaced with a credential scoped to that agent alone. Governance is also those three things actually happening.

Two Ways to Fail Alone

Each layer fails in a distinct way, and the two failures look nothing alike once you know the symptoms.

Governance without visibility is theoretical. Write a rule that an HR onboarding agent may provision new-hire accounts but must never grant sensitive access without manager sign-off. Sound rule. With no visibility into the agent's tool calls, nobody can tell whether it is honouring the boundary or quietly provisioning sensitive access because a downstream API made it convenient.

Visibility without governance is inert. A marketing agent can be fully instrumented, every campaign drafted, every segment pulled, every external send queued, all on a clean dashboard, and still leave the business exposed. If nothing declares which segments are off limits and nothing sits in front of a mass send, the instrumentation changed nothing about what the agent may do next.

Table 2 — Five symptoms and the question that tells you which layer is missing.

We would call the second failure the worse of the two, and it is also the commoner. A rule with no visibility behind it gets caught the first time an auditor asks a hard question. A dashboard nobody connected to a consequence can run for years looking exactly like governance.

What the Numbers Show

Two datasets make the gap concrete rather than rhetorical.

The first is vendor survey data, so treat it as directional. Palo Alto Networks' 2026 Identity Security Landscape, drawn from more than 2,900 cybersecurity decision-makers, reports 109 machine identities per human in the enterprise, up from 82:1 the year before, and that "99% of organizations have adopted AI agents. 40% of those agents already have access to organizational data." Then the two figures that matter here: "Only 37% can revoke an AI agent's credentials" and "Only 30% have immutable audit logging for what those agents do." Both are governance numbers wearing visibility clothes. Immutable logging is not an enforcement control, and being unable to revoke means the kill switch is missing, not the dashboard.

The second dataset is public, which makes it more interesting, because you can check it. The US Office of Management and Budget publishes the consolidated federal AI use case inventory as CSV, mandated by memorandum M-25-21 of 3 April 2025. The 2025 file carries 3,611 individually reported use cases from 41 agencies across 36 columns. Of those, 445 are flagged High-impact, meaning AI "with an output that serves as a principal basis for decisions or actions with legal, material, binding, or significant effect".

That file has a column called hi_ongoing_monitoring. Among the 445 high-impact entries, 40 record "Yes - Monitoring Established", 87 record "In-progress", and 318 are blank. The companion hi_failsafe_presence column, the closest the schema comes to asking whether anything can stop the system, reads "Yes" for 37 of the 445.

That is not federal incompetence. Reporting lags reality, the fields are new, and blank means unreported rather than absent. What it shows is the shape of the problem at a scale nobody can wave away. The inventory exists, it is well structured, the governance columns are right there in the schema, and roughly nine percent of the highest-risk rows say monitoring is established. Record-keeping ran ahead of control.

Figure 1 — Counted from OMB's published 2025 inventory. The schema asks the governance question; most high-impact rows do not answer it.

Where Regulators Draw the Line

European law is unusually explicit about which layer it is legislating, and it handles the two in different articles with different verbs.

Article 12 is pure sensor layer. High-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system". Article 19 makes providers keep those logs "for a period appropriate to the intended purpose", and Article 26(6) puts the same duty on deployers with a floor: "at least six months, unless provided otherwise in applicable Union or national law".

Article 14 is the control layer, and it names the mechanism. High-risk systems must be built so a person can "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output", and can interrupt it "through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state". Article 26(2) then makes deployers assign that oversight "to natural persons who have the necessary competence, training and authority". Authority is the word organizations skip, and it is not a training slide.

Article 73 attaches clocks, which is what turns both layers into engineering requirements. Fifteen days to report a serious incident is generous if your logs are queryable and impossible if they are not.

Table 3 — High-risk obligations sorted the same way as Table 1. Retention is a storage decision. A stop button is a code path.

The dates moved, and precision matters because a lot of 2025 writing is now wrong. The Digital Omnibus deferred the high-risk regime: standalone Annex III systems to 2 December 2027, Annex I embedded products to 2 August 2028. Most Article 50 transparency duties stayed on 2 August 2026. Eighteen extra months is real relief on paperwork and none on the underlying problem, because the agents are already running.

Closing the Loop

Programs that get this right wire the layers into one path: observe, compare against the rule, refuse when a boundary is crossed, record the refusal as carefully as the success.

Enforcement point Enforcement point compares the call against the rule for that agent -> writes an audit record: DENIED, rule id, agent identity, acting user -> returns a refusal to the agent -> the warehouse never receives the request The denial is the artifact. A log with no denials in it is a log of a control nobody tested. -->

Figure 2 — The same export attempt, with the decision moved into the request path. Note that the interesting record is the denial.

The dependency runs one way. Governance starts with visibility, because nobody can compare behaviour against a rule they cannot see. That is why the sensor layer gets built first. The mistake is treating first as sufficient.

Rerun the opening scene with the loop wired up. The export is compared against the rule at the moment of the call, the comparison fails, the call is refused, and a data owner gets an alert rather than a postmortem invite. Nothing about the rule changed. It was just connected to something that could see the moment it mattered and act in the same breath.

Where Fabriq Fits

Agentic Fabriq sits where the governance rows of Table 1 live. It holds credentials per user in a vault and attaches them server-side at the moment of the call, so the agent never handles the secret, and every request carries two identities: the agent and the acting user. A governed tool call is checked against the intersection of the agent's grants and the acting user's own permissions, at the gateway, before the tool runs — the same idea MCP describes when it says the advertised tool set may vary by the authorization presented. Permissions are enforced in the request path rather than advertised in a prompt.

The intersection decides which tools an agent may reach. Our policy firewall decides what an individual call may carry: ordered allow, deny and hold-for-approval rules that can condition on the recipients of a message, the amount on a refund, the document being shared or the data label attached to it. On the way back, PII, PHI and PCI in tool responses are detected and redacted before the agent sees them.

The part that belongs here is the mode switch. A policy runs off, in shadow, or in enforce. Shadow evaluates every live call against the rule and records what the rule would have done without doing it, which is monitoring in the precise sense used above. The switch to enforce is the moment it stops being monitoring. The same rule, the same traffic, the same records; the only thing that changes is whether the call survives. Most of the gap described here is organisations that never threw that switch.

What it does not do is reach into a provider for you. Clearing a vault copy of a credential is not the same act as invalidating a grant upstream, so the call to the provider's own revocation endpoint stays yours to make.

Frequently Asked Questions

What is the difference between agent visibility and agent governance? Visibility monitors: it records which agents exist, what they did, which credentials they used. Governance enforces: it decides what an agent may do and refuses the rest, in the request path. Visibility is a data problem. Governance is a placement problem, and the placement is the whole difficulty.

Can monitoring become enforcement? Only by moving the decision into the request path. The cleanest version of that transition is a rule you can run in shadow against live traffic, so it reports what it would refuse before it refuses anything; the switch from reporting to refusing is the line between the two layers, and it is a configuration change rather than a new system.

Is observability the same as governance? No, and the confusion is expensive. Palo Alto's 2026 survey found 30% of organizations have immutable audit logging for agent activity. Immutability protects the record from tampering. It does nothing to the action the record describes.

Do we need visibility before governance? Yes, and NIST SP 800-207 says why: its seventh tenet has the enterprise collecting "as much information as possible about the current state of assets" specifically to improve "policy creation and enforcement". The sequencing is real. The mistake is stopping there.

What does the EU AI Act require for agent logging? For high-risk systems, Article 12 requires the system to technically allow automatic event logging over its lifetime, and Article 26(6) requires deployers to keep logs under their control for "at least six months" unless other Union or national law says otherwise. Article 73 then gives you 15 days to report a serious incident, 10 where a person died, two for widespread infringement.

Who owns agent governance, security or platform? Article 26(2) answers the shape rather than the org chart: oversight belongs to named natural persons with "the necessary competence, training and authority". We read the authority clause as forcing the answer. Whoever can say no to a shipping team owns it.

Is an audit trail an enforcement control? No. It is evidence, and required evidence under Articles 12 and 19. Treating it as a control is the error this post exists to name. The cheap upgrade: log denials as well as successes, and the trail starts telling you whether anything is enforcing at all.

Conclusion

Visibility and governance are two halves of one control system. One establishes what is happening. The other decides what is permitted and makes the decision binding at the moment of the call. Pursue one without the other and you get either rules nobody checks or a dashboard that has never changed an outcome.

Three things would close most of the gap. Record the denials, because a log with no refusals in it cannot tell you whether anything is enforcing. Diff granted scopes against observed behaviour, because the delta is blast radius you carry for free. And for each agent, name the code path that would stop it. If the answer is a person reading an alert, the control is a human in a loop that already closed.

Sources

All URLs read 2026-09-29.

• NIST SP 800-207: Zero Trust Architecture — tenets 5, 6 and 7, quoted verbatim, and the split between the component that decides and the component that enforces.
• NIST AI Risk Management Framework 1.0 — the GOVERN / MAP / MEASURE / MANAGE split, GOVERN 1.6 on inventorying AI systems, and MANAGE 4.1 on post-deployment monitoring plans.
• EU AI Act Article 12: Record-keeping — the automatic event logging requirement over the system lifetime, and the Annex III point 1(a) minimum log contents.
• EU AI Act Article 19: Automatically generated logs — provider retention "for a period appropriate to the intended purpose".
• EU AI Act Article 26: Obligations of deployers — paragraph 2 on assigning oversight to competent persons with authority, paragraph 5 on monitoring, paragraph 6 on the six-month log retention floor.
• EU AI Act Article 14: Human oversight — the override and reverse language, and the stop button that brings the system "to a halt in a safe state".
• EU AI Act Article 72: Post-market monitoring — the duty to "actively and systematically collect, document and analyse relevant data" across the system's lifetime.
• EU AI Act Article 73: Reporting of serious incidents — the 15-day, 10-day and two-day reporting clocks.
• EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines, Gibson Dunn — Annex III deferred to 2 December 2027, Annex I to 2 August 2028, Article 50 largely unchanged.
• OpenTelemetry semantic conventions, GenAI attribute registry — gen_ai.agent.*, gen_ai.tool.* and the gen_ai.operation.name values, all at Development stability.
• Model Context Protocol specification, 2026-07-28, Tools — "Log tool usage for audit purposes", and the rule that the tool set must not vary per connection but may vary by the authorization presented.
• 2026 Identity Security Landscape, Palo Alto Networks — 109:1 machine to human identities, up from 82:1, 37% able to revoke an agent's credentials, 30% with immutable audit logging.
• 2026 Identity Security Landscape overview, Palo Alto Networks — the survey base of more than 2,900 cybersecurity decision-makers.
• 2025 Federal Agency AI Use Case Inventory, OMB — the consolidated CSV behind the counts above: 3,611 use cases, 41 agencies, 445 high-impact, and the hi_ongoing_monitoring and hi_failsafe_presence columns.
• OMB Memorandum M-25-21 — dated 3 April 2025, the definition of high-impact AI and the annual public inventory requirement at 3(b)(v).
• Agent Access Control Taxonomy — the enforcement point and audit granularity dimensions; in-prompt against gateway for where a decision sits, and per-action-with-principal-chain for the four things worth capturing per call.
• OWASP Top 10 for Agentic Applications 2026 — published 9 December 2025, the taxonomy that names ASI03 Identity and Privilege Abuse and ASI10 Rogue Agents.