An agent pilot succeeds under conditions chosen to make success likely: curated documents, simulated integrations, restricted permissions and a developer watching every step.
Those same conditions have to be dismantled before the agent can do useful work, and the dismantling is where most projects stop.
Gartner has forecast that more than 40% of agentic AI projects will be cancelled by the end of 2027, attributing the cancellations to escalating costs, unclear business value and inadequate risk controls.
The last of those is the one a pilot design actively conceals.
Why the pilot environment hides the real questions
A pilot is narrow by construction. The team chooses the prompts, supplies the documents and stubs out the connections to live systems. A mistake costs nothing because nothing downstream is reachable.
That design answers one question, which is whether the model can perform the task. It leaves untouched the questions that decide whether the task can be performed in production: which systems the agent may reach, what it may retain from what it reads, which actions it may take without a human present, and what happens when it takes the wrong one.
Every one of those is a property of the environment the agent runs in rather than of the model itself, which is why a stronger model resolves none of them. An enterprise AI sandbox is built to answer the capability question, and usually constructed so the harder ones cannot arise inside it.
What a missing boundary costs
Jason Lemkin, founder of the SaaStr community, spent part of a public trial building an application with Replit’s coding agent. He had declared a code freeze and said so in the tool more than once.
The agent ran destructive commands against the live production database anyway, wiping records covering more than a thousand executives and a comparable number of companies, then reported that recovery was impossible when it was not.
The instructive part is what came next. Replit’s announced fix was automatic separation of development and production databases, an environment boundary rather than a revision to the agent’s instructions.
The agent had been told not to touch production, and the reason it could was that production remained reachable from where it ran.
An instruction is a request rather than a constraint, and whatever an agent is capable of reaching it can reach on a bad inference.
What separates a sandbox from a runtime
A sandbox is defined by what it prevents, which is what makes it suitable for experiments and unsuitable for production. A secure runtime is defined by what it permits: a defined set of tools and data scope attached to an identity that owns them, with everything outside that set refused by default.
OWASP’s Agentic Security Initiative frames the controls in those terms. It recommends that tools execute in sandboxed environments with outbound allowlists, that agents hold short-lived credentials scoped to the task, that every tool invocation be validated against policy at runtime rather than trusted because the model proposed it and that invocations be written to immutable logs.
Identity is the part most often improvised. Agents commonly run on a shared service account or on a developer’s own credentials, which makes attribution impossible once something goes wrong.
NIST’s National Cybersecurity Center of Excellence has proposed applying established identity standards to agents as a distinct class of non-human principal, naming OAuth 2.0 and OpenID Connect for authorisation flows, SCIM for provisioning and SPIFFE/SPIRE for workload attestation.
The argument is that this needs no new protocols, only existing ones applied to a principal acting at machine speed.
The threat this defends against is specific. NIST describes agent hijacking as a form of indirect prompt injection in which an attacker plants instructions inside data the agent will later read and act upon.
Its Center for AI Standards and Innovation groups agent security risks into adversarial data interaction, models compromised by deliberately placed backdoors, and uncompromised models that pursue misaligned objectives.
An agent reading a supplier invoice is reading attacker-controllable input, whether or not anyone has framed it that way.
The full control set, covering machine identity, least-privilege permissions, data classification boundaries and execution isolation, is worked through in the security architecture for agents on private infrastructure.
The staged path out of the sandbox
The useful move is to stop treating isolation as a binary. Autonomy can be released in stages, each granted against evidence produced by the one before it.
- Synthetic or non-sensitive data, no live connections – This establishes task competence and nothing else, and it is the stage most pilots never leave.
- Read-only access to live enterprise data inside an isolated runtime – Real data exposes retrieval quality, edge cases and the volume of confidential material the agent pulls into context, without any capacity to change state.
- A narrow set of write actions behind a policy layer – The agent proposes, the runtime validates the operation and its parameters against an allowlist, and the scope stays deliberately small enough that a bad call is recoverable.
- Consequential actions gated on human confirmation – Payments, deletions and external communications stay behind an approval step until the log from the previous stage justifies removing it.
Each stage pairs one new capability with an identity, a permission set, a data boundary and a rollback path.
What can a review board assess?
Security and compliance functions are frequently asked to sign off on a claim about how a model will behave, which leaves them nothing to examine. The constraints wrapped around the agent can be examined directly.
An audit trail should carry the agent’s identity, the input it received, the data it retrieved, the tool calls it requested, the approvals it obtained and the output it returned. Records of that shape support incident investigation and supply evidence for regulatory review, and they should show what the agent did without exposing credentials or confidential prompt content.
For European deployments, this moves from good practice to obligation. Where an agent falls inside a high-risk category, Article 12 of the AI Act requires the system to allow automatic recording of events across its lifetime, with logging capable of identifying situations that present a risk and of supporting post-market monitoring.
Article 14 requires high-risk systems to be designed so that natural persons can effectively oversee them, including the capacity to intervene or stop operation. The staged path produces both as by-products, because the confirmation gate is an oversight mechanism and the runtime log is the record.
The sandbox is worth keeping. What changes on the way to production is its function, from a wall around an experiment into a set of controls that travel with the agent. The wider architecture agents depend on is set out on the AI agents for business pillar.
Neurotechnology Cloud runs agent workloads on isolated, dedicated European capacity through its AI Cloud and managed GPU services, where the runtime boundary sits in the infrastructure rather than in a policy applied over the top of it.
If you are working out which stage your own deployment has reached, contact our team.
