ENFORCEMENT ARCHITECTURE · SEPTEMBER 2026 · 3 MIN
The floor has to be in the path
Why governance that depends on a network call is not governance.
When a governance layer enforces its rules by calling an external service, it has introduced a dependency it cannot control. The service may be slow. It may be unreachable. The tenant may have misconfigured the endpoint. In each of these cases the system faces a choice: fail open, or fail closed. Failing closed breaks the agent. Failing open means the governance layer did not govern.
The only resolution is to enforce in the execution path itself. Not adjacent to it, not downstream of it — in it. Before the model call returns. Before the tool executes. The decision has to be local, synchronous, and impossible to bypass by timing, configuration, or network failure.
This is not a performance optimisation. It is the difference between a governance floor and a governance suggestion. A floor holds under failure. A suggestion holds when conditions are favourable.
The HuggingFace agent intrusion in July 2026 took 17,600 actions over four days. The attack succeeded in stages, each stage depending on the previous one not being stopped. A governance layer that can be bypassed by a timeout, a misconfigured endpoint, or a container restart is not a layer — it is a gate with an unlocked side door.
VARC’s Policy Bus runs every shield check in-process, in parallel, before the model call completes. The tenant cannot configure this away. The floor is not a policy. It is the execution path.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
RUNTIME GOVERNANCE · SEPTEMBER 2026 · 9 MIN
A log is not evidence
A log records that something happened. Evidence establishes what was permitted, what was applied, what was decided and by whose authority — in a form a party who was not present can verify without taking your word for it.
I have watched a lot of examination preparation over the years and it always has the same rhythm. A date appears. A programme forms. Somebody builds a tracker. For eight weeks a group of capable people assemble artefacts, reconcile them against a request list, and rehearse the answers.
That rhythm works when the thing being examined holds still between examinations. A lending policy holds still. A capital model holds still, more or less, and when it changes there is a change record with a date on it and a person who signed it.
An autonomous agent does not hold still, and this is the part that has not landed yet.
The artefact you validated is not the thing that is running
An agent chooses its own route through the tools available to it. It calls other agents. It reads sources that were not in scope when it was reviewed. Its behaviour on Thursday can differ materially from its behaviour on Tuesday with no code change, no release, and no ticket to point at — because a tool returned something different, or the context window filled differently, or an upstream agent phrased a handoff another way.
So when an examiner asks what the agent did in March, the honest answer in most institutions is a reconstruction. Here is the application log. Here is the prompt template we believe was in force. Here is the model version we think was deployed. Here is a person who remembers approving something adjacent. Every step of that chain is an inference, and every inference is a place where the examination goes badly.
What an evidentiary record actually has to carry
This is worth being precise about, because a lot of programmes are being run on the assumption that more logging solves it.
- The action proposed, normalised to a form that does not depend on which platform the agent happened to be running on.
- The behavioural contract in force for that agent at that moment, identified by revision.
- The scoring model applied, identified by version — because a score of 0.72 means nothing without knowing what produced it.
- The thresholds in force at that timestamp, snapshotted rather than looked up later, because thresholds move as an institution tunes its posture.
- The enforcement decision and the level at which it landed.
- The accountable owner, resolved at the time, not reconstructed from an org chart that has since changed twice.
- A signature over all of it, on a chain that breaks if anything is modified afterwards.
Every one of those fields is only available at the moment the decision is made. None of them can be added retrospectively. That is why runtime is not an architectural preference or a vendor's opinion about where software should sit — it is the only point in the lifecycle where the evidence physically exists.
The verification property nobody asks about early enough
There is one more requirement, and it is the one most often skipped because it sounds academic until it isn't. The record has to be independently verifiable. A third party should be able to confirm it has not been modified without trusting the vendor that produced it.
A governance record you have to take a vendor's word for is not evidence. It is marketing with a timestamp. Ask any vendor in this space a single question: can my examiner verify this record without calling you? If the answer requires a person to vouch for a step, you are buying a monitoring product with a compliance label on it.
The uncomfortable implication
If you accept the argument to this point, one conclusion follows that most governance programmes are not structured to handle.
An institution that instruments its agents today has evidence starting today. It does not have evidence for last quarter, and no amount of programme effort will produce it. The window for the period you are currently operating in closes continuously, every hour, whether or not anyone has approved a budget.
There is no date to prepare for. The record is being written or it is not, right now.
When the examination does arrive — and the supervisory guidance now makes clear that it will — it will look backwards at a period during which you either had the instrumentation or you did not. That is a decision you are making this quarter by default, whether or not anyone has framed it as a decision.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
FLEET INTELLIGENCE · SEPTEMBER 2026 · 8 MIN
Every agent behaved. The fleet did not.
Five agents, each operating inside its own permitted envelope, can between them complete a path that none of them was authorised to complete. Per-agent scoring is structurally unable to see it.
Ask a risk function how it governs AI agents and you will usually get an answer shaped like a list. Here are our agents. Here is what each one is permitted to do. Here is the control that checks each one against its permissions.
That model is not wrong. It is just incomplete in a way that becomes dangerous at scale, and the danger arrives silently.
The path nobody authorised
Consider a procurement chain. One agent onboards a vendor. A second raises a purchase order. A third matches an invoice. A fourth approves within a delegated limit. A fifth releases payment. Each has a narrow, sensible, individually defensible envelope. No single one of them can move money from nothing to a bank account.
Between them, they can. And if the five happen to share a tool endpoint, or hand off through a common mailbox, or simply act in a correlated sequence, the composite behaviour is something no individual agent was ever assessed against.
Now score each one. Every score comes back clean. Every control reports green. The estate looks healthy right up until somebody traces the transaction backwards after the fact and discovers that the path existed all along, assembled out of five perfectly compliant parts.
Why this is structural, not a tuning problem
It is tempting to think the answer is stricter per-agent thresholds. It is not, for the same reason that tightening individual trading limits does not detect a structuring pattern. The signal is not in any single observation. It is in the relationships between them.
So the estate has to be scored as a graph rather than a list. Agents are nodes. Delegations, shared tool endpoints, mailbox handoffs and timing correlations are edges. Once you have that structure, the question changes from is this agent behaving to is this group of agents behaving as a group — and densely connected subgraphs are where coordinated behaviour concentrates, because coordination requires connection.
What the graph actually surfaces
- Cliques. Subgroups with far more internal connectivity than the estate average. Sometimes legitimate — a tightly coupled workflow. Sometimes not.
- Shared endpoints. Several agents converging on the same external resource is an edge type, not a coincidence, and it is how a poisoned tool response propagates.
- Timing correlation. Agents that repeatedly act within a narrow window of each other are related whether or not anyone designed them to be.
- Orphaned density. A clique whose members have drifted to different owners, or no owner, is a governance problem before it is a security problem.
Two design details matter more than they sound. The first is temporal decay: an association from six months ago should not keep scoring as though it happened this morning, or every mature estate eventually looks like one giant clique. The second is that a swarm score has to be able to raise an alert on the group even when no member breached individually — otherwise you have rebuilt per-agent scoring with extra steps.
The uncomfortable part for the org chart
This creates a question most institutions have not answered: who owns a clique?
Each agent has an owner. The group does not. So when the graph raises a swarm alert, the routing question is genuinely hard — and in practice the alert lands with whoever is least able to refuse it rather than whoever is best placed to act.
An estate can be fully governed agent by agent and completely ungoverned as a system.
Worth resolving that ownership question before the first alert rather than during it. My experience is that the argument about who owns the composite is much easier to have on a Tuesday morning with a whiteboard than at eleven at night with a transaction to unwind.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
ENFORCEMENT DESIGN · AUGUST 2026 · 7 MIN
Why binary allow-or-block always gets switched off
Set the threshold tight and operations disables the control. Set it loose and you have a monitoring product wearing an enforcement badge. Neither survives contact with a production estate.
Every control that gets built for a production environment eventually faces the same test, and it is not a technical test. Somebody senior, under time pressure, decides whether the control stays on.
I have watched that meeting many times across three decades, in change management, in DLP, in fraud systems, and now in AI governance. The pattern does not vary much. If the control has blocked legitimate work more than a couple of times, it gets an exception process. If the exception process gets used more than a couple of times, the control gets disabled, and the disabling is documented as a risk acceptance nobody revisits.
Both settings fail
A binary gate has exactly one parameter, and neither end of it works.
Set it tight and the control blocks work the business needs done. The first time an agent is stopped from completing a legitimate payment at quarter end, you will be in a room explaining yourself, and the outcome of that room is rarely that the control stays as configured.
Set it loose and the control passes everything that matters. It produces alerts, dashboards and a quarterly report. It cannot honestly be described as enforcement, because it has never actually stopped anything, and eventually somebody asks the obvious question.
The graduated alternative
The design that survives is a ladder rather than a gate. Roughly five levels, and the shape matters more than the exact labels:
- Observe. Action permitted, attested, recorded. The overwhelming majority of traffic lands here, which is the entire point.
- Flag. Action permitted but marked for review, so a pattern accumulates rather than evaporating.
- Human in the loop. Action held for a named person. Not a queue — a person, with the reasoning presented so the decision takes seconds rather than an afternoon.
- Freeze. The session stops and the reason is retained. This is where fail-closed actually means something.
- Decommission. The agent's permissions are reduced automatically at the identity layer, without waiting for a human to remember to do it.
The property that makes this work is unglamorous: most decisions land low. A control that rarely interferes is a control that stays switched on, which means it is there on the day it matters. That day is the only day the investment was ever for.
History has to count
There is a second reason a ladder beats a gate, and it is about intelligence rather than diplomacy.
The same request from an agent with a clean record and an agent that has accumulated governance debt over the past month should not receive the same response. A gate cannot express that. A ladder can, by weighting accumulated risk over a rolling window and escalating an agent's baseline position rather than waiting for a single request to cross a fixed line.
That is the difference between rule matching and behavioural intelligence, and it is also what makes the control hard to game. A fixed threshold can be probed until you find the phrasing that sits just underneath it. A position that moves with your history cannot.
The write-back that closes the loop
One last piece, usually missing. At the top of the ladder, remediation should not require a human in the path. If an agent has earned decommissioning, the reduction of its permissions in the identity platform should happen automatically.
A control that can detect but not act is an alerting system. Alerting systems do not prevent findings.
The uncomfortable truth is that most governance products stop one step short of this, because writing back into the identity platform requires a level of integration and trust that is harder to sell than a dashboard. It is also the only part of the chain that actually removes the exposure.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
MODEL-AGNOSTIC GOVERNANCE · SEPTEMBER 2026 · 8 MIN
The model doesn’t matter. The governance layer does.
An estate that runs one model family for customer work, another for code and a third on-premise needs a control that holds across all three. If it only works on one vendor, it is a vendor feature, not governance.
Every enterprise I speak to has the same architecture diagram, drawn slightly differently. One model family for customer-facing work. Another for code. A third, often open-weight and hosted internally, for data that cannot leave the building. Sometimes a fourth that a business unit adopted without asking anyone.
That is not a failure of standards. It is the rational outcome of a market where no single vendor is best at everything and the prices move every quarter. Multi-model is the steady state, not a transition.
Which raises a question most governance programmes have not answered: does your control hold when the model underneath it changes?
What we tested
We put twenty-four agents into a single governed estate, three from each of eight model families — Gemini Enterprise, OpenAI GPT, xAI Grok, Mistral, Meta Llama, DeepSeek, Anthropic Claude and Perplexity Sonar. Each agent was driven through the same nine-stage attack sequence: reconnaissance, credential access, PII exfiltration, scope creep, tool abuse, delegation escalation, covert channel, data fabrication and command-and-control.
That is 216 governed checks. The same deterministic engine scored every one of them, regardless of which model produced the action.
- 204 of 216 detected — 94% across the fleet.
- Six of the nine stages caught on every agent in every family, including PII exfiltration and data fabrication.
- Three families at 100%: Gemini Enterprise, OpenAI GPT and xAI Grok. Mistral at 96%, Llama and DeepSeek at 92%, Claude at 88%, Sonar at 85%.
The two families below 90% were both fresh deployments whose behavioural baselines had not yet settled. That is a warm-up effect rather than a ceiling, and it is exactly the kind of result worth publishing rather than smoothing over — because a governance vendor that only ever reports 100% is telling you it did not test anything difficult.
Why the vendor ranking is the wrong headline
It is tempting to read that table as a league table of model safety. Resist it. The spread between families is narrow, it moves between runs, and it says more about how each family phrases a malicious action than about how dangerous it is.
The finding that matters is the other one. The same governance layer, with the same signatures, the same policy bus and the same behavioural contracts, produced consistent results across eight vendors it has no relationship with. The control did not need to know which model it was governing.
If your governance only works on one vendor’s models, you have bought a vendor feature and called it a control.
The cost of a model judging a model
There is a second reason the design matters, and it shows up on the invoice.
A lot of AI safety tooling works by asking a second model whether the first model’s output was acceptable. That approach has an intuitive appeal and two structural problems. It inherits the failure modes of the thing it is supervising — the judge can be manipulated by the same phrasing that manipulated the agent. And it doubles the model spend, because every governed action becomes two model calls instead of one.
Deterministic scoring avoids both. The entire 216-check run cost a hundredth of a cent. Projected across a 1,200-agent estate spanning all eight families for seventy-two hours, the governance layer costs about a dollar and twelve cents, because it never makes a model call to decide whether a model call was acceptable.
That number is the one I would put in front of a CFO. Governance that scales with the estate rather than with the model bill is governance that stays switched on.
What to ask your own vendors
- Which model families has the control been tested against, and will they publish per-family results rather than one flattering aggregate?
- Does the control call a model to make its decision? If so, what stops the same manipulation that fooled the agent from fooling the judge?
- What happens to the control’s cost when your agent count triples?
The model will change. It probably changes next quarter. Buy the layer that does not have to.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
INTEGRATION · SEPTEMBER 2026 · 7 MIN
Governance at the tool boundary
Agents do their damage through tools. If governance cannot see the tool call before it executes, and verify the response when it comes back, it is governing the conversation rather than the action.
For most of the last two years, AI governance has been built around the prompt. What went in, what came out, whether either contained something it should not. That made sense when the model’s output was the product.
It makes much less sense now. An agent’s output is rarely the product. The product is what it does with tools: the payment it releases, the record it updates, the file it sends, the other agent it delegates to. The text in between is the least consequential part of the transaction.
Where the damage actually happens
Look at the agent incidents that have been documented publicly this year and the pattern is consistent. Almost none of them turned on a harmful sentence. They turned on an action — a tool call to an endpoint that should not have been reachable, a response from a tool that should not have been trusted, a delegation to an agent outside the trust boundary.
The Model Context Protocol has accelerated that shift, and for good reasons. It gives agents a standard way to discover and call tools, which is exactly what makes them useful. It also concentrates the risk at a single, well-defined boundary. That is good news, if your governance sits there.
Two things have to happen at the boundary
Before execution, the call has to be committed. The tool, the arguments and the context are captured and hashed before anything runs, so there is an immutable record of what the agent intended to do. That is the difference between a record of what happened and a record of what was attempted — and when something goes wrong, the second is the one you need.
After execution, the response has to be verified. This is the half most designs skip. A tool response re-enters the agent’s context as trusted input. If it has been spoofed, duplicated or tampered with, the agent will act on it without hesitation, because from the agent’s perspective nothing unusual happened. Reconciling each response against its commitment is what stops a poisoned response from quietly steering the next step.
Governing the prompt is governing the conversation. Governing the tool call is governing the action.
Why speaking MCP natively matters
There is a practical point here that is easy to underrate. VARC now exposes its governance tools over MCP itself — six of them, on a single Streamable HTTP endpoint: start a governed session, check a policy, commit a call, verify a response, score behaviour, and check whether an action is held for review.
The consequence is adoption speed. An agent developer can attach runtime governance the same way they attach any other tool. There is no SDK to learn, no framework adapter to maintain, and no platform team backlog to wait behind. Governance becomes a line of configuration rather than an integration programme.
That matters more than it sounds. In my experience, the controls that fail in production are rarely the ones that were badly designed. They are the ones that were too expensive to adopt, so they were adopted by the teams that needed them least and skipped by the teams moving fastest — which are exactly the teams building the most agents.
The question to ask
If you want to test whether a governance product is actually governing actions, ask it one thing: show me the record of a tool call that was attempted, blocked, and never executed.
If the answer is a log of calls that did execute, the control is sitting in the wrong place.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
DETECTION DESIGN · SEPTEMBER 2026 · 6 MIN
Four thousand, nine hundred and thirteen actions
Threshold-based detection fires when damage crosses a line. Behavioural governance fires when behaviour departs from its contract. In a multi-agent breach, those two moments can be thousands of actions apart.
When we replay a documented incident against the platform, the number people remember is not the detection rate. It is the gap.
In one publicly documented multi-agent breach, the conventional detection — the point at which the activity crossed a threshold anyone was watching — arrived at action 4,914. Replayed through VARC, the first intervention came at action one.
Four thousand, nine hundred and thirteen actions of head start. It is worth understanding why that gap exists, because it is not a story about a cleverer algorithm.
Detection that waits for the damage
Most security monitoring is built around thresholds on outcomes. Data volume leaving the network. Failed authentications per minute. Spend against a budget. Rows read from a sensitive table. These are sensible signals, and they share one property: they fire when the harm is already large enough to measure.
In a human-operated environment that was tolerable, because humans are slow. An attacker working through a system manually generates a trail at human speed, and the threshold usually trips before the damage becomes catastrophic.
Agents are not slow. An agent working through a kill chain can take thousands of individually unremarkable actions in the time it takes a threshold to accumulate. Each step is small. Each step is plausible. None of them trips anything on its own. By the time the aggregate crosses the line, the work is done.
Governance that waits for the departure
Runtime governance asks a different question at a different moment. It does not ask whether the damage is large yet. It asks whether this action is consistent with what this agent was deployed to do.
That question can be answered at action one, because the first step of most breaches is already a departure. An agent reading a data source outside its contract. A tool call to an endpoint it has never used. A delegation to an agent outside its trust boundary. Individually small, but each one is a deviation from a signed behavioural contract, and that is detectable immediately rather than cumulatively.
Threshold detection measures how much has gone wrong. Behavioural governance measures whether anything has gone wrong at all.
What the gap is worth
The honest caveat is that a replay is a replay. It shows what the platform would have done against that sequence of actions, not a guarantee against every future one. And intervening at action one only matters if the intervention is graduated — a control that blocks every early deviation will be switched off by operations inside a week.
But the structural point holds regardless of the specific incident. Detection that waits for damage will always arrive late against an adversary that operates at machine speed, because the damage accrues at machine speed. The only position that gets ahead of it is inside the decision path, before each action executes, measured against what that agent was allowed to do.
That is not a smarter version of the old approach. It is a different place to stand.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.