The hardest question I hear from enterprise buyers isn’t about what AI agents can do. They’ve seen the demos and they believe the capability. What stops them comes from the risk committee, and it’s almost always the same question. “If one of these agents does something wrong, can we show exactly what it touched, why, and on whose authority?”
In most organisations I work with across Southeast Asia, the honest answer today is no. That isn’t because they lack governance tools. Usually they have too many. There’s a data catalogue owned by the data office, model monitoring owned by the AI team, an API gateway owned by platform engineering, and identity and security tooling owned by the CISO. Each works as designed. None of them can reconstruct the full path an agent took from prompt to data to model to action.
That is my argument. Agentic AI hasn’t created a new governance problem so much as it has exposed a structural one. When autonomous software crosses every boundary your controls were built around, fragmented controls become fragmented evidence. The fix isn’t another point tool. It’s a single control plane where data governance, AI observability and routing, and security are enforced and recorded together.
Agents are a new class of actor, and most controls don’t treat them that way
Traditional governance assumes two kinds of actors. People authenticate and get role-based access, and applications follow fixed, reviewable code paths. An agent is neither. It acts on someone’s behalf, but it decides at runtime which tools to call, which data to retrieve, and which systems to write to. OWASP’s Top 10 for LLM Applications names “excessive agency” as one of the core risks for exactly this reason. The danger isn’t only that a model says something wrong. It’s that the model is allowed to do too much, with too little oversight.
When I walk through deployment plans with banking and energy clients, the permission model is often inherited from whatever service account the pilot team set up. That account usually has far broader access than any single task needs. Nobody chose that on purpose. There was simply no layer where an agent’s scope could be defined, enforced, and reviewed as a governed identity.
When we built a governance test environment modelling a pan-Asian life insurer, with customer records spanning Hong Kong, Singapore, Thailand, and the EU, we seeded it the way real data estates tend to look. One scenario covers a set of Thai-resident health records already sitting offshore in Hong Kong, a residency problem that predates any AI use. An agent inheriting a broad service account would read that data without anyone noticing. Nothing about the violation is visible from the agent’s side. Only a layer that knows both the data’s classification and where the request is going can catch it.
Fragmented tooling produces fragmented evidence
Say an agent in a financial institution summarises a customer’s transaction history, flags a pattern, and drafts a case note. To defend that outcome to an auditor, you need one connected record. Which data sources were queried, and were they classified as sensitive? Which policy allowed the access? Which model handled the data, where was it hosted, and which version was it? What did the agent output, and did a human approve the action?
In a fragmented stack, those answers sit in four or five systems with different log formats, retention periods, and owners. Stitching them together after an incident is slow, and in practice it’s often incomplete. Policymakers and standards bodies are pointing the other way. Singapore’s Model AI Governance Framework for Agentic AI, introduced by IMDA in January 2026 (the current Version 1.5 was published on 20 May 2026 and updated on 5 June 2026), asks organisations to place limits on agents’ autonomy and access to tools and data, define checkpoints where human approval is required, and treat logging and monitoring as core components of an agent. At the regional level, the ASEAN Guide on AI Governance and Ethics, released and endorsed by ASEAN at the 4th ASEAN Digital Ministers’ Meeting in February 2024, counts accountability and integrity, and privacy and data governance, among its seven principles. NIST’s AI Risk Management Framework organises its core into four functions, Govern, Map, Measure, and Manage, and treats Govern as a cross-cutting function that informs and runs through the other three. And for financial institutions, the MAS FEAT principles have set accountability and transparency expectations for AI since 2018. None of these frameworks says it in exactly these words, but read together, my conclusion is that evidence has to exist by design, not by forensic reconstruction.
Routing is a governance decision, not just an engineering one
This is the point I find most often overlooked. Enterprises increasingly run several models. They use frontier models for complex reasoning, smaller or open models for routine tasks, and sometimes in-country models for regulated data. Deciding which model receives which request is usually treated as a cost and performance question.
In Southeast Asia it’s also a compliance question. Data residency rules, sector-specific outsourcing requirements, and customer consent terms all determine where certain data is allowed to go. If routing logic lives in application code that the data governance team never sees, you can end up with a well-classified dataset being sent to a model endpoint it should never reach. Classification and routing need to be read from the same policy, and each routing decision needs to be logged with the policy that justified it.
Observability has to cover actions, not just outputs
Much of today’s AI monitoring focuses on the model, measuring latency, token costs, drift, and hallucination rates. That matters, but it’s the wrong unit of accountability for agents. What the risk committee cares about is the action chain, which is every tool call, data read, write, and handoff between agents. A useful audit trail for agentic systems looks less like a model dashboard and more like a chain of custody. Every step is attributable to an identity, tied to the policy that permitted it, and replayable.
That’s only practical when observability sits in the same layer that enforces access and routing. If the control point and the logging point are the same, the trail is complete by construction. If they’re different systems, you’re trusting that they stay in sync, and in my experience they don’t.
A single control plane speeds deployment up rather than slowing it down
The objection I hear from innovation teams is that more control means slower delivery. I’ve seen the opposite. The pilots that stall are the ones where every new use case triggers a fresh negotiation between data, security, risk, and architecture teams, because there’s no shared mechanism to express and prove what the agent is allowed to do.
When data policy, model routing, agent permissions, and audit logging run through one control plane, approval becomes repeatable. Risk teams review the policy once, not each deployment. Auditors get evidence in a consistent format. Engineering teams build against guardrails they can see. The conversation shifts from “can we allow this?” to “which policy does this fall under?” That shift separates organisations with a handful of stuck pilots from those running agents in production.
Agents will eventually touch every system that matters in your enterprise. The question isn’t whether to allow that. It’s whether you’ll be able to prove, step by step, what happened when they did. Put the control plane in place before you scale the agents, because trust you can’t evidence isn’t really control.
