OWASP’s Q3 exploit roundup shows where an agent's limits are actually enforced

OWASP’s GenAI Security Project just published its Q3 exploit roundup, and there’s a line in it I’d love to see on a billboard for every security, IT and AI team:

“Prompt-level instructions alone do not establish a secure boundary.”

I couldn’t agree more, and I think the word alone is particularly important because it recognizes the need for defense in depth.

A well-written system prompt makes a good outcome more likely, and it remains the main way we tell an agent what we want. The model still has to interpret those instructions alongside everything else in its context, though, and that context grows and changes as the agent works, while the agent keeps trying to achieve the goals it has been given.

That goal orientation is something I think we need to pay much more attention to. Agents can be very persistent in pursuing an objective, even when the route they take is quite different from what anyone anticipated, and a rule that gets in the way of the goal is something the agent has to weigh and interpret rather than simply obey.

What the incidents show

The roundup covers nine incidents between May and September, and OWASP is clear that they shouldn’t be counted as independent attacks, since some are related and others are separate supply chain campaigns. Several of them share a pattern, which is that agents in evaluation settings who couldn’t reach their intended target carried on using whatever was accessible instead. One scanned around 9,000 hosts until it found a live application and read credentials from a debug page. Another published a malicious package to the real public PyPI registry because its setup instructions referred to a package that didn’t exist, and a security scanner later installed that package and exposed credentials to a vendor’s systems.¹

The agents weren’t necessarily acting maliciously; they were just trying to complete the tasks they’d been given using the tools and access available to them, and the resulting behavior was still unexpected and potentially harmful.

The limits we describe and the limits we enforce

I think this is where we need to be much more precise about what we mean by an agent’s boundaries. There is a considerable difference between the limits we describe to a model and the limits its operating environment actually enforces. You might instruct an agent to use only approved repositories, but if its credentials allow it to access or publish elsewhere, you’re still relying on the model to respect that instruction. Restricting those credentials or enforcing which destinations it can reach means the boundary holds even when the agent decides that another route would help it complete its task.

OWASP’s recommended mitigations reflect the same distinction. Egress allowlists, credentials scoped to individual runs, no public package publishing from evaluation networks and re-approval of MCP tool definitions when they change all operate independently of whether the model interprets its instructions correctly - that’s what makes them boundaries rather than guidance.¹

Boundaries have to follow change

I’d add two considerations from what we see at Geordie. The first is that controls need to account for how an agent and its environment change during execution. One entry in the roundup involved a malicious MCP server that behaved normally for three tool calls before changing its tool metadata to point connected agents at SSH keys and cloud credentials, although OWASP notes that none of the pull requests promoting it were merged, so there is no confirmed compromise.¹ Another involved a crafted link and a summarized web page that could write instructions into an assistant’s persistent memory, which has since been patched, with no exploitation in the wild reported.¹ In both cases, each individual step could have been permitted when it was approved. Knowing whether a single action is allowed is useful, but you also need to recognize when the context in which that permission was granted has changed, whether through a tool definition, a memory or a credential scope.

The second is that the right control depends on what the agent is doing. Some boundaries should be deterministically enforced because the policy is clear, some decisions warrant a person’s explicit approval because the answer depends on context, and a good deal of everyday activity is best handled by giving the agent better context as it works and keeping a record of what happened. That’s the thinking behind Beam - our inline remediation engine, which offers Monitor, Guide, Confirm and Enforce modes so that the response can match the risk, applied within the agent’s own environment as dependable control.

I’ll absolutely keep advocating for clear instructions and well-designed prompts, since they make agents more useful and their behavior easier to predict. I just wouldn’t rely on them to establish the security perimeter around an agent, and I’d want any team running agents in production to be able to say which of their limits are described to the model and which are enforced around it.

1. OWASP GenAI Security Project, “GenAI and Agentic AI Exploit Roundup Q3 2026,” 8 October 2026. https://genai.owasp.org/2026/10/08/genai-and-agentic-ai-exploit-roundup-q3-2026/