AI agents are now a security surface, not just a tool

A chatbot that answers questions has a narrow blast radius if something goes wrong — worst case, it says something embarrassing. An agent that can read files, call internal APIs, write to a database, or execute code has a fundamentally different risk profile, because the failure mode isn’t "wrong answer," it’s "wrong action taken." A meaningful share of projected enterprise security incidents involving AI are expected to come from misuse of agents specifically — not from the underlying model being "hacked" in some exotic way, but from agents being given more authority than the security model around them was designed to handle.

Before deploying any agent with write access to a real system, the first design question should be: if this agent does something completely wrong — not malicious, just wrong, the way any software occasionally is — what’s the worst case? If the honest answer is "it could delete production data" or "it could send money to the wrong place," that’s a signal the agent needs a narrower scope, a human approval step, or both, regardless of how good the model’s track record has been in testing.

Sandboxing is the primary technical control here, and it’s worth treating as non-negotiable infrastructure rather than a nice-to-have. An agent’s execution environment should have the minimum access it needs for its specific task — not the same credentials a human engineer would have, not broad database access "in case it needs it later." Scope creep in agent permissions is exactly how a narrow, useful automation becomes a serious incident waiting to happen.

If an agent reads content from an external source — a webpage, an email, a document a user uploaded — that content can contain instructions designed to manipulate the agent’s behavior. This isn’t a hypothetical edge case; it’s a documented and increasingly common attack pattern. Any agent that ingests untrusted external content as part of its workflow needs that content treated as adversarial input by default, with the agent’s tool access scoped tightly enough that even a successfully manipulated agent can’t do much damage.

The practical mitigation is the same principle as the blast radius question: separate the agent’s ability to read untrusted content from its ability to take consequential action, and put a verification step between the two wherever the action is hard to reverse.

Every agent gets scoped credentials specific to its task, not inherited broad access. Every action with real-world consequence — financial, destructive, or externally visible — gets a logged audit trail at minimum, and a human approval gate for the first weeks of production regardless of how confident the testing made us. And every agent’s permissions get reviewed on the same cadence as a human employee’s access — not granted once and forgotten.

None of this is exotic security practice. It’s the same least-privilege thinking that’s applied to human access for decades, applied consistently to a new category of system that can act, not just respond. The teams getting burned by agent security incidents aren’t facing some novel unsolvable threat — they skipped the basics because the system felt more like a chatbot than infrastructure.

Regulatory movement on this is real but uneven — some jurisdictions and industries have specific frameworks emerging for agentic systems, particularly in healthcare and financial services where the stakes of an autonomous action going wrong are highest. Most general-purpose compliance frameworks, though, were written with traditional software in mind and don’t cleanly address a system that makes its own decisions about what action to take next.

Our practical approach in the meantime: apply the strictest applicable framework even where the letter of the regulation doesn’t explicitly mention agentic systems yet. If your industry has data handling, audit trail, or access control requirements for traditional software, treat an agent touching that same data as bound by the same requirements — don’t wait for a regulator to write an agent-specific rule to start applying the spirit of the existing one. Auditors and regulators are increasingly asking pointed questions about AI system governance even where the formal rule hasn’t caught up, and being able to show deliberate governance beats being able to point at a technical loophole.

This is also where internal threats deserve more attention than they typically get in agent security conversations, which tend to focus heavily on external attackers. An employee with legitimate access who misuses an agent’s capabilities — intentionally or through carelessness — is a meaningful share of realistic incident scenarios, and the same scoped-access, audit-logged approach that limits external attack blast radius limits this risk too.

Treat every agent with write access the way you’d treat a new employee on day one: minimum necessary access, logged actions, and trust that builds gradually rather than gets assumed up front. The agents causing real damage in the wild aren’t exploiting some sophisticated novel vulnerability — they’re being given more authority than basic security hygiene would ever grant a human in the same role.