When AI agents get production rights, text becomes an attack surface

What this is about

Help Net Security published an analysis on 20 May 2026 about AI agents in IT and network operations. The core issue is not that language models suddenly become malicious. It is simpler: many agents read text that attackers can influence while also holding tools that can change production systems.

The analysis builds on the arXiv survey Agentic AI in Network and IT Operations. It frames the risk as a confused-deputy problem: an authorized system is tricked into using its privileges for an attacker’s goal.

What AI operations agents actually do

These systems summarize alerts, read tickets, search runbooks, propose configuration changes and, in some environments, trigger changes through APIs. That is where the break happens: an agent treats a ticket, chat transcript or log entry as work material. For attackers, the same artifacts can be input channels.

The analysis lists several attack patterns. Indirect prompt injection hides instructions in tickets or wikis. Retrieval poisoning changes knowledge sources so the agent reaches the wrong conclusion. Retrieval jamming floods search with blocking information. Manipulated telemetry can steer the agent toward the wrong mitigation without compromising the model itself.

Why it matters

The difference from ordinary chatbots is the privilege layer. An LLM that only drafts text has limited blast radius. An agent with access to change-management APIs, network controllers or deployment pipelines can cause real damage when it fails.

For companies this matters because many vendors sell autonomy as an efficiency promise. The security question is not: "Can the agent make useful suggestions?" It is: "What happens when an attacker controls the text from which the agent derives those suggestions?"

In plain language

Imagine a building caretaker who has every key and blindly follows work orders dropped into a mailbox. As long as only employees write the notes, the process works. Once a stranger can drop in a manipulated note, the keyring itself becomes the risk. The safer design is: the caretaker may propose actions, but critical doors open only after an independent check.

A practical example

A fictional platform team runs 120 microservices. Each week it receives 700 tickets and 40 automated alert chains. An agent reads the tickets and proposes database configuration changes when latency rises. An attacker places an instruction in a harmless-looking ticket that labels some guardrails as "obsolete". Without a hard split, the agent might prepare a change that weakens access controls. With a propose-commit model, the agent can only draft a diff; policy-as-code, four-eye approval and staging tests separately decide whether it may be applied.

Scope and limits

• The analysis does not prove that every IT agent is unsafe. It shows where architecture breaks when reading, deciding and writing collapse into one model.
• Prompt rules alone are not a security boundary. They can help, but they do not replace non-bypassable write controls.
• Read-only agents have a different risk profile from agents with production rights. Marketing that blends the two makes evaluation harder.

SEO & GEO keywords

Agentic AI security, confused deputy, prompt injection, retrieval poisoning, IT operations, production access, policy as code, OWASP excessive agency, AI agents, DevSecOps, incident response, arXiv 2605.12729