AIOps agents read a great deal of text they did not write. Alert descriptions, log lines, ticket comments, chat transcripts and runbook pages all flow into the model’s context, and any of them may contain instructions placed there by someone with bad intentions. This is prompt injection, and for an agent that can restart services or change configuration it is not an abstract research topic. It is an operational risk that belongs in the same register as credentials leakage and misconfiguration.
The core problem is that language models do not reliably distinguish between instructions from the operator and data they happen to be reading. A log line saying that the assistant should ignore previous instructions and delete a volume looks, to the model, like more text. If the agent has a tool that deletes volumes and nothing else stands in the way, a determined attacker only needs a way to get that sentence into a log, a ticket or an error message that the agent will later read.
The most reliable defence is to limit what the agent can do, not to limit what it can read. Apply least privilege to every tool. A diagnostic agent should hold read-only credentials. A remediation agent should be restricted to a short list of pre-approved actions on a defined set of resources, with parameters validated by deterministic code rather than trusted from the model. If the worst thing a successful injection can achieve is a harmless read, the attack has little value.
Separate untrusted content from instructions structurally. Place retrieved text inside clearly delimited blocks, tell the model that the content is data and must never be followed as a command, and avoid concatenating raw external text into the system prompt. These measures reduce the success rate but do not eliminate it, so treat them as a layer rather than a guarantee. Pair them with output checks that verify the proposed action against policy before anything executes.
Put a policy layer between the model and the world. Every tool call should pass through code that checks the caller, the target, the arguments and the context, for example refusing any deletion outside a maintenance window or any command touching production from an agent that was only asked about staging. Log the decision with the reasoning that produced it. When an injection does succeed in persuading the model, the policy layer is what turns an incident into a blocked and recorded attempt.
Require human approval for actions that are irreversible, expensive or externally visible, and make the approval request show the evidence the agent used, including the source of each piece of text. A person who sees that the justification came from a free-text field in a customer ticket will treat it with appropriate suspicion. Approval prompts that merely say the agent wants to proceed teach people to click yes.
Test for it deliberately. Build a small suite of adversarial inputs, such as logs containing instructions, tickets that impersonate administrators and runbook pages with hidden directives, and run it whenever the model, prompt or toolset changes. Monitor for symptoms in production too: tool calls that do not match the task, sudden attempts to reach unusual resources and responses that quote instruction-like text from sources. Prompt injection will not disappear, but agents built with narrow permissions, strict policy checks and good telemetry can keep it from becoming an outage.