The pilot is easy. Trust is the hard part.
Most enterprise AI pilots look impressive in the first month. The agent summarises tickets, drafts memos, routes approvals, or reconciles data across systems faster than any human team could manage. The demo works. The executive sponsor is pleased. Then someone asks the only question that matters: can we trust this thing in production?
That is where many programmes stall in 2026. They stall because the organisation realises an autonomous agent is not just another interface layer. It is a new operational actor with access, authority, side effects, and failure modes that traditional governance was never designed to contain.
I have seen this pattern before in APAC transformation programmes. A Singapore bank once asked me to review an automation initiative that had reduced turnaround times beautifully on paper. The snag was not technical performance. The snag was that nobody could say, with confidence, which system privileges the automation estate had accumulated over time, who was accountable for revoking them, or how an auditor would reconstruct a disputed action six months later. The programme had speed. It did not yet have trust.
Agentic AI is now forcing that same reckoning at a much larger scale. The organisations that move from pilot to production will not be the ones with the flashiest demos. They will be the ones that can prove an agent has a clear identity, bounded authority, and a visible operational trail.
The numbers already show this is a control problem
The strongest recent evidence comes from the Cloud Security Alliance. On April 21, 2026, CSA said 82% of surveyed organisations had discovered unknown AI agents in their environments during the previous year, and 65% reported at least one AI agent-related incident in the past 12 months. Of those incidents, 61% involved data exposure, 43% caused operational disruption, and 35% carried a financial cost. Only 21% reported formal decommissioning processes for agents. That is not an innovation story. That is an estate-management story.
Go back one month and the same pattern appears from a different angle. In CSA’s March 24, 2026 IAM-focused survey, 68% of organisations said they could not clearly distinguish AI agent activity from human activity. Eighty-five percent said they already use AI agents in production environments. Seventy-four percent said agents often receive more access than necessary, and 79% believed agents create new access paths that are difficult to monitor. Only 22% said access frameworks are applied very consistently to AI agents.
Frankly, that is the trust gap in one paragraph. Enterprises are not struggling to imagine agent value. They are struggling to prove that autonomous action remains within policy once those agents touch real systems, real data, and real approvals.
This is precisely why NIST’s Center for AI Standards and Innovation launched its AI Agent Standards Initiative on February 17, 2026. NIST was explicit that agents can now work autonomously, interact with external systems and internal data, and therefore need confidence, security, and interoperability if adoption is to scale.
Why trust collapses after the pilot stage
A pilot usually runs inside a protected bubble. The data set is narrower. The workflows are cleaner. The human reviewers are unusually attentive. The connectors are few. Exceptions are manually handled. That environment flatters the technology.
Production is where the real world intrudes. A live agent does not just answer prompts. It inherits messy entitlements, stale service accounts, conflicting policies, noisy datasets, and third-party integrations. The gap between pilot and production is where trust starts to erode.
In my experience, the erosion happens across three layers.
First, identity is vague. The agent may technically exist, but it is operating under a shared account, a borrowed human token, or an inherited workload identity that no one treats as a first-class principal.
Second, runtime authority is too broad. Teams define what the agent should do in a slide deck, but they do not enforce what it must never do at the connector, approval, and orchestration layers. The result is soft governance sitting on top of hard privileges.
Third, observability is shallow. Logs may show that an API call happened, but not why the agent chose it, what context it used, whether a policy check fired, or how a human approval altered the path. That is tolerable in a sandbox. It is dangerous in production.
The hard truth is that enterprises do not fail to scale agents because they lack confidence in AI. They fail because their control plane still assumes the main actor is human.
Pillar one: identity governance has to become agent-native
The first condition for trust is simple: every production agent needs a distinct identity, a clear owner, and a defined lifecycle.
CSA’s March survey could not have been clearer. Fifty-two percent of organisations said their AI agents use workload identities, 43% rely on shared service accounts, and 31% allow agents to operate under human user identities. That is an identity grey zone, and grey zones always become audit problems before they become architecture improvements.
When an agent borrows a human identity, three things happen immediately. Accountability blurs, least privilege becomes harder to enforce, and incident response slows down because responders are no longer isolating one machine actor with one business purpose. They are disentangling a hybrid trail of human and machine behaviour. I would not accept that design for a privileged automation script touching a payments workflow. I certainly would not accept it for a reasoning system that can plan multi-step actions across several systems.
Every agent should have:
- a unique identity separate from human users
- a business owner and a technical owner
- a documented purpose statement in business language
- time-bounded and context-aware credentials
- an attestation and decommissioning process
This sounds bureaucratic until you see the alternative. I once worked with a public-sector client that had accumulated so many automation identities that no one could say which ones were still needed. The real damage was not just security exposure. It was decision paralysis. Every change review became slower because the organisation no longer trusted its own dependency map.
Pillar two: runtime controls must govern actions, not just access
Many organisations still treat agent security as a permissions problem. It is really a behaviour-and-authority problem.
An agent can hold legitimate read access to several systems and still create a business failure by combining information in the wrong way, triggering the wrong downstream action, or moving from recommendation to commitment without the right approval. This is why the trust conversation has to shift from “what can the agent access?” to “what sequences of action is the agent allowed to complete?”
CSA’s April 21 survey points to the right direction. It found that 53% of organisations allow agents to operate autonomously for low-risk tasks but require human review for higher-risk actions. Only 13% reported fully autonomous models. More importantly, when agents exceed scope, 38% said the action requires human approval, 24% require it to be logged, and only 11% automatically block it. That tells me the market has already discovered something important: risk-based delegation is becoming the real operating model.
That model needs more discipline than most pilots currently provide. High-trust production agents should operate with explicit control tiers:
- low-risk actions that can execute autonomously
- medium-risk actions that require policy checks and stronger logging
- high-risk actions that trigger human approval or a hard stop
Payments, entitlements, external communication, regulated-data export, contract changes, and policy overrides should sit in that top bucket by default. The business cost of being wrong is asymmetrical.
Microsoft’s March 20, 2026 security update is notable here because it frames the problem at platform level rather than model level. Microsoft said it is expanding Sentinel to unify context, automate workflows, and standardise access, governance, and deployment across security solutions, while also extending Zero Trust for AI.
Pillar three: observability is what turns trust from belief into evidence
Every executive says they want AI they can trust. Very few say what evidence would satisfy that standard. That is where observability comes in.
If an agent recommends a credit hold, changes a workflow route, escalates a security incident, or drafts a customer communication, the organisation needs more than a success log. It needs a record of the task, the identity used, the systems touched, the policy checks applied, the approval gates encountered, the outputs generated, and the final disposition. If the system cannot tell that story clearly, then the organisation is asking people to trust opaque automation in a context where accountability still lands on humans.
This is also where many pilot programmes fool themselves. Teams see dashboard visibility and assume they have observability. Those are not the same thing.
NIST’s new initiative explicitly includes research into agent authentication and security evaluations, while CSA’s April survey shows 79% of respondents now see context-aware controls as important over the next two years. Those two signals matter because they point toward the same destination: agent trust will depend on runtime evidence, not static policy documents.
I would go further. For most enterprises, the first production-grade observability milestone should be the ability to answer five questions in minutes, not days:
- Which agent performed the action?
- Under whose authority and for what business purpose?
- What tools, data, and identities were involved?
- Which control or approval path allowed it?
- How do we stop or roll it back now?
If you cannot answer those questions quickly, then your agent estate is not production-ready, however impressive the pilot metrics may look.
What this means for CIOs and CISOs right now
The practical agenda is not mysterious. It is just less glamorous than the market would prefer.
Build an inventory of agents, connectors, and privileges. Register every production agent as a governed identity. Separate human and agent actions cleanly in logging. Put high-risk workflows behind explicit approval rules. Require kill switches and decommissioning playbooks.
In APAC boardrooms, leaders often ask when regulation will force this discipline. That is the wrong question. By the time regulators become precise, the operational debt will already be expensive. The better question is this: what evidence would our board, auditor, or regulator expect if an AI agent caused a material incident next quarter?
The bottom line is stark. The agentic trust gap is not a philosophical problem about whether machines deserve confidence. It is an engineering and governance problem about whether enterprises can prove control over non-human actors operating at machine speed. The winners in this phase of AI adoption will not be those that deploy the most agents. They will be those that make autonomous action legible, bounded, and accountable enough to deserve production trust.