Arjen Hendrikse, Founder, Aivance Consulting
The three documents released by IMDA on 20 May 2026 are worth reading together, not separately. The ATxSummit press release, the updated Model AI Governance Framework for Agentic AI (MGF v1.5), and the Google-Singapore AI Agents Sandbox report tell a coherent story about where Singapore’s AI governance is headed, and where it still has ground to cover.
I want to focus on a specific gap, because it matters practically for every organisation deploying agentic AI right now.
What the case studies actually show
The shift from the January 2026 MGF to today’s version is real. The original framework was principled but abstract. Version 1.5 names specific patterns, with over ten case studies showing how organisations have operationalised each dimension.
Most of the case studies describe governance at the policy and application layer. Dayos built a tiered autonomy model: Tier 1 actions (password resets) are fully automated, Tier 2 (chart of accounts updates) requires human approval before the agent can act, Tier 3 (security changes, permissions modifications) the “agent does not touch.” The Tencent CodeBuddy case study shows checkpoint-based human approval: the system defines which actions require sign-off, explains complex commands in plain English, and flags suspicious commands even if they had been previously whitelisted.
These are meaningful patterns and worth studying closely.
Then there is the Terminal 3 case study, which is in a different category.
Terminal 3 is a Hong Kong-based data privacy infrastructure company that deployed a finance payroll agent to automate its monthly payroll cycle. The process is high-stakes: sensitive personal data, financial transactions, government-mandated contributions. Their implementation works like this:
Before the monthly cycle begins, the HR director issues a Verifiable Credential of Intent to the agent: a mathematically binding, cycle-scoped authorisation defining which employee records the agent can access, the applicable contribution rates, expense claim thresholds, and the ceiling amount for the consolidated bank transfer. All sensitive personal data is held exclusively within a Trusted Execution Environment (TEE) and never transmitted to the agent at any point. The agent operates on opaque reference identifiers only. Every agent action is routed through the TEE and verified against the credentialed parameters at hardware speed. Out-of-scope actions, whether from erroneous reasoning or adversarial inputs, are blocked before execution. The audit trail is recorded on an immutable ledger with hardware attestation.
This is what enforcement-layer governance looks like. Authority is defined in a cryptographically verifiable credential before the agent runs. The boundaries are enforced at hardware speed, not in application code. Sensitive data is architecturally separated from the agent’s context so there is nothing to extract. The audit trail cannot be modified after the fact.
Where most case studies stop
The Terminal 3 case study is useful precisely because it makes visible what the other case studies do not address.
When Dayos says Tier 3 actions are ones the agent “does not touch,” that is a statement about application design. The Dayos team has chosen not to build those capabilities into the agent’s workflow. That is a reasonable and practical choice at the current maturity of agentic AI. But it is not an enforcement boundary. If the service account running the agent has the IAM permissions to take Tier 3 actions at the infrastructure layer, the restriction is only as durable as the application code and the judgment of whoever configures it.
When Tencent CodeBuddy flags “suspicious commands” for human approval even when the command type had been whitelisted, that classification logic lives inside the system. The sandbox report flagged indirect prompt injection, a class of attack where an agent is deceived by content it processes into performing unintended actions. A classification system that can be circumvented by manipulating what the agent has read is not a technical control. It is a policy with an exception condition that an attacker can trigger.
This is not a criticism of Dayos or Tencent. They are describing practical governance for real deployments. The distinction matters because when organisations read the MGF, they should understand that the case studies span a range from policy-layer to architecture-layer enforcement, and most of them sit at the policy layer.
The framework itself names the gap
What is notable about MGF v1.5 is that it does not pretend otherwise. The identity and permissions section of the framework states directly:
“Current authorisation systems typically have pre-defined, static scopes. However, to operate safely in more complex scenarios, agents require fine-grained permissions that may change dynamically depending on context, risk levels, and task objectives. Current authentication systems are also typically based on a single, unique individual. Such systems face difficulty in handling complex agent setups, such as when agents act for multiple human users with different permissions, or recursive delegation scenarios where agents spin up multiple sub-agents.”
The framework acknowledges this is an evolving space and references emerging solutions (OAuth 2.1 integration into MCP, decentralised identity management, the Cloud Security Alliance’s agentic IAM framework). It recommends interim best practices: unique cryptographic agent identities, scoped and time-bound authorisations, centralised agent identity catalogues.
IMDA’s own OpenClaw case study in the framework makes the same distinction explicitly: “Enforce human approval through system-level controls where possible, vs prompt-layer guardrails, which may be bypassed or ‘forgotten’.”
The framework is telling organisations that prompt-layer restrictions are weaker than system-level ones. That is correct. And it is the central design question most organisations are not yet asking when they implement the MGF.
What this means for organisations deploying agents now
The deployment acceleration announced at ATxSummit (the S$300 million OpenAI partnership, the Punggol Digital District testbed, GovTech’s expanding rollout of coding assistants) is real. The organisations receiving those signals from their leadership are the same organisations whose governance teams are trying to implement the MGF.
The practical question is not whether to implement tiered autonomy or human approval checkpoints. Those are necessary starting points. The question is what layer those controls operate at.
For lower-risk deployments, application-layer governance is a reasonable starting point, especially in early phases where the blast radius is contained. For deployments involving sensitive data, financial transactions, or irreversible real-world actions, the Terminal 3 case study shows what governance needs to look like at the architecture level: credentials that define authority before execution, enforcement that operates independently of application code, and audit trails that cannot be modified after the fact.
The MGF v1.5 provides the vocabulary and the starting examples. Closing the distance between a governance policy and a system where that policy is enforced architecturally is the work that sits between the framework and the production deployment.
Arjen Hendrikse is the founder of Aivance, an AI governance consultancy in Singapore focused on the technical implementation of governance frameworks for agentic AI systems.