Guillaume Lebedel · · 7 min read 
Why AI agent pilots stall before production
Table of Contents
Most AI agent pilots stall because the systems they need to act on cannot grant scoped, identity-bound, logged write access. Deloitte’s Tech Trends 2026 reports 38% of organisations piloting agents and 11% running them in production. Google Cloud found 35% of senior IT leaders blame insufficient security for multi-system access.
Facts in this post were verified on 1 September 2026.
How many enterprises actually run AI agents in production?
Deloitte’s Tech Trends 2026 chapter on agentic AI strategy, drawing on its 2025 Emerging Technology Trends study, puts 30% of organisations exploring agentic options, 38% piloting, 14% ready to deploy, and 11% running agents in production.
The drop from 38% to 14% is not a drop in enthusiasm. An organisation piloting an agent has already paid for the model, the prompt work and the demo. The drop happens where someone has to approve the agent writing into a system the business runs on.
Which four capabilities do legacy enterprise systems lack for AI agents?
Deloitte names four: real-time execution capability, modern APIs, modular architectures, and secure identity management. Traditional enterprise software was designed for people clicking through screens and for nightly batch jobs, so it offers no way to give a single autonomous caller a narrow, attributable, revocable grant. Each line maps to something specific that breaks.
| Capability | What it means for an agent | What breaks without it |
|---|---|---|
| Real-time execution | The write commits now, not in tonight’s batch | The agent reports success and the record changes hours later, or not at all |
| Modern APIs | There is an endpoint to call instead of a CSV export on an SFTP drop | Integration work becomes file handling, and there is nothing to scope or log per call |
| Modular architecture | Access can be granted to one object or one action without granting the whole tenant | Approving one workflow means approving every field the credential can reach |
| Secure identity management | The call carries a principal that names the agent | The audit log names a shared service account, so no individual write is attributable |
Most pilots have real-time execution and modern APIs, and lack the other two. The demo calls a live endpoint in real time, then the security review asks who the agent authenticates as, and the answer is a service account six other jobs also use. Agent failures usually turn out to be permissions failures rather than reasoning failures, which is the same problem measured earlier.
Why does insufficient security for multi-system access block AI agent deployment?
Google Cloud surveyed more than 1,400 senior IT leaders for its 2026 State of AI infrastructure report. 35% named insufficient security for multi-system access as a primary reason agents are not deployed, and 79% put security, governance or MLOps at the top of their barriers to scaling inference.
Two surveys with different methods and different respondents name the same cause. In the same Google Cloud research, published 23 July 2026, 43% of IT leaders picked difficulty integrating with legacy APIs and data sources as their biggest agentic infrastructure gap, against 36% for a lack of high-throughput vector databases. That puts the integration layer above the parts of the stack getting most attention.
An agent that reasons well still needs a credentialed, scoped, logged way to write into systems like Workday, Salesforce or NetSuite, and most enterprises do not have one. So the pilot runs on read-only demo data, where none of those controls are needed, and the production version never clears review.
What changes when an AI agent gets its own identity instead of a service account?
With a shared service account, the audit log records one caller for every agent and job using that credential, so nobody can tell which agent wrote a record. With a per-agent identity, each call carries its own principal, its own scope, and its own log line, which is what a security reviewer can actually sign off on.
A reviewer will ask what happens if the agent misbehaves at 2am. With a shared credential the only response is to revoke it, which also stops the nightly payroll sync and two reporting jobs. With a per-agent identity you revoke that agent and nothing else changes.
This is the layer StackOne works on. An agent calls a single named action rather than a whole connector, the grant is scoped to that action for that agent, and every call is logged with the agent’s own principal on it. Across hundreds of connectors that means the answer to “which agent wrote this record” is a name rather than a shared credential. None of that makes the agent smarter, it makes the write reviewable, which is the step that blocks approval.
How do you tell whether an AI agent pilot will survive security review?
Score the pilot on the four capabilities before you score it on the model. The two that fail most often are modular architecture and secure identity management, because the grant is tenant-wide and the caller is a shared service account.
Five checks, in the order a reviewer will ask them:
- List the systems the agent writes to, one line each, and name the specific field it changes. A pilot that cannot produce this list in a minute has not been scoped.
- Name the principal on each write. If the answer is a service account shared with other jobs, the pilot fails this check however well the agent performs.
- Check the grant width. Ask whether revoking the agent’s access to one object would break anything else using that credential. If it would, the grant is tenant-wide.
- Pull one write out of the audit log and read it. If the line does not name the agent, the action and the field, it will not satisfy a reviewer, and adding logging after approval is a second project.
- Confirm the write is synchronous. If it queues into a nightly job, the agent cannot verify its own work, and neither can the person reviewing it.
A CIO or Head of IT can get all five checks answered in one meeting with the team that built the pilot. Four of the five checks are integration layer properties, not agent properties.
Protocol work is moving in the same direction without closing the gap on its own. The MCP 2026-07-28 specification improved transport and authentication without adding execution or approval controls, and multi-agent systems coordinate cleanly and then fail at the handoff into a system of record. A protocol can standardise how an agent asks, but whether the answer is a scoped, attributable, revocable grant is decided by the integration layer underneath it.
If you want the mechanics before you commit to an approach, see how per-action grants and audit logging are defined in the StackOne docs.