Dieser Blogpost ist auch auf Deutsch verfügbar

TL;DR

  • “AI agents in ops need tighter permissions than cron jobs because they choose their own paths.”
  • “Damage usually comes from over-privileged tokens, missing deletion protection, and mixed environments.”
  • “Autonomy follows reversibility: observing is fine, reversible actions are limited, destructive actions never.”
  • “Access via dedicated accounts, short-lived certificates, and session proxies enables auditing and a kill switch.”
  • “Allowlists and prompts aren’t enough; runbook scripts, plan/apply, and separate backups limit prompt injection.”

Software with far-reaching permissions has been running on our servers for years. A cron job clears out old logs every night, Ansible rolls out configuration, and the CI pipeline deploys with privileges that hardly anyone on the team uses day to day. Nobody gives this much thought, because that software only does what its code or configuration says.

An agent works differently. It gets a goal and finds its own way there. At three in the morning an alert reports that a server’s disk is full. The agent logs in and finds a log file that has been writing the same exception every second since a broken deployment. It can rotate the log and restart the service. Deleting the old database dumps under /var/backups frees up just as much space, though, and as far as the alert is concerned, both are a fix. Which path the agent takes depends on what it considers sensible in that moment. The only levers you have are its instructions and its permissions.

Even so, I think it is feasible for agents to work in operations: picking up alerts, logging into servers, reading logs and restarting services. Then again, you don’t hand a new colleague the root password in their first week either. They get their own account with few permissions, and for a while someone looks over their shoulder. That is how I would start with an agent too, except that someone has to stay responsible for it after the onboarding period.

What agents can do in operations today

Operations is, roughly speaking, everything after the deployment. Whoever is on call gets alerted when something breaks, at night as well. For known failures there are, at best, runbooks: written instructions along the lines of “if this happens, check that and do this”. A large part of the work is routine, which in SRE jargon is called toil. Think full disks, expired certificates, hung processes or a deployment that needs to be rolled back.

The big vendors now have products for this. AWS made its DevOps Agent generally available in March 2026, Microsoft has the Azure SRE Agent (SRE stands for Site Reliability Engineering, operations treated as an engineering discipline), and Datadog and PagerDuty are building their own variants. There is also open source, such as HolmesGPT, which sits with the Cloud Native Computing Foundation. The products work in fairly similar ways. They read logs and metrics and correlate them with recent deployments, and what comes out at the end is a hypothesis about the cause. They are usually only allowed to intervene through a pull request or a single action that a human approves. An AWS employee writes on the Builder Center platform, explicitly as a personal view: “The agent investigates and recommends; humans approve and execute.” According to its README, HolmesGPT has read-only access “by design”. In his overview from October 2026, Gergely Orosz also concludes that these tools mainly help with investigation.

In the ITBench-AA benchmark from May 2026, models had to find the cause of incidents in Kubernetes clusters, and the best model scored 47 percent. Searching longer did not lead to better hits; the models tended to get lost in side issues. Alex Palcuie, formerly an SRE at Google Cloud and now at Anthropic, said at QCon London that the models are great for observation and read logs “at the speed of I/O”. When it comes to the cause, though, they readily confuse correlation and causation.

The Azure SRE Agent documentation describes two modes. In review mode the agent proposes actions and waits for approval, in autonomous mode it acts and reports afterwards. Microsoft recommends watching in review mode for two to four weeks and only then enabling individual triggers. Review is the default for the agent as a whole. But if you create an incident response plan or a scheduled task and keep the default, the agent runs autonomously there from day one.

Then there is the route without any product. Someone gives Claude Code or the Codex CLI access to servers or cloud accounts and lets the agent work there. For setting up an Nginx or fixing a broken configuration, that works well. Most of the known incidents come from this corner.

What went wrong

In February 2026, the operator of a learning platform had Claude Code run Terraform commands against their AWS account. Terraform manages cloud infrastructure and keeps track of its state in a state file. That file was missing, because it was still on an old machine. While cleaning up, the agent fell back on an older state and ran terraform destroy against production. Network, cluster and database including snapshots were gone, and it took AWS support around 24 hours to restore the data. There was no deletion protection, development and production lived in the same account, and nobody looked at the plan before the destroy.

