These aren’t exotic requirements. They’re the natural result of running software that makes decisions on its own. And they become significantly harder to retrofit once workloads are in production and teams have gotten used to operating without them.
Agents don’t just run code. They read tool descriptions, structured definitions of what each tool does, what inputs it accepts, and what it has access to, and then act based on those descriptions. That’s the mechanism. Which means the tool definition itself is an attack surface. A malicious or overly broad tool definition, sometimes called tool poisoning, can cause an agent to take actions that produce real damage, and the agent may have no way to detect that the instructions it’s following have been tampered with.
Now apply that as a provider question.
Worth taking slowly.
What Makes Agent Security Different from App Security
Current enterprise security guidance is consistent here: agents should use scoped, short-lived credentials together with proper secret management. Not shared static keys. The practical reasons are clear. A shared static key that gets exposed takes down everything using it. A scoped, short-lived credential that leaks is a much smaller problem, it expires, it can be revoked without touching other workloads, and its access was limited from the start.
So the provider question becomes whether the platform actually supports per-workload identity and real secret handling. Can credentials be generated at task start and invalidated at task end? Is there actual secret management infrastructure, or are teams expected to inject credentials via environment variables and figure the rest out themselves?
Most application security thinking is designed around bounded, predictable behavior. A web service handles requests and returns responses. Inputs, outputs, mostly static configurations to audit. Hard enough, but the surface area stays relatively stable.
This tends to be the area where the biggest gap exists between what providers describe in sales conversations and what teams discover when they actually need it.
And it’s the core challenge that modern AI security guidance is increasingly built around.
Execution Isolation
The decisions that determine whether these capabilities are even available are often made before the first line of agent code is written.
Runtime visibility into agent decisions is increasingly recognized as a distinct security requirement. Not just a monitoring dashboard. Not just latency metrics. An actual record of what the agent chose to do and in what sequence.
For DevOps teams evaluating providers, this is the first thing to nail down. Isolation isn’t optional once you’re running agents that execute code at runtime.
Agents authenticate to services. They consume resources that belong to real accounts. And in many deployments, they do this using credentials that were hardcoded, shared across multiple workloads, or rotated infrequently.
Teams asking these questions now, in procurement conversations before they’re locked into a platform, will have a much easier time when agent workloads scale and the pressure to audit, trace, and constrain them grows. Retrofitting isolation and observability into a production environment is significantly harder than choosing a provider that supports them from the start, and those architectural decisions become much harder to change once autonomous workflows are part of day-to-day operations.
Tool and Resource Access Control
Materially harder.
A developer building a careful, well-scoped agent on a platform that doesn’t support per-task isolation or scoped credential management is working against the grain of what good agent security actually requires. The framework matters at the infrastructure level, not just at the application level. That’s a provider-selection question before it becomes a development question.
The guiding principle is least privilege: access scoped as narrowly as possible to what the agent actually needs to complete its task. Not “everything this agent might conceivably need.” Exactly what this specific task requires, and nothing more. The gap between those two scopes is where a lot of agent security failures happen, an easy thing to get wrong in early deployments when teams are still figuring out what agents actually need, and the tendency is to grant broad access and tighten later.
AI agents run code, call tools, access filesystems, authenticate to external services, and make chains of decisions that nobody reviews in real time.
When your hosting or infrastructure provider runs agent workloads, does each task get its own isolated execution environment, or are workloads sharing a host? Worth asking explicitly, because the answer isn’t always obvious from marketing materials. “Containerized” doesn’t automatically mean “isolated per task.” There are configurations where containers share networks, volumes, or process namespaces in ways that undermine the whole point, and providers don’t tend to lead with that in their documentation.
To pull this together as a practical checklist for anyone evaluating where to run agent workloads:
Identity and Credential Management
When an AI agent is capable of running arbitrary code, as many development and automation agents are, the question of where that code runs matters enormously.
This one is less intuitive.
Give an agent a goal and a set of tools, and its behavior at runtime can branch in ways that were never explicitly written into the code. It might decide to query a database, spin up a subprocess, write to a filesystem, call an external API, and authenticate with a downstream service, all as part of completing one task. The question stops being “did this function behave correctly?” and becomes something harder: did this thing do what we actually wanted, using only what it was supposed to touch, in a way we can verify afterward?
That autonomy creates security exposures that traditional application security was never designed for.
A widely recommended architectural pattern is a disposable, isolated environment for each task: a sandboxed container, microVM, or similar workload boundary rather than a shared host where one compromised agent can affect everything else running alongside it. The logic is straightforward. If something goes wrong inside an isolated container, the blast radius is contained. The damage doesn’t spread to adjacent workloads, shared filesystems, or the infrastructure underneath.
Runtime Monitoring and Observability
Translated to provider evaluation: how granularly can you control what an agent-hosted workload can reach? Can you define per-tool permissions? Can you scope network access at the task level? Can you prevent an agent from touching resources it has no legitimate reason to access? Some platforms give you this kind of control. Many don’t, or bury it in configuration that most teams never look at.
AI agents that book meetings, query databases, and send summary emails without human review are already being deployed in production. This is not a future scenario. Teams are deploying this right now, and the security questions it raises are genuinely different from what any standard application checklist was built to handle — different in ways that don’t become obvious until something actually goes wrong, when the damage is already done and the logs don’t tell you nearly enough.
By Randy Ferguson
The latter is how a lot of small agent deployments get stood up quickly. It’s also how a lot of them create exposure they don’t fully understand until something goes wrong. Silent privilege escalation, where an agent’s effective access quietly grows beyond what was intended, is one of the specific patterns that proper credential scoping prevents. It doesn’t look dramatic. It doesn’t show up obviously in logs. It just means an agent has been operating with more access than it should have, for longer than anyone realized, and nobody noticed until it mattered.
General-purpose infrastructure monitoring wasn’t built with agent decision trails in mind, and that gap shows up at the worst possible time, after an incident, when you need to reconstruct what happened. Some providers are now adding this kind of agent-specific observability. Many haven’t yet. The practical question for any provider evaluation is: what does the observability layer actually give you for agent workloads specifically? Can you trace individual agent decisions across a multi-step workflow? Is there tooling to replay or audit a task sequence after the fact? Does the monitoring surface agent behavior specifically, or just generic resource consumption?
Because agents make dynamic, multi-step decisions at runtime, standard application logs often don’t tell you much. You can see that a function was called and returned a result. What you usually can’t see is why the agent called it, what it decided not to do, what tool descriptions it read before acting, or how it moved through each step, the full decision and action trail that separates agent behavior from an ordinary function call. Without that, post-incident analysis is basically guesswork. You can tell that something went wrong. Reconstructing how an agent reached a particular outcome is much harder when all you have are after-the-fact logs that weren’t designed to capture decision sequences.
Translating the Four Domains into Evaluation Questions
Agents break that assumption entirely.
- On execution isolation: Does the provider give each workload a fully isolated environment, or are tasks sharing host resources? What does “containerized” actually mean in their specific configuration?
- On tool and resource access control: How granularly can you scope what a workload can access? Can permissions be defined at the per-tool or per-task level, or only at the service level?
- On identity and credential management: Does the platform support scoped, short-lived credentials per workload? Is there actual secret management infrastructure, or do teams have to handle credentials themselves?
- On runtime monitoring: What does the observability layer look like for agent workloads specifically, not just general metrics, but decision and action trails across multi-step tasks?
Sometimes never.
Why This Matters for DevOps Teams Choosing Providers
There’s also a subtler point worth stating plainly. Least-privilege access isn’t only about stopping intentional attacks, it limits the blast radius of plain mistakes, too. An agent that can only reach what it needs to reach cannot accidentally delete, exfiltrate, or corrupt things outside its scope. That matters even when nobody is attacking anything.
When a team chooses which provider or platform to run on.
This one is about knowing what they actually did.
As enterprise adoption grows, security guidance has converged around four foundational domains: execution isolation, tool and resource access control, identity and credential management, and runtime monitoring. Different vendors and security organizations describe these controls in different ways. The underlying principles stay remarkably consistent. They also translate directly into provider evaluation questions for anyone picking a hosting or infrastructure platform to run AI agent workloads.
The three domains above are mostly about constraining what agents can do before and during execution.
