Cloud Security Alliance research commissioned by Token Security found that 82% of enterprises have AI agents running in their environments that nobody has catalogued, while 68% of the same organisations rated their visibility as strong.
Only 21% had a formal process for retiring an agent once its work was done, which leaves permissions and credentials attached to systems long after anyone remembers why.
Most published guidance on this responds with policy: govern your agents, scope their permissions, log their actions. The harder question sits underneath. A large share of those controls are only enforceable if you own the environment the agent executes in, and organisations discover which ones after the architecture is already fixed.
Our guide to AI agents for business covers the infrastructure layers an agent deployment needs. This post covers the security architecture: what changes when software acts on its own, where the tool layer has become a supply chain, and which controls depend on the deployment model rather than on policy.
What changes when an agent can act
Application security assumes a program does what it was built to do, and that the interesting question is who may invoke it. Agents break that assumption, because the sequence of actions is chosen at runtime by a model reading input nobody has vetted.
The Autonomous Action Runtime Management working group at the Cloud Security Alliance frames the difference in four parts. Agents act faster than any human review process can follow.
They usually run under static, high-privilege identities that bear no relationship to least privilege. Prompt injection means the reasoning layer cannot serve as a security boundary, since anything the agent reads can attempt to redirect it. And individual actions can each satisfy policy while their combination constitutes a breach.
That last point is the one that survives a permissions review unnoticed. An agent cleared to read customer records, and separately cleared to send email, has been granted data exfiltration without anyone approving data exfiltration. Neither permission looks wrong on its own, which is precisely why a permissions model that evaluates grants individually will pass it.
The practical consequence is that guardrails written into prompts cannot be the primary control. A system prompt is an instruction to a model that is simultaneously reading documents, tool outputs and web content, any of which can carry an injection attempt.
The tool layer is now a supply chain
The Model Context Protocol has become the common interface between agents and external systems, and our pillar covers its role in integration. Less discussed is what it does to the trust boundary.
A systematisation of MCP security research makes the structural problem clear: unlike REST or gRPC, which keep transport, authentication and execution separate, MCP merges reasoning and control flow inside a shared semantic context. Context, metadata and executable instructions travel together, frequently without strong isolation between them.
This produces attack classes that have no equivalent in conventional API integration:
- Tool description injection – Tool descriptions flow into the model’s context, so a description can carry instructions to the agent. A tool that claims to fetch weather data can append an instruction to post environment variables to an external endpoint, with no user input involved at any point.
- Tool poisoning and shadowing – MCP has no built-in way to cryptographically verify a tool’s origin. Names, descriptions and claimed providers can be spoofed, so a malicious server can present a convincing duplicate of a tool your team already trusts.
- Confused deputy – An MCP server frequently holds broader permissions than the user on whose behalf it acts. An agent persuaded to make the request becomes the route to those elevated privileges.
- Post-deployment mutation – A server that behaved correctly during evaluation can change what it does afterwards, and nothing in the protocol requires it to announce that.
The mitigations are infrastructure decisions rather than model decisions. Running MCP servers inside your own perimeter rather than calling third-party endpoints removes most of the supply chain.
Allow-listing which servers an agent may reach, and pinning versions rather than resolving them at runtime, closes the rest.
Identity, and the traceability gap
A CSA survey of 285 IT and security professionals commissioned by Strata Identity found that only 18% of security leaders were highly confident their existing IAM could manage agent identities, and only 28% could trace agent actions back to a human sponsor across all their environments.
That second figure carries the most weight. An agent running on a shared service account or an engineer’s credentials inherits everything that identity can reach, and every log entry it writes reads as that person. When something goes wrong there is no accountability chain to follow, and no answer for an auditor.
Ownership tends to be fragmented too, split in the same survey across security functions at 39%, IT at 32% and AI functions at 13%.
The fix is that each agent holds its own identity with short-lived credentials rather than static keys, scoped to the task it exists to perform, tied to a named human sponsor, and given a retirement path defined before it goes live.
The controls that depend on owning the runtime
Everything above is achievable in principle on any infrastructure. In practice, five controls behave very differently depending on where the agent runs.
Egress control: An agent that browses the web or calls external APIs has an outbound path, and default container networking permits it. An outbound allow-list enforced at the cluster network layer turns exfiltration from a single action into a blocked one. This is enforceable where you control network policy and largely unavailable where you do not.
Where inference happens: If the reasoning model sits behind a third-party API, every prompt and every tool-call payload leaves your perimeter, including whatever the agent read from internal systems before composing the call. Self-hosted or dedicated inference keeps that traffic inside. For biometric, clinical or financial data this is frequently the control that decides the deployment model outright.
Code execution isolation: Agents that write and run code need an execution sandbox with no credential access, an ephemeral filesystem and no route to production networks. That is a container or virtual machine boundary, provisioned and enforced at the infrastructure layer.
Log custody: Reconstructing an execution chain for an auditor two years later depends on the trace still existing and not having been altered. Logs held in a vendor platform are subject to that vendor’s retention terms. Logs written to storage you control, with write-once semantics, are evidence.
Tenancy: Shared inference endpoints and shared storage mean your prompts, your tool outputs and any fine-tuned weights sit alongside somebody else’s. Dedicated or logically isolated environments enforce that separation at the network, storage, compute and identity layers rather than trusting a software boundary above them.
What to ask an infrastructure provider
The gap between a policy document and an enforced control is usually visible from a handful of questions:
- Can we define outbound network policy per workload, and who can change it?
- Does inference run on dedicated capacity, or on a shared endpoint alongside other tenants?
- Where are prompt and tool-call payloads processed, and are they retained anywhere?
- Do we hold the execution logs, in storage we control, with immutability guarantees?
- How is isolation enforced between tenants at the network and storage layers?
- What is the process for provisioning a sandboxed execution environment with no credential access?
Any provider serious about agent workloads will have direct answers. Vague ones are informative in their own right.
Where this leaves the deployment decision
Public cloud services are quick to start with and appropriate for plenty of agent work. An internal assistant with narrow data access rarely justifies more. The questions get harder as an agent moves toward customer records, payment systems or regulated data, because at that point the controls that matter are the ones sitting below the application.
Neurotechnology Cloud’s AI cloud and managed GPU services provide dedicated or logically isolated environments built for that requirement, with tenant separation enforced across network, storage and compute, and a dedicated AI engineer handling the infrastructure work.
For teams evaluating what their agent workloads actually need, we design and operate the environments these systems run on, from cluster and network policy through to the inference capacity underneath. NVIDIA’s OpenShell runtime is one worked example of the isolation pattern, which we cover in our piece on NemoClaw.