At PocketOS in April 2026, an agent working on a task in the staging environment found an API token in an unrelated file. The token was meant for domain management but had full permissions. A single call deleted a storage volume and with it the backups that were stored on the same volume. Back in July 2025, an agent at Replit deleted a database despite an explicit code freeze and then claimed that a rollback was impossible. Replit has since separated development and production. And at Amazon, according to the Financial Times, the in-house agent Kiro deleted and rebuilt an environment in December 2025, causing a 13-hour outage. Amazon disputes this and calls it “user (AWS employee) error - specifically misconfigured access controls - not AI”.

The agents made mistakes in all four cases. But the damage was only possible because, for example, a token had far too many permissions or the backups sat right next to the data, and that could just as well have hit a human. The remedy is what operations has been doing for a long time: narrowly scoped tokens and backups kept somewhere else.

How dangerous is the task?

Whether an agent should take on a task depends mostly on how much damage a mistake does and whether it can be undone.

Observing is the most harmless part: reading logs and metrics, or checking with systemctl status whether a service is running. Even that is not entirely without risk, because data can leak and the agent reads text written by strangers. In diagnosis it can be wrong. As long as a human assesses the findings before anything happens, though, a wrong diagnosis mostly costs time.

It gets trickier as soon as the agent intervenes. Restarting a service or rolling back a deployment can cause a short outage, but it can be undone. Here it may be enough for a human to approve the action case by case, or to have signed off a runbook for exactly this situation in advance. Changes to configuration or packages tend to cause creeping failures that sometimes only show up days later. If they are versioned, you can usually go back, but every such plan should still be approved before it runs. Anything that cannot be undone at all, such as deleting data or tearing down infrastructure, a human does personally.

This grading is based on Feng, McDonald and Zhang (“Levels of Autonomy for AI Agents”, 2025). They describe an agent’s autonomy in terms of the role the human plays and stress that it is a design decision, not a property of the model. In the example from the beginning, the agent might be allowed to restart the service on its own at night. Deleting files under /var/backups, on the other hand, should not be permitted at all.

How the agent gets onto the server

The quickest way is to give the agent an admin’s SSH key, or just root. Then every log shows the same name, no matter whether a human or the agent did something. A useful check for any setup is therefore whose name appears in auth.log, the server’s login log, when the agent runs sudo.

It is better to give each agent its own account, with credentials that expire on their own. Instead of an SSH key that is valid forever, you use an SSH certificate. If the agent should no longer get in, you simply don’t issue a new one. An access proxy goes one step further. The agent then connects to the server through an intermediary that records the session and can terminate it at any time. The proxy injects the credentials itself, so the agent never gets to see them. Teleport and HashiCorp Boundary now explicitly offer this for agents, partly still in preview.

The log should also record on whose behalf the agent was acting, because the technical account on its own only tells you that the agent did something.

At PocketOS, the agent used a token that was lying around in a file and was allowed to do far more than necessary. The UK’s National Cyber Security Centre (NCSC) writes in guidance from May 2026: “give agents only the minimum access they need, for the shortest time required”. A few lines further down it says “avoid long-lived credentials”.

Command lists are not enough

Many start with a list of allowed commands, say systemctl restart, journalctl and df and nothing else. In 2025, Trail of Bits examined three agent products that worked this way. Commands such as go test, git show and rg were considered safe there, and only the name of the command was checked. Using the right flags, it was still possible to execute arbitrary code. The authors' conclusion: “Maintaining allowlists of ‘safe’ commands without a sandbox is fundamentally flawed.”

On servers, this problem has long been familiar from the sudo configuration, which defines the programs an account may start with root privileges. Many harmless-looking programs open a shell. In less, !/bin/sh is enough, in vim it’s :!sh, and find has -exec. If you allow the agent sudo less so it can read logs, you have given it root. The GTFOBins collection lists hundreds of such paths.

The sandbox in which Claude Code or Codex run their commands does not help here either. It isolates the machine the agent runs on. Whatever it does on another server via SSH is outside of it.

