Securing agents in the most dangerous period of digital evolution

Traditional software only does what it was written to do. An agent decides what to do next based on content it just read — a ticket, an email, a web page, a document — and then acts through tools with real permissions. That is a genuinely new class of exposure, and it is why the period we are in is more dangerous than either the cloud or mobile transitions: the attack surface is the input, and the input is language.

The failure modes that matter

Prompt injection is first and has no complete fix. Any content the agent reads can contain instructions, and models cannot reliably tell data from directives. A support ticket, a résumé, a supplier PDF, a web page it was asked to summarise — each is a possible instruction channel. Treat every input as untrusted and design so that a successful injection cannot do much.

Tool abuse is the consequence. The damage is not what the agent says, it is what it is allowed to call. An agent with broad write access and a search tool is one crafted document away from exfiltrating data or changing records, entirely within its granted permissions.

Excessive agency is the quiet one. Most agents are given more access than their task needs because scoping permissions properly is tedious. Then the blast radius of any single failure is the union of everything the agent can reach.

Identity and attribution come next. If the agent runs as a shared service account, your logs cannot answer who authorised an action, which breaks both incident response and any audit that matters commercially.

Memory and context poisoning is the slow burn. An agent that persists what it learns can be taught something false once and repeat it for months. Anything written to long-term memory needs the same scrutiny as an action.

Supply chain is the last: tools, connectors, and MCP-style servers the agent trusts. A compromised or over-permissive connector inherits the agent's reach, and it will not appear in any of your application code review.

Controls that hold up

Least privilege per tool, not per agent. Each tool gets the narrowest scope that lets it work, and read paths stay separate from write paths so a compromised summary step cannot reach a write step.

Human approval on anything irreversible. Money, outbound messages, deletions, and permission changes stay gated until accuracy is proven, and stay gated permanently where the failure cost is high. This is a design decision, not a maturity stage you grow out of.

A distinct machine identity per agent, with actions attributed to both the agent and the person or system on whose behalf it acted. Without that, incident response is guesswork.

Output validation before action. Structured, schema-checked outputs and allowlisted targets mean a manipulated model cannot produce a valid destructive call. Validate at the tool boundary, not in the prompt.

Adversarial testing before launch, repeated on every change: injection attempts in every input channel, tool-abuse attempts, and confidentiality probes. Then a regression suite over real historical cases, because a prompt change is a security change.

Limits and alerting as containment. Rate limits, per-task cost ceilings, and anomaly alerts turn a runaway or hijacked agent from an incident into a paged warning. Cost controls are a security control, not just a finance one.

Why this decides whether agents stay deployed

The pattern we see is not agents being switched off after a breach. It is agents being switched off after one visible wrong action, because trust in the team was never underwritten by evidence. Approval gates, evaluations, and audit trails are what let an agent survive its first mistake — which it will make.

Almost every serious weakness we find traces back to prototype assumptions reaching production: shared credentials, unscoped tools, no evaluation, no ceilings. That path is described in the limits of agents built only from vibe-code tools, and it is the same reason staged rollout matters when you migrate an existing system.

Where to start

Inventory what your agents can currently do, not what they were built to do. List every tool, its scope, and whether an irreversible action can be taken without a human. Most teams find at least one path they did not intend to grant.

We do that review as part of hardening on the AI agents services page. If you have an agent already running, bring it to a scoping call or start there — reviewing a live agent is faster and more useful than reviewing a plan.