AI agents don’t need new security rules – they need the old ones, applied

A week of October 2026 reading on agentic AI security, and what I make of it.

Over the last few days I read five pieces on securing AI agents – a vendor survey, an email security company’s report, a finance trade site, an AWS executive’s opinion piece and a sponsored article on Dark Reading. They come from very different places, but they keep landing on the same few points.

What struck me is that none of those points are new. They’re the security basics we’ve known for years, being rediscovered for a new kind of user. Here is how I see it.

1. Nobody has a full inventory

This is the clearest point, and it’s the same as CIS Control 2. Most companies don’t know precisely what standard software they have installed – never mind AI. You can’t govern what you can’t see and don’t know about!

An agent can be created in minutes, often by someone who isn’t in IT, and nobody thinks to tell security. That’s shadow IT again, but this version can read your mail and call your APIs.

What I’d do: one list. Every agent, connector and MCP server, who introduced it, and what it can reach. A spreadsheet is fine to begin with. It just has to exist.

2. Agents have far too much access

Least privilege is one of the oldest ideas in security, and it’s the first thing to go when something is new and exciting. An agent gets the permissions of whoever set it up, because that’s the easy option, not because the job needs it.

I’d treat every agent like a contractor on day one. Give it one task, one set of credentials, read-only unless it truly must write, and nothing it doesn’t need. If an email agent needs fifty tools attached to do its job, the job is badly defined.

3. Treat everything an agent reads as untrusted

For me this is the most important new problem, and the one that is genuinely different from what we had before. A person knows an email is just an email. An agent might read it as an instruction.

That makes an inbox, a web page or an external tool connection a way in. It’s injection, in a new form, and we’ve been dealing with injection for twenty-five years. The same lesson applies: don’t mix data and commands, and don’t trust input because it arrived somewhere “inside”.

I like the idea that AI agents present outwardly as adults, but are actually people-pleasing children who have a need to get the job done. Maybe if someone else gives them their favourite sweets, they might do something you didn’t expect!

So vet any outside tool or MCP server before you connect it, the same way you’d vet a supplier.

4. The check has to sit outside the model

It’s tempting to rely on the model’s built-in guardrails. I wouldn’t. Guardrails can be weakened, worked around or just fail, and a model can behave differently after its next update, while the approval you gave it last year stays on file.

So I’d separate thinking from authority. The model can recommend. Something else – a permission, a rule, a person – decides whether it happens. For anything that matters (payments, deletions, changes to production) a human approves, and for money the approval names the exact recipient and amount, not a blanket “yes”.

It also means re-approving. Pin the version, and review before you accept the next one.

5. Small things chain together

Severity scores rate each issue alone. Attackers don’t. A harmless permission here, a stored credential there and a message the agent can send – none of it alarming, all of it together a way out with your data.

A list of “low” findings isn’t a low risk. What matters is what an agent can reach in combination. This is why checking components one at a time, which is how most governance works, isn’t enough.

6. Log it, and be able to stop it

Two ordinary controls that matter more with agents, because they act faster than a person would notice:

• Logs the agent can’t edit. If it can alter its own record, the record is worth nothing. Review them, because a log nobody reads is just storage.
• A tested off switch. If you’ve never tried revoking an agent’s access, you don’t know that you can. Try it before you need it.

7. Who is actually responsible?

The question that always keeps coming back is ownership. Is the agent an IT tool, a department asset, a “data processor”? If the people who understand the risk aren’t in the decision, the access gets granted first and questioned later.

I’d put Information Security in the approval path, and name an owner for every agent. If nobody owns it, it shouldn’t be running.

A word on the numbers

Be careful when you see headline statistics. Most come from people selling something. That doesn’t make the findings wrong, but each one is only defined in a limited context. That’s why most figures never align.

So I’d keep the pattern and ignore the percentages. Understand each risk in your own domain and assess this accordingly!

The takeaway

Know what you’ve deployed. Limit what it can touch. Don’t trust what it reads. Keep the final check outside the model. Be able to stop it.

None of this is new. It’s inventory, least privilege, input validation, logging and incident response, applied to a user that works at machine speed and doesn’t ask permission. The organisations that have done the basics well will find this much easier, and the ones that haven’t will find AI just makes the gaps bigger.

Agentic AI may well become your greatest Insider Risk – and unlike most insiders, you invited it in knowingly. Consider that when talking to the C-Suite.