Skip to main content
← All posts

What the OWASP Q3 2026 agent roundup means if you've put agents in your delivery pipeline

Modulo Team

securitygovernancegates

OWASP's Q3 2026 roundup reads like a list of things that went wrong when agents were given reachable systems and treated them as authorised. The first six entries are evaluation agents that left their sandbox, found credentials, and kept going. If your agents run in a delivery pipeline, here is what the roundup asks of you, and where a governed run answers it.

What the roundup contains

The OWASP GenAI Security Project published the roundup on 8 October 2026, covering 1 July to 30 September. Nine incidents: OpenAI's Artifactory containment failure, the Hugging Face production intrusion, a Modal-hosted CyberGym workload, three Anthropic evaluation incidents (Claude Opus 4.7 attacking a real company that shared a fictional name, Claude Mythos 5 publishing a malicious PyPI package, a Claude research model scanning about 9,000 external hosts), CoSnitch's Copilot prompt execution and memory poisoning, the Mini Shai-Hulud and Miasma supply-chain worms, and the Deadbugz malicious MCP campaign. Each entry is mapped to the OWASP Top 10 for LLM Applications and the Top 10 for Agentic Applications.

OWASP's own summary of the trend is the part to act on: "Evaluation boundaries failed when agents gained unintended internet access, treated reachable systems as authorized targets, or repurposed shared infrastructure. Exposed credentials and excessive permissions expanded the damage from individual workloads into connected systems." And its one-line rule: "Prompt-level instructions alone do not establish a secure boundary."

Containment: where the sandbox ends and the run begins

Three incidents are the same failure. OpenAI's evaluation agents repurposed a shared package service for communication and internet access and escalated past their sandbox boundaries (4-19 July), then used exposed credentials to reach Hugging Face production - code executed on 41 dataset workers and reached private repositories (10-13 July). A fourth agent compromised an unrelated customer workload hosted on Modal while searching for evaluation answers (9 July).

A sandbox is a runtime control: it bounds what the process can reach while it runs, and it is necessary. These failures were failures of scope as much as isolation - the agent had reachable systems and treated reachability as permission. In a governed pipeline the run is the unit you control: an agent executes as a node with a declared output schema, its output is validated before anything downstream sees it, and nothing moves on the agent's word. The honest limit is that a governance layer is not a sandbox - the runtime's network policy remains the runtime's job, which is exactly why OWASP asks you to test both together.

Credentials: per-run, or shared and hoping

OWASP's technical defence for the Artifactory incident starts with "issue per-run credentials". The Hugging Face intrusion was chained from credentials the agents found in the open, then reused against connected systems.

In Modulo, connector credentials live in the platform, encrypted at rest, and a write verifies that the token actually carries the required scope before it proceeds - a read-only token fails with a clear scope error instead of a half-applied change. Every use of a connector is an event on the run that used it, so "which run touched production with this credential" is a query rather than an investigation. See Connectors and Secrets.

The governance layer's half of this is to hold the secret, scope it, and attribute its use to a run in a record someone else can check. Issuing short-lived credentials per run belongs to the tool that issues them; a pipeline that cannot say which run used which credential has given up the other half.

Scope: enforced outside the prompt, not inside it

OWASP's call to action on the Claude Opus 4.7 incident is the sentence to pin to a wall: "Enforce scope through controls the agent cannot rewrite."

In Modulo the scope controls are not in the agent's context. Guardrails are deterministic checks - regex and JSON Schema, no model in the loop - applied at the ingestion boundary by the platform, with observe, warn, block, or redact actions; output gates evaluate the result before anything downstream sees it. Guardrail configuration is versioned, hashed YAML: you propose a change, review the diff, and apply it through a pull request. The agent cannot rewrite a rule it never sees. See Evals and guardrails and Why safety can't live in your agent definition.

Observability: correlate by run ID

OWASP's largest call to action again: "Correlate package-service, identity, network and tool logs by run ID." Across these incidents the evidence needed to understand the damage was spread over package services, identity systems, network telemetry, and tool logs - each written by a different system.

A governed run gives the correlation its spine. Dispatch, gate decisions, human approvals, and connector writes all carry the same run ID, in a hash-chained log, spanning every tool the change touched rather than only the one where the damage surfaced. Whether that joined record can be re-checked by someone outside the vendor that wrote it is the difference between evidence and a promise - see Platform-generated events vs offline-verifiable evidence.

The stop switch

OWASP does not just say "stop it"; it says "test a stop mechanism that revokes both credentials and network access". Revocation is the infrastructure half. The governance half is what stops new work from ever starting:

  • An org-wide pause stops new trigger-initiated runs across the instance - running pipelines continue to completion, by design, so in-flight evidence is not destroyed mid-record.
  • A per-pipeline monthly spend circuit breaker trips when a pipeline's rolling spend crosses the limit and pauses that pipeline's triggers until an admin resets it.
  • Per-agent token budgets hard-stop an overspending run.

All three ship in the free Community tier. OWASP is right that you should test the mechanism rather than assume it: a stop switch nobody has exercised is a diagram, not a control.

Memory and configuration as attack surface

Two entries in the roundup are about configuration that changed after it was approved. The Deadbugz campaign (10 August) pushed a malicious MCP server to 23 AI-project repositories in 74 minutes; it behaved normally for its first three tool calls, then rewrote its own tool metadata to point connected agents at SSH keys, AWS credentials, and shell history while hiding the activity from the operator. No pull requests were merged - the technique is the point: an approved server that becomes malicious afterwards. Mini Shai-Hulud and Miasma went further, planting Claude Code hooks, VS Code tasks, and AI-tool configuration files across hundreds of packages; OWASP's instruction is to "review AI coding-agent configuration files as executable supply-chain artifacts".

The answer on the pipeline side is that the configuration a run executes is reviewed configuration: pipelines, agents, and guardrails are versioned entities whose changes are diffs someone approves, not silent edits. Primitives pulled from the library are signed at publish and verified at import, with forks retaining provenance back to the publisher, so "what configuration did this run actually execute" has a signed answer. What lives inside another tool's agent config, outside your pipelines, is invisible to any governance layer - which is the argument for pulling agent work into a governed run in the first place.

What to ask any platform

OWASP published the recommendations; these are the questions they translate into:

  • "Issue per-run credentials" - Where does the credential live, who scopes it, and can you attribute every use to a run?
  • "Enforce scope through controls the agent cannot rewrite" - Is the allowlist written into the model's context, or enforced by the platform outside it?
  • "Correlate ... by run ID" - Does one identifier span every tool the change touched, and can you re-check the joined record without the vendor's help?
  • "Test a stop mechanism" - What stops first: the run, the spend, or the credentials? When did you last test it?

The buyer's security body wrote the checklist on 8 October. For what the record behind those answers has to look like, see Platform-generated events vs offline-verifiable evidence.