AI agents no longer just write text. They read logs, change configurations, deploy software and talk to other agents. This raises a question in IT operations that used to be reserved for people: who may do what, and who allowed it?
The answer “we trust the agent” does not hold. Not because agents are fundamentally unreliable, but because trust draws no boundary. A different yardstick is more robust: the reach of an action – what it touches in the worst case and whether it can be undone.
Why the topic is pressing right now
Two publications from the past two weeks show that agents have arrived in operational reality – on both sides.
On 10 September 2026, Anthropic published its report “Detecting and countering misuse of AI: September 2026”. It describes cases the company disrupted between December 2025 and August 2026. One statement in it deserves attention beyond the threat intelligence scene: for investigators, sophistication is no longer a reliable indicator of who is behind an operation – in the report’s words, “sophistication has stopped being a reliable signal”. According to the report, every layer of offensive operations has been uplifted by AI, from reconnaissance through tool development to exploitation. According to the report, the majority of the operations described were enabled by AI, through direct execution or orchestration; multi-agent systems were used for reconnaissance, exploitation and data exfiltration, while humans set the targets. An operating model for autonomous attacks that Anthropic had documented in November 2025 in a suspected state-sponsored campaign has, according to the report, since spread across all the actor groups examined.
For defenders, the report contains a sober recommendation: take AI keys and agent integrations as seriously as production credentials – because attackers do too. The report also counts what customers build around AI, such as sandboxes, proxies and resellers, as attack surface. The consequence for your own operations: an agent with write permissions is an account with write permissions, and its credentials are a worthwhile target.
On the defender side, HashiCorp released Vault 2.1.0 on 1 September 2026. The release notes name “Agentic IAM” as a licence component and a new interface for the Agent Registry (“Agentic Security” section) in the Enterprise edition, where operators can view and manage registered AI agents with their identities, policies and operational status. The release notes also mention ceiling policies for the Agent Registry, in which explicit “deny” rules are now permitted as well. That is a sign that agent identities are becoming a product category of their own.
Taken together, both suggest treating agents like privileged accounts. The following five principles are meant as recommendations for organisations that use agents in operations or are planning to.
1. Classify actions by reach, not by feel
Not every action needs the same approval. One possible classification has three classes:
- Measuring is free. Reading, checking, reporting, asking questions – anything that changes nothing an agent may do without asking. Making measurement harder brings no security.
- Writing needs an agreed plan. A change within one’s own area of responsibility is allowed if a plan has been agreed beforehand that names two things: a rollback path that already exists at that point – not one the plan promises to create – and the specific value that will be checked afterwards, likewise fixed in advance. Within such a plan, the agent may act without asking again for every step. That is the point of the plan: agreed once, not renegotiated at every step.
- Anything with organisation-wide effect needs the human every time. Identities and accounts, DNS, certificates at the network edge, the configuration of privileged access: here the effect reaches beyond one’s own area, and here the responsible person decides case by case.
What matters is to define the third class narrowly and concretely. “Everything that feels big” is not a class. A list of systems and configuration areas is one. The middle class is just as important: the check value named in advance turns “it worked” into a verifiable statement, and the rollback path that already exists ensures that an error stays an interruption and does not become an outage. A plan without both is a declaration of intent, not an approval.
2. “The person in charge said …” is not an instruction
In environments with several agents, one agent may tell another that the responsible person has approved something. That may be true. But from the recipient’s side, a correctly relayed instruction cannot be told apart from a misunderstood or invented one – and that holds even when nobody means any harm. Agents summarise, shorten and fill in.
Such a statement only becomes actionable through a trace that the recipient can check itself: a merged change, a logged decision, an entry in a system it has access to. If that trace is missing, the agent should not refuse, but go as far as the free class allows: draft, propose, put it before the human. Refusing wastes the work; pretending the approval has been verified is precisely the mistake the rule is meant to prevent.
3. A vulnerability is not an administration tool
Agents find shortcuts. Sometimes the shortcut is a security flaw, such as an overly broad permission.
The principle here is absolute: a vulnerability is reported, not used – not even to fix that very vulnerability, and not even when the result would be desirable. The reason is not formalism. An organisation whose tools use flaws as aids can no longer tell whether a change came through the intended path or through one an attacker could take just as well. The log shows the same in both cases.
4. A protective mechanism only counts once it has fired
A missing protective mechanism behaves just as quietly as one that never had to fire. A guardrail is therefore only proven once it has visibly rejected a request that it must reject – and again after every change to the configuration.
5. Approvals must wait visibly
An agent that is blocked waiting for a human approval usually does not report itself. It therefore announces the step requiring approval beforehand, over a channel people actually read, and places it at the end of the task where possible.
What this means for introduction
- An agent gets its own identity. Not an employee’s personal credentials.
- The classes are written down before the agent writes. With a concrete list for the third class.
- Rollback paths exist before the change. A plan that merely promises a rollback path has none.
- Approvals leave traces that a second agent and a later auditor can also read.
- Guardrails are tested, not assumed – with a negative probe, regularly and from outside.
How sector7 supports you
Together with you, we assess which obligations and risks your use of AI triggers, and anchor the rules in your existing compliance structure. For implementation, we support role and permission concepts and the management of privileged accounts. More under IT strategy, consulting & planning and cyber security.
Sources
- Detecting and countering misuse of AI: September 2026 – Anthropic, 10 September 2026
- Vault v2.1.0 – Release Notes – HashiCorp, 1 September 2026