IMDA released MGF v1.5 at ATxSummit 2026. One case study shows what enforcement-layer governance actually requires. Read the analysis →
agentic AIAI governanceenforcement layerauthority architectureruntime governanceSingapore

The Path Is the New Surface

Arjen Hendrikse · · 5 min read

Aivance Analysis | Agentic AI Governance

Why several unrelated teams just built the same thing

Something worth noticing has happened quietly over the past eighteen months. A pre-seed startup out of the Netherlands, an internal team at Microsoft, and half a dozen academic research groups working independently have all converged on the same architectural conclusion about securing AI agents. None of them appear to have been reading each other’s work when they started. They arrived at the same place anyway.

The conclusion is this: checking whether a single action is allowed tells you almost nothing about whether an agent is safe. An agent that reads a customer record is doing something ordinary. An agent that sends an external message is doing something ordinary. An agent that reads a customer record and then sends an external message, in that order, within the same task, is doing something that should never have been allowed to happen. Every existing control that evaluates one step at a time, whether it is an identity policy, a content filter, or a prompt-level instruction, is structurally blind to that sequence. It sees two permitted actions. It never sees the breach.

Once you frame the problem this way, the design that falls out of it is fairly constrained. Something has to sit close enough to the agent to see its full history within a task, evaluate each new step against that history rather than in isolation, and make a decision before the step executes rather than after. Call it a kernel, a fabric, a gateway, or a policy engine. The label varies. The shape does not.

Where the mechanism lives

The clearest split across the current field is where this checkpoint sits relative to the agent.

Some approaches build it directly into the agent’s own process. A small set of startups and research prototypes take this path, reasoning that anything outside the process is a hop an attacker or a misconfiguration can route around. The tradeoff is integration effort: every framework and every deployment environment needs its own hook.

Others build it as a gateway or proxy that tool calls pass through on their way out. This is easier to bolt onto an existing stack and easier to centralize across many agents at once, at the cost of being one more network hop and one more thing that has to stay reachable for the agent to function at all.

A third group works upstream of both, on agent identity and privilege. Rather than evaluating the sequence of actions directly, these systems reason about how much privilege an agent should hold at a given moment and escalate to a human when the requested privilege crosses a risk threshold. This is a genuinely different lever. It does not require modeling the path explicitly, but it also cannot catch a harmful sequence built entirely out of individually low-risk, already-granted permissions.

None of these three is strictly better. They answer slightly different questions, and a mature deployment will likely need more than one, a point that lines up with how we mapped the tooling stack in The AI Governance Enforcement Layer: most organisations end up combining controls rather than picking a single winner.

The platform-native version

The fourth version of this story is the one that changes the calculus for everyone else building in the category: the platform vendors are building it themselves. Microsoft has published a policy toolkit with the same allow, deny, warn, escalate verdict structure showing up independently elsewhere in the field, alongside a reference pattern for a shared authorization checkpoint that every agent call passes through before touching a tool. Neither is a mature, universally adopted product yet. But it is a strong signal about where the ground is likely to shift, because a governance layer that ships free and pre-integrated with the agent framework an enterprise has already standardized on is a hard thing for a standalone vendor to compete against on adoption alone, whatever the technical merits of either approach.

This does not make the independent vendors irrelevant. Multi-cloud and multi-framework organisations, and anyone who needs the checkpoint to work identically regardless of which platform an agent happens to run on, still need something platform-agnostic. But it does mean the category’s near-term shape depends heavily on how far the platform vendors take their own native versions, and how much appetite regulated institutions have for depending on a single vendor’s definition of what a safe sequence looks like.

What actually matters for a regulated institution

Strip away the vendor names and the architecture debate resolves into three questions worth asking of any of these approaches.

Does it see the full sequence of a task, or only one action at a time? If it is the latter, it will miss exactly the class of harm this whole category exists to catch.

Does evaluating an action require sending your data outside your own environment to do it? For an institution answering to MAS AIRG or IMDA’s governance framework, this is not a minor implementation detail. Where the data goes during the check is itself a governance question, separate from whether the check is any good.

Does the mechanism produce its own evidence as a byproduct of enforcing, or does it require a second, separate system to document what happened? A control that has to be reported on by hand is a control that will eventually go unreported.

None of the current entrants answer all three questions the same way, and the field is early enough that the honest answer to “which of these is right” is that it has not been settled yet, by the market or by regulators. What does seem settled, at least provisionally, is the underlying premise: the sequence is the risk, not the individual step, and any governance approach that cannot see the sequence is answering a question the agent has already moved past.


Aivance works with CROs, CISOs, and Enterprise Architects deploying autonomous AI in Singapore and Southeast Asia. The complimentary 30-Minute Enforcement Gap Review maps whether your current controls evaluate actions one at a time or see the sequence a task actually took. You leave with a one-page diagnosis on Aivance letterhead within 48 hours. Book your review here.

AH
Arjen Hendrikse
Founder of Aivance Consulting. ISO/IEC 42001:2023 Lead Auditor. Thirty years working at the edge of what technology can do. More about Arjen
This article was drafted with AI assistance and reviewed for accuracy by Arjen Hendrikse before publication. AI Use Policy

Put what you just read to work

If this article raised questions about your own governance posture, the 30-Minute Enforcement Gap Review is the right next step. 30 minutes, complimentary, with a one-page diagnosis on Aivance letterhead within 48 hours.

Book Your Enforcement Gap Review