As enterprises in the region start to deploy autonomous multi-agent workflows, a silent and far more dangerous risk is manifesting in the corporate boardroom. Organisations from Singapore to Jakarta are rapidly offloading complex execution pipelines to agentic systems, yet they are confronting a profound governance and operational vacuum. While companies celebrate immediate drops in frontline cycle times, they are quietly grappling with the invisible atrophy of domain expertise within their leadership tiers and a structural over-trust in algorithmic outputs once systems achieve prolonged reliability. The current enterprise landscape is increasingly defined by a precarious reliance on superficial compliance checkboxes and borrowed human credentials, leaving firms deeply exposed to regulatory breaches, cybersecurity vulnerabilities, and flawed productivity metrics that borrow heavily against next quarter’s incident response time.
Countering this unchecked rush toward total automation is a growing movement among digital trust practitioners advocating for a structural shift in enterprise architecture. The emerging consensus is clear: preventing critical system failures requires moving past the naive assumption that AI safety is simply a manager-training problem. Instead, forward-thinking organisations are pioneering “governance-by-design” frameworks that treat autonomous agents as distinct digital identities equipped with scoped permissions, continuous verification, and intentionally frictional checkpoints. By mandating checkpoints that are structurally inconvenient to bypass and establishing end-to-end traceability before deployment, these architectures ensure that meaningful human-in-the-loop oversight is preserved rather than reduced to mere rubber-stamping theatre.
We explore why the shock Ohmyhome divestment marks the end of an era for regional proptech
To unpack how organisations can strike a definitive balance between autonomous efficiency and absolute accountability, we speak with Jasie Fon, Regional Vice President Asia at Ping Identity, who is a leading digital trust and AI governance strategist. In this exclusive conversation, we explore the hidden liabilities of invisible multi-agent chains, the necessity of measuring rework rates alongside end-to-end cycle times, and how shifting APAC data protection regimes are penalising firms that fail to establish granular code and data attribution. We dive deep into why enterprise security must transition toward dynamic, context-aware access, and why building structural friction into autonomous workflows is the ultimate paradigm shift for the future of corporate governance in Southeast Asia.
How can boards prevent managers from over-trusting autonomous systems and ensure meaningful human-in-the-loop checkpoints are maintained?
Boards tend to think about this as a training problem, teach managers to be more sceptical, and that’s the wrong frame. The honest issue is that approving agent-driven work feels the same as approving human work, and it isn’t. When a manager signs off on a colleague’s output, they’re usually drawing on some accumulated sense of that person’s judgment. With an agent, there’s no equivalent track record unless someone has deliberately built one.
What I’d push boards to do instead is mandate checkpoints that are structurally inconvenient to skip—not a checkbox in a workflow tool, but a requirement that certain categories of agent-initiated action (anything touching financial systems, customer data, or external commitments) literally cannot execute past a certain point without a logged, attributable human decision. The friction is the point. If the checkpoint is easy to wave through, it will be waved through, especially once the agent has been right ninety times in a row. That’s actually the most dangerous moment for over-trust—not when the system is new, but once it’s been reliable for a while and the checkpoint starts to feel like theatre.
If AI agents do the heavy lifting, do we risk creating a corporate leadership tier that lacks the domain expertise needed to audit the work they sign off on?
Yes, and I think it’s already happening quietly. The risk isn’t that leaders become lazy; it’s that the skill of evaluating work atrophies differently from the skill of doing work, and organisations haven’t noticed the gap forming until something breaks. A developer who reviews AI-generated code for five years without writing much of their own code starts to lose the instinct for where bugs hide, because that instinct comes from having been burned by their own mistakes, not from reading someone else’s output.
The fix isn’t to ban agents from doing the heavy lifting; that ship has sailed. It’s to deliberately preserve certain “manual” steps for the people who will eventually need to sign off on judgement calls. As organisations pursue AI-driven productivity gains, they need to ensure the focus is not simply on doing things faster, but also on improving quality and preserving the time and experience needed for effective oversight and learning.
Some firms are already doing a version of this in compliance and legal teams, where junior staff are still required to build certain analyses from scratch even though a tool could do it faster, specifically so they retain the ability to catch the tool being wrong later. The goal is not to reject efficiency, but to build the human judgement, quality control capabilities and trust that organisations will ultimately depend on when AI systems make mistakes.
When agentic workflows make execution invisible, how should business leaders accurately measure productivity and capture the ROI of saved time?
Most of the productivity numbers companies report right now don’t hold up to scrutiny. That’s not because anyone is lying. It’s because nobody has a reliable way to measure what they’re claiming. If an agent chains together six tool calls and a manager sees one approved outcome, you can’t attribute the time saved to that one visible step, because you don’t know how much of the prior process was redundant, wasteful, or quietly wrong in a way that didn’t matter this time.
I’d measure two things instead of one. First, cycle time on the outcome, end to end, not the human’s slice of it, the whole thing, because that’s the number that matters to the business. Second, and this gets skipped constantly, the rework rate: how often does output that was approved at the checkpoint later need to be corrected, reversed, or escalated? A process that looks fast because nobody’s watching the middle of it isn’t fast; it’s just deferred. Real ROI shows up in the second number, staying low while the first number drops. If the first number drops and the second one creeps up, you haven’t gained productivity; you’ve borrowed against next quarter’s incident response time.
Who is legally and regulatorily accountable when a compliance breach or error occurs deep within a multi-agent chain of actions?
Right now, in most jurisdictions, the honest answer is: whoever the regulator can reach, which is usually the company, and within the company, whoever approved the workflow that triggered the chain, regardless of whether that person could have reasonably seen what happened three steps downstream. That’s an uncomfortable answer, and it’s one reason I think the accountability question is actually the one forcing organisations to take agent governance seriously, more so than the productivity argument.
This is going to keep shifting as regulation catches up. The EU’s approach to AI liability and various APAC data protection regimes are moving toward looking at the deployer’s due diligence rather than just the outcome, which changes the incentive. If regulators start asking “did you have logging, scoped permissions, and a defined escalation path,” not just “did the breach happen,” then the organisations that invested in traceability before they were forced to will be in a materially different position than the ones that didn’t. I’d rather a client be over-prepared for that conversation than rely on the argument that “the agent did it.”
Why must enterprise security shift from letting AI agents “borrow” human credentials to treating them as distinct digital identities with scoped permissions?
Because the moment an agent is using your credentials, every log entry it generates says it was you. If that agent gets compromised, behaves unexpectedly, or is simply doing something at 3 am that you never asked it to do, your security team has no way to tell the difference between you and the agent acting in your name. You can’t audit, throttle, or revoke an action you can’t distinguish.
Giving agents their own identity with scoped permissions isn’t really an extra layer of bureaucracy; it’s the same logic that’s existed in identity management for thirty years, just extended to a new category of actor. Least privilege, defined lifespan, clear ownership: an agent’s access should be provisioned, reviewed, and deprovisioned the same way you’d manage any employee’s, except faster, because agents spin up and down far more often than people change roles. Borrowed credentials made sense as a shortcut when agents were a handful of scripts. They stop making sense the moment an agent is initiating chains of action across systems on its own.
How can organisations guarantee absolute code and data attribution to clearly distinguish between work done by an agent versus a human?
I’d push back gently on “guarantee.” Absolute attribution is a hard claim to stand behind once you have agents calling other agents, some of which were built by third parties whose internal logic you don’t control. What’s achievable is something close to it: every action tagged at the point of execution with the identity that performed it, agent or human, time stamped and tied back to the request that triggered it. That gives you a chain you can reconstruct after the fact, even if you can’t always say in real time, with total certainty, where a piece of generated code or content originated.
The organisations getting this right are the ones treating attribution as an architecture decision made before deployment, not a forensics exercise after something goes wrong. By the time you’re trying to reconstruct attribution after an incident, you’re usually working backward from incomplete logs, and that’s a much weaker position than having designed the system to log identity by default.
What technical guardrails are required to give autonomous agents deep system access without expanding a company’s cyber-attack surface?
The instinct a lot of security teams have is to either lock agents down so tightly they’re useless, or give them broad access because scoping permissions for every individual task is slow. Both are mistakes. What works is dynamic, context-aware access—permissions that expand for the duration of a specific task and contract immediately after, rather than a static role that sits there as a standing liability whether the agent is using it or not.
Pair that with continuous verification rather than one-time authentication. An agent that was legitimate when it started a workflow ten steps ago isn’t automatically still trustworthy at step eleven, especially in a multi-agent chain where one compromised or manipulated agent further upstream can pass bad instructions downstream without anything looking wrong on the surface.
You also need behavioural baselining: knowing what normal looks like for a given agent’s pattern of system calls—because an agent doing something unusual is often a better early signal than an agent doing something explicitly disallowed. The attack surface problem with agentic AI isn’t really that agents have access. It’s that access tends to be granted once and forgotten, and an agent, unlike a person, can use that forgotten access thousands of times a day without anyone noticing it’s still open.