Four questions to ask before you let an AI agent loose

Anthropic’s Deputy CISO, Jason Clinton, has published a short piece that every leader weighing up AI agents should read. It is called Zero risk isn’t the job, and the argument is refreshingly practical. The point of security in the age of AI agents is not to eliminate risk. It is to make that risk visible and bounded, so the business can decide what it is willing to accept and then get on with it.

That framing lands here in Australia, where boards are already asking whether AI use is governed at all, and where staff are quietly connecting agents to email, files and line-of-business systems without telling anyone. Say no, and the activity moves into the shadows where you have no visibility and no off switch. Say yes without controls, and the first serious incident sets the whole program back. The workable path is governance that keeps pace with the tools.

Four questions to ask about any agent

Clinton’s team runs every proposed agent through four questions before it goes anywhere. They are worth borrowing:

1. What untrusted content does it read? Anything an attacker could write or alter, such as inbound email, the open web or a third-party document. If the honest answer is nothing, the agent-specific risk is low and you can move quickly.
2. What actions can it take, and on whose behalf? Read-only is a different animal to read and write. Every action runs under some identity, and you need to know whose.
3. What is the blast radius if it goes wrong? One file or the whole organisation? A minor annoyance or a genuine incident?
4. What can you actually see? Can you tell an agent’s actions apart from a person’s, and does that activity reach the tools where you already investigate?

The rule that follows is what Clinton calls least agency: grant the narrowest capability that still completes the task, switch it on for a small group, watch what happens, then widen access. It is the principle of least privilege, pointed at a new kind of user.

A misaligned agent looks a lot like an insider

One line stands out. An agent that drifts away from your intent is hard to tell apart from an insider attack. Clinton cites research from the Ponemon Institute showing that organisations still take an average of 67 days to contain an insider incident, even after years of investment in the problem. At the speed an agent works, days are far too slow. That is why the controls, and the monitoring behind them, have to be in place before you switch anything on, not bolted on after something goes wrong.

The controls that keep an agent bounded

The guide lists the controls that make an agent safe to run, and in ISO terms none of them are new. They are the access, logging, supplier and change disciplines you already know, applied to software that acts on its own:

• Identity issued and revoked through the same system you use for staff, so access can be pulled the moment it needs to be.
• Allowlists that decide which systems an agent can reach, and which specific actions it can take. If the risk that keeps you up at night is a deleted production database, remove the delete action from the agent’s world entirely.
• Sandboxed execution, so the agent never holds a credential worth stealing.
• Egress allowlisting, described as the single strongest defence against prompt injection. If a compromised agent has nowhere to send data, the attacker gets nothing out.
• Telemetry streamed to the same place you already investigate, so an agent’s actions sit next to everyone else’s.
• A single off switch that disables every agent at once, with the option to go narrower before you go to zero.

If you hold ISO 27001, that list will read like your Annex A controls: access control, logging and monitoring, supplier management and change control. The technology is new. The disciplines are not.

The bit that matters for ISO-certified teams

Clinton is clear that deliberately accepting risk is a human act, carried out by people with the authority to accept it. For that to mean anything, the output of all this assessment has to land somewhere. His point: if you run ISO 42001, or something like it, with a live risk register and an executive risk council behind it, re-scored risks reach the people who can accept them and flagged vendor terms reach the people who negotiate them. And if you already hold ISO 27001, he notes that adding ISO 42001 is usually an incremental step with your existing auditor.

We have written separately on how ISO 42001 and ISO 27001 fit together and where each one sits when you are securing personal information, so we will not repeat that here. The short version for this article is simple. The four questions and the controls above are not a new tool to buy. They are a management system doing its job. If the answers to Clinton’s four questions have nowhere to go in your business, that is the gap a certified system closes.

Availability belongs in the same assessment. An agent can be well governed and still leave a process exposed if its provider or model is unavailable. Our guide to AI business continuity and provider concentration explains how to map fallbacks and manual operating methods before every agent “calls in sick” at once.

Three things worth doing this quarter

1. Take the agent your team is pushing hardest for and run it through the four questions. The goal is not a yes or no, it is to find the conditions under which you would say yes.
2. Ask your identity provider, your logging tool and any AI vendor to show you the controls above working in your own environment, not on a slide.
3. Write down what counts as untrusted content in your business. Every future agent decision gets easier once that line exists.

Deploying an agent is only the first half. Six months later the question is whether anyone is still reviewing what it can reach, and most access reviews only list people. We have written that up separately, with a free checklist: access reviews that count AI agents, not just people.

And when the agent is pointed at you

Update, 17 August 2026. The Australian Signals Directorate has since taken this question and turned it around. On 11 August 2026 the ASD published a news item, When AI agents take unexpected actions, prompted by an incident ABC News reported on 10 August. An AI assistant made unapproved modifications in an Australian gym booking system, reserving classes beyond the permitted timeframe and removing another customer from a waiting list. The user got what they asked for. The agent achieved it in a way the user never approved and could not reverse.

Most of the coverage picked up the half of ASD’s advice aimed at people using agents: keep them on low risk, non-sensitive tasks, avoid granting broad access or decision-making authority, and maintain a human in the loop to review, approve and monitor what the agent does. The sentence worth your attention is the one aimed at the other end of the transaction. “Organisations providing online services should consider that AI agents might identify and exploit vulnerabilities at speed and scale.” You are the online service. Your customers are now sending agents at it, and three things follow that are easy to miss.

• Your controls assume a human at a keyboard. Booking windows, rate limits, waitlist logic and terms of use were all designed against human patience, not against something that retries relentlessly and reads your business rules as an optimisation problem. That is an application security requirements question, and on most systems nobody has re-asked it since the thing was built.
• It is not an attack, which is exactly why nothing will detect it. No malicious actor, no anomalous credential, nothing exfiltrated. A legitimate customer got what they asked for and another customer was quietly harmed. Nothing in a normal monitoring stack fires. What finds it is vulnerability management plus a clause 9.2 internal audit that samples your business rules against what the system will actually permit.
• Irreversibility is the design defect, not the agent. The agent could not undo the waitlist removal, which means the service offered a destructive action with no confirmation step and no reversal path. That belongs in your secure development lifecycle, not in an incident report.

If you are deploying agents as well as receiving them, the two halves meet neatly. ISO 42001’s human oversight and impact assessment requirements are the mirror image of ASD’s human-in-the-loop advice, seen from the other end of the same transaction, and ISO 27001’s secure development and vulnerability management controls are where the receiver-side work actually gets done. The same question, asked from both directions.

Where Streamline fits

If you are being asked to govern AI and you are not confident the answers would land anywhere, that gap is exactly what ISO 27001 and ISO 42001 are built to close. Streamline helps Australian organisations design and certify both, often at the same time, so AI adoption comes with a risk register, a named owner and an audit trail behind it. If that is where you are headed, take a look at how we approach ISO 42001 AI management and ISO 27001 information security, or get in touch for a plain conversation about where to start.