For two years, AI agents mostly talked. Now they act.

The shift from read-only assistants to agents with write access is the most important change in enterprise AI this year, and it broke an assumption underneath most security models: that anything taking an action inside your systems is either a person or a program doing exactly what it was told.

An agent is neither. It decides what to do next, and the decision changes with the input.

What changed in 2026

Two developments are worth knowing about, because together they explain why this became urgent now.

Agents got standard ways to reach your systems. The Agentic AI Foundation now counts more than 250 members, including AWS, Anthropic, Google, Microsoft, Cloudflare, Bloomberg and Block, consolidating agent protocols like MCP and A2A into a single governed stack.

That standardisation is genuinely good news. It reduces integration friction and lets you build multi-vendor agent architectures instead of locking into one provider. It also means connecting an agent to a live system is now easy enough that people do it without a review.

The platform vendors started warning about it. In late August 2026, Google Cloud published guidance tied to its State of AI Infrastructure report framing agent security as a gating issue for scaling autonomous workflows — recommending platform-level governance, task-level provenance, and human-in-the-loop checkpoints rather than bolting agents onto existing access and logging systems.

When infrastructure vendors publish "here is how not to hurt yourself" guidance, it is usually because enough customers already have.

Why normal security controls do not fit

Your existing model has two categories: users, who authenticate and get permissions, and services, which have fixed credentials and do one predictable thing.

Agents fit neither.

The permission problem

A service account has one job, so you scope its permissions once. An agent's next action depends on what it just read. So teams give it broad permissions to cover every case it might encounter — which means it holds far more access than any single task requires, permanently.

The fix is short-lived, task-scoped permissions rather than a standing role. That is more work than issuing an API key, which is why most setups have not done it.

The audit problem

When something goes wrong, you need to know what happened. A traditional log says which account did what. An agent log often says a request came in and an action went out, with the reasoning in between invisible.

This is what task-level provenance means: recording not just the action but the chain that led to it — what the agent read, which tool it called, what it decided. Without it, an incident investigation has no middle.

The trust-boundary problem

This is the one that surprises people. An agent that reads external content — emails, web pages, uploaded documents, a customer support ticket — is reading text that someone else wrote. If that text contains instructions and the agent has tools, the content becomes an attack surface.

The lesson from adversarial testing work in this space is worth stating plainly: treat any tool-using agent as a potential insider threat, and test it against hostile inputs rather than only against benchmarks. Benchmark evaluations measure whether an agent is capable. They do not measure whether it can be manipulated.

Five controls worth putting in place

None of these require a platform migration. They are ordered by how much protection they buy per hour of work.

1. Human approval on irreversible actions

The highest-value control and the simplest. Sending money, deleting records, emailing customers, granting access — these stop for a person.

Full autonomy demos well and is the wrong default in production. Decide deliberately which actions are reversible and let the agent act freely on those. Everything else waits.

2. Scope permissions per task, not per agent

Instead of one agent identity with everything it might ever need, issue narrow, short-lived credentials for the specific task at hand. This limits how much damage a manipulated or malfunctioning agent can do in a single run.

3. Log the reasoning chain, not just the outcome

Record what the agent read, which tools it called, in what order, and what it produced. You will need this the first time something goes wrong, and you cannot reconstruct it after the fact.

4. Treat external content as untrusted input

Any content the agent did not generate and you did not write is potentially hostile. Separate instructions from data in how you construct prompts, and test what happens when a document contains something that looks like a command.

5. Set escalation points

Define in advance what makes an agent stop and ask rather than proceed. An agent that hits an unexpected state and improvises is a worse outcome than one that pauses.

Six questions for your own setup

1. Which of your agents can write to a system of record, and who approved that? 2. If an agent did something wrong last Tuesday, could you reconstruct why? 3. What permissions does each agent hold, and does it need all of them for every task? 4. Which agents read content written by people outside your company? 5. What happens when an agent encounters a situation it was not designed for? 6. Who in your organisation owns agent security? If the answer is nobody, that is the finding. Any question you cannot answer cleanly is a gap, not a technicality.

What this means practically

The controls above are not exotic. They are the ordinary discipline of running software that can affect real things, applied to a category of software that got deployed unusually fast because it was easy to deploy.

The uncomfortable part is that agents were mostly rolled out by teams solving a business problem, not by security teams. Ownership of the layer underneath is frequently unassigned — which is the same structural gap that leaves most companies' agents disconnected from each other. Nobody owns the space between.

If you are commissioning agent work, the practical version is to ask your vendor the six questions above. The answers tell you whether you are buying a system or a demo — the same test we described in what a custom AI agent actually costs.

This is also why our own builds default to human approval on anything that leaves the company, and why we treat the evaluator layer as part of the system rather than an optional extra.

To review your current setup, describe it to ZAC Consultant — it will map which agents hold what access and where the approval points should sit. For a costed picture of adding the missing layers, ZAC Estimator gives a range in about two minutes.

More on how we build: AI automation, custom software, and systems we have shipped.