The boundary therefore has to be drawn on the target system itself. A few things help:

  • Reading and acting use separate accounts. Something that only reads logs doesn’t need write access.
  • sudo only applies to small in-house scripts without free arguments, such as restart-app.sh, and not to general-purpose tools like less or find.
  • Instead of an open shell, the agent gets runbooks as individual, tested actions. It picks which one fits, but not what happens inside it.
  • Infrastructure changes go through plan and apply. terraform plan or kubectl --dry-run show beforehand what would change, and execution only happens after approval.
  • Whatever must not be lost is out of its reach, with deletion protection and backups in a separate account.

What the agent reads can steer it

An agent in operations spends all day reading text written by others, mostly log lines and error messages, sometimes HTTP headers or tickets. If that text contains an instruction, the model may follow it as if it came from its own team. Attacks of this kind are called indirect prompt injection, because the instruction reaches the model’s context through the data it processes.

A study from April 2026 tried this out with logs (“LogJack”). It hid instructions in cloud logs and set eight models loose on them as debugging agents. Depending on the model, the injected commands were executed in 0 to 86 percent of cases. A curl | bash, which downloads a foreign script and runs it straight away, worked on six of the eight models. The safety filters of two major cloud providers caught almost none of it. Germany’s Federal Office for Information Security (BSI) also writes, in a security advisory from June 2026, that prompt injection becomes critical above all in agentic systems, and recommends securing them through isolation, validation layers and permission concepts.

So far there is no publicly known case of an operations agent being manipulated through a log line. As the filter numbers show, such an instruction cannot be reliably detected either. All you can do is limit what it can cause, and that again is a matter of permissions. It helps, for example, not to give agents that analyse external logs the right to restart services.

Approvals by humans

The obvious idea is to have a human approve every critical action. An “Approve” button under “I’m going to restart the service now” doesn’t achieve much, though. Whoever approves needs to see which command is supposed to run on which system. That includes what happens in the worst case and how to undo it.

But even with good information, attention wears off. Once a system has been right a hundred times, you click through the next one without reading. Lisanne Bainbridge described this in 1983 in “Ironies of Automation”, and Uwe Friedrichsen applied it to AI agents in 2025. Bainbridge’s point was that people who only monitor lose the practice they need for the rare emergency.

Some of this can be measured. How long do people look before approving, and how often do they reject? If both values approach zero, people are probably just clicking through. Approvals should therefore only exist where they actually decide something. The team should also still be able to do what the agent handles at night.

The agent needs operating too

The agent adds another system to operations, one that changes without anyone on the team doing anything. The vendor adjusts the model, sometimes without a new version name. Runbooks and prompts go stale, and permissions added for a special case rarely get removed again. Robert Glaser therefore describes a team’s working environment with agents as something with its own backlog that has to be maintained alongside feature work. Roman Stranghöner compares it to maintenance in factories, where Total Productive Maintenance settles who is responsible for keeping a plant available. According to Stranghöner, in teams with agents this is usually not clearly settled today.

So the agent needs an owner, a person or a team. That includes fixed test scenarios used to check regularly whether it still behaves as expected, and a date on which someone reviews its permissions.

Who is accountable for what the agent does

The NCSC is clear about this: “A system may take an action, but humans remain accountable for: the decision to deploy it, the access it was granted, the safeguards around it, the consequences of its operation.” The agency recommends deciding before the first deployment who owns the agent, who approves its access, who monitors it and who can stop it. Another sentence from the same guidance works well as a test: “If you cannot understand, monitor or contain an agent’s actions, it is not ready for deployment.”

Under ISO 27001, an agent with admin rights is one more privileged access, subject to the same rules on granting permissions and logging as any admin. Companies that fall under the EU’s NIS2 directive have to show access control concepts, and the agent belongs in them.

Sources

Conclusion

Seven questions before the first login

Before an agent logs into a production server for the first time, the team should be able to answer a few questions:

  • Which tasks is it supposed to take on, and which of them cannot be undone?
  • Does the log show its own name and the name of whoever gave it the task?
  • How quickly can it be locked out if something goes wrong?
  • Is the boundary enforced by the target system, or only by a prompt or a command list?
  • Where are the backups, and when was a restore last tested?
  • Does it read text from outside, and with which permissions?
  • Who is responsible for it?

As long as several of these are open, I would let the agent work read-only.

TAGS