Agentic
security

Why agents break the old model
Classic application security assumes a boundary between instructions and data. Code is trusted, user input is not, and the job is to keep them apart. An AI agent erases that boundary by design: it reads a web page, an email or a document and then decides what to do next. The content it reads becomes, in effect, an instruction.

Add the three things that make an agent useful - tools, credentials and autonomy - and you have a system that can be told what to do by anyone whose text it happens to read. OWASP published a separate Top 10 for Agentic Applications in December 2025 for exactly this reason. The LLM Top 10 treats the model as something that receives input and produces output. The agentic list treats it as an actor with goals, keys and the ability to chain actions across many steps without a human in between.

Prompt injection is not one attack
Direct prompt injection - a user typing "ignore your instructions" - is the version everyone knows and the least dangerous. The one that matters is indirect prompt injection: the payload sits in content the agent will process later. A line of white text in a PDF. A comment in a code repository. A calendar invite. An email the agent was asked to summarise.

This is ASI01, Agent Goal Hijack. The attacker never touches your system. They place text where your agent will read it, and your agent carries out the instruction using your identity. Researchers have demonstrated extraction of private cryptographic keys from a self-hosted agent within minutes, purely through an emailed injection.

There is no filter that solves this. Instruction and data arrive through the same channel and look identical to the model. Detection helps at the margins; architecture is what actually contains it.

Tool misuse and unexpected code execution
ASI02 and ASI05. An agent with a shell tool, a file tool and an HTTP tool has, between them, a general-purpose exploitation kit. Nothing has to be vulnerable in the traditional sense. The attacker supplies a goal, and the agent assembles the steps out of features that all work exactly as designed.

The pattern security teams keep missing: the agent is not the target, it is the execution layer. Where an attacker previously needed a foothold, a privilege escalation and a data-staging step of their own, the agent now performs each stage on their behalf - inside the network, with valid credentials, generating logs that look like normal automation.

Identity and privilege abuse
ASI03, and in practice the most under-managed. Agents are typically handed one long-lived, broadly scoped credential because narrow scoping breaks their usefulness. That credential then sits on a workstation or a container with the rights of the person who installed it.

Ask a concrete question about every agent in your estate: if this process were fully controlled by an attacker for one hour, what could it reach? For most self-hosted agents the honest answer is the user's entire home directory, their SSH keys, their cloud CLI sessions, their password manager if it is unlocked, and every API integration configured in the agent.
OpenClaw: what host privileges actually cost
OpenClaw - the self-hosted autonomous agent that began as Clawdbot - is the clearest worked example available, because its problems are documented in public CVEs rather than in vendor marketing. It runs on the user's own machine, executes shell commands, reads local files, and is driven from WhatsApp, Telegram, Slack or Teams. Everything it needs to be useful is also everything an attacker wants.

Privilege escalation to full admin. CVE-2026-32922, CVSS 9.9. The device pairing subsystem let a caller holding only the limited operator.pairing scope rotate its own token into a fully privileged operator.admin token, because the rotation function never constrained the new scope to the caller's existing set. The result is remote code execution across every connected node. Fixed in 2026.3.11; the recommendation is 2026.3.21 or later, plus binding the gateway to localhost and firewalling port 18789.

The Claw Chain. Four further flaws that combine into a full compromise: CVE-2026-44112 (9.6) redirects write operations outside the intended filesystem root; CVE-2026-44115 (8.8) leaks environment variables - and therefore secrets - through heredoc expansion; CVE-2026-44118 (7.8) escalates privilege through an unverified ownership flag in loopback MCP communication; CVE-2026-44113 (7.7) crosses the sandbox boundary through a race condition on file reads. Chained: code execution, credential harvesting, owner-level privilege, persistent backdoor - with the agent's own privileges doing the work.

Exposure at scale. Scans in May 2026 found roughly 245,000 publicly reachable instances. Nobody deliberately publishes an agent gateway to the internet. They bind it to 0.0.0.0 to reach it from a phone, and that is the whole story.

The plugin supply chain. ASI04. More than 230 malicious "skill" packages appeared in under a week, impersonating legitimate utilities and shipping infostealers. An agent skill is code that runs with the agent's privileges, installed with roughly the ceremony of adding a browser extension.

Memory poisoning and the long game
ASI06 is the one that defeats incident response. An injection that writes to the agent's persistent memory does not have to fire now. It sits there and activates in a session next week, when the person who read the suspicious email has forgotten it. If your agent has long-term memory, that memory is a persistence mechanism, and it belongs in your forensic scope.

And the human in the loop
ASI09. Human-in-the-loop is the control everyone reaches for first, and it degrades faster than any other. After the fortieth approval prompt in a day, people click yes. A compromised agent that writes a persuasive justification for its next action will get that approval - and the fact that a human approved it is precisely what makes the action hard to challenge afterwards.

Approval only works when it is rare, specific and legible. "Agent wants to run a command" is not a decision anyone can make. "Agent wants to send 4.2 MB from /home/user/.ssh to an external host" is.
What actually reduces the risk
Give the agent its own identity. Never the user's. Its own account, its own keys, scoped to the specific systems it needs, short-lived, revocable in one step, and logged separately so you can tell agent activity from human activity in an investigation.

Isolate the runtime. A container or VM with a mounted working directory, not the user's home. No SSH keys, no cloud CLI profiles, no password manager socket. Bind the gateway to localhost. If remote access is genuinely needed, put it behind the VPN, never on 0.0.0.0.

Separate reading from acting. The strongest architectural control available today: an agent that has processed untrusted external content in a session should not, in that same session, hold the credentials to act on internal systems. Split the work into a retrieval step and an action step with a validated hand-off between them.

Treat every tool as a privilege grant. Enumerate the tools each agent has and write down what the worst legitimate-looking use of each one would be. Remove the ones nobody can justify. Most agents are configured with far more capability than their actual job requires.

Govern the skill supply chain. An allowlist, pinned versions, review before install, and someone accountable for it. The same discipline you would apply to any dependency that executes with production credentials - because that is what it is.

Test with injection, not with prompts. Red-team the agent by planting payloads in the content it consumes: documents, emails, web pages, repository files, calendar entries. Asking the agent nicely to misbehave tests nothing that matters.

Log the actions, not the conversation. Tool calls, arguments, files touched, hosts contacted, with retention long enough for a memory-poisoning investigation. A transcript of what the agent said is not evidence of what it did.

Where this meets the regulation
An agent that runs on your systems and touches personal or operational data is squarely inside your ICT risk management framework - and inside your AI governance obligations. Article 4 of the EU AI Act requires you to support AI literacy among the people operating your AI systems, and that duty applies now. ISO/IEC 42001 gives you the inventory, the impact assessment and the life-cycle records that make agent deployments auditable rather than improvised. Under DORA, an agent with production access is an ICT asset and belongs in the register.

The honest summary: agentic security is not a new product category. It is identity management, isolation and supply-chain discipline applied to a component that can be talked into things.

Related
Kurs: KI-Agenten (OpenClaw) sicher einsetzen
The EU AI Act - deadlines and obligations
ISO/IEC 42001 - the AI management system standard
Hardening your cloud instance