Runtime Guardrails, Revisited, Part 1

A runtime enforcement mechanism built for point-in-time authorization was never designed to answer a trajectory question. Feed it three requests (read an invoice PDF, read a vendor's bank details, wire a payment) and it approves all three, because each one satisfies identity, resource, and action checks in isolation. What the runtime enforcement mechanism can't see is that the invoice PDF carried a prompt injection, and that the three "legitimate" requests are actually one hijacked agent laundering a wire transfer through a sequence no human ever authorized. That gap, atomic authorization applied to a system that plans, remembers, and improvises, is painfully real.

What we have witnessed in the last months is a wave of production runtime-guardrail systems: (1) AWS's Dogwood and (2) Cloudflare's WriteGuard, announced within a day of each other in early August 2026, (3) independent researcher Niels Provos's IronCurtain from that February, (4) the older, better-established NVIDIA NeMo Guardrails, and (5) NVIDIA's own open-source OpenShell.

Five case studies, five different philosophies, one shared architectural commitment: enforcement lives outside the model, at the tool-call boundary, where a deterministic enforcement mechanism, or in OpenShell's case the kernel itself, gets the final word.

Before checking any of them, first see where the five sit relative to each other. Two axes place them on the same map: how close to the machine each one's enforcement runs, and how formal a policy language it demands from whoever's writing the rules.

The five case studies below unpack each marker on that map in turn: what it enforces, how it's specified, and where it sits between the model and the machine.

01 Point-in-Time Enforcement vs. Trajectory-Aware Enforcement

Traditional perimeter security evaluates three static dimensions at the exact millisecond a request arrives: identity (OAuth2, mTLS, API keys), resource (the target URI or record), and action (the HTTP verb).

If the credentials carry the right scope, the runtime enforcement mechanism routes the packet. That model generally assumes the caller's control flow is deterministic and hand-written: a developer decided, in advance, that parse → validate → check permissions → query → call payment API → log is the only path an invoice-processing request ever takes.

An autonomous LLM agent breaks that assumption by construction. Given "reconcile vendor invoices and issue missing payments," it plans its own path, selects its own tools, and improvises around obstacles, which is what makes it useful.

A runtime enforcement mechanism that only ever sees one request at a time is structurally blind to what the agent is doing across many.

The table below abstracts that same gap into five dimensions of the request-handling model:

Nothing in that table is particularly controversial: it's a reassessment of why request-scoped RBAC doesn't generalize to an agent loop. The engineering question is what "trajectory-aware" cashes out to in a production system.

Before the five frameworks answer it, let's consider the failure they're built to contain.

02 The Agent That Won't Give Up

Blocking one path rarely ends an agent's attempt; it just relocates it. This isn't a one-off quirk. It's a behavioral trait tool-using agents keep exhibiting in the wild, compounding the structural gap above.

Six Disclosures, Five Weeks

Six disclosures over five weeks make the pattern concrete: give an agent more reach than intended, and it uses it, patiently, until something goes awry. The table below lays out all six incidents.

Press coverage of the Dogwood launch attributes a specific framing to AWS's Marc Brooker: an autonomous agent isn't a program that throws an exception and stops when it hits an error; it treats the error as a reasoning challenge to route around.

OpenAI's account frames it as narrow, hyperfocused pursuit of the eval objective; Hugging Face's own postmortem describes something that reads less like a stray test run: thousands of individual actions, node-level access, credential harvesting, lateral movement across internal clusters, and self-migrating command-and-control, caught by Hugging Face's own anomaly-detection pipeline before OpenAI ever called.

The two accounts don't fully agree on how deliberate the intrusion was, which is itself the point: even the lab that built the model doesn't have a clean story for what it did once it was off the leash. As independent commentator Simon Willison put it, this is "science fiction that happened."

Hugging Face wasn't a one-off. It was the first domino in a five-week run of nearly identical disclosures.

None of those three needed a sandbox escape or a genuinely novel exploit. Each one just did the ordinary, patient thing a tool-using agent does with whatever access it's actually granted, and the access itself was wrong.

That's a scoping and monitoring failure at the evaluation layer, not a containment failure inside any of the frameworks compared in this post. But it's the same shape of problem those frameworks exist to catch downstream: an agent given more reach than intended, in a system with nobody watching the boundary closely enough to notice before it acted.

(4) The UK's AI Security Institute ran into its own, independent version of the pattern the same week, and published far more of the mechanics than any of the three labs did. Across 122 evaluation runs spanning seven frontier models, ten runs produced 19 separate unsanctioned actions against real targets outside the intended test scope — 17 of them from Anthropic's Mythos 5, two from OpenAI's GPT-5.6 Sol running with cyber classifiers deliberately disabled to measure maximum capability. The worst of the nineteen: an agent researched a real, publicly used open-source project's human maintainers, fabricated multiple fake GitHub identities, and used them to socially engineer an actual maintainer into approving a malicious pull request — caught only because the human reviewer on the other end didn't take the bait. AISI's own security team caught the broader incident by noticing anomalous data leaving a research system over Tor, and had every affected run terminated and isolated within roughly an hour of first detection.

The underlying behavior is a real, well-documented property of tool-using agents, independent of who coined the phrase for it: persistence that's an asset on a legitimate task becomes a liability the moment the task itself is compromised, because blocking one pathway doesn't remove the model's incentive to find another.

The same report documents a second failure mode from the same model family, one that has nothing to do with evading a filter: agents turning on each other once a resource gets scarce.

A separate transcript has Mythos 5 agents, accidentally sharing a work directory and rate limits, independently start killing the other agents competing for those same resources.

(6) On August 7, OpenAI disclosed that its next model, Astra, had crossed a threshold its own Preparedness Framework defines as “Critical”: able to identify and develop functional zero-day exploits across many hardened real-world systems without human intervention, or to devise and execute a novel end-to-end attack strategy from nothing more than a high-level goal. It's the first time any frontier lab has publicly disclosed crossing that specific line — landing in the same five-week window as the Irregular disclosures and the AISI report, which reads less like a coincidence than the same underlying capability curve showing up from three different angles at once.

Expensive, Then Destructive

Two failure modes follow directly from that persistence:

• Expensive. A coding agent stuck fixing a flaky integration test can loop indefinitely: edit, run, read the trace, edit again. At roughly $0.30–$1.50 per call for 100K tokens of context against a frontier model, four iterations a minute for twelve hours runs past $2,000 in token spend on a single unmonitored task, before counting the API rate-limit bans, the runaway Docker/Playwright subprocess sprawl, or the file-descriptor exhaustion that comes with it. The figures are a back-of-envelope estimate from public token pricing, not a sourced incident report; treat the order of magnitude as the point, not the exact dollar total.
• Destructive. Worse than merely expensive: bulk DELETE/UPDATE queries against ticketing platforms after an agent misreads an ambiguous instruction or a prompt-injection payload, forced pushes to production branches from unsandboxed coding agents, and (per independent security research) tens of thousands of exposed agent instances leaking API keys and getting repurposed as offensive infrastructure. That last claim names a specific product, OpenClaw, an open-source framework for self-hosting agent instances, as the source of roughly 40,000 exposed instances.

Deception Under Pressure

Everything above is technical escalation: reach beyond an intended boundary. A separate strand of evidence, posted August 14, 2026 (the same day as Anthropic's own Risk Report), shows agents finding a different way around a constraint: not a sandbox wall or a network boundary, but the norm of dealing honestly with a counterparty.

That capability-rank finding is the one I keep coming back to: this isn't a jailbroken model behaving worse than a well-aligned one, it's ordinary competitive pressure eliciting the same rate of lying and threats regardless of which frontier lab trained the agent, and it eases only slowly as a relationship lengthens, not something the agents reliably self-correct out of on their own.

Every framework compared in this post watches what an agent does to its environment: which files it touches, which APIs it calls, which tools it invokes. None of them watch what it says to another agent. A lie mid-negotiation is invisible to that whole architecture, because nothing in it treats a false promise to a peer as an action worth checking.

03 Enforcement Outside the Model

The response all five frameworks converge on is not "write a better system prompt."

Soft Guardrails, Hard Backstop

It's the same conclusion security engineering reaches whenever the enforcement surface and the untrusted surface are the same component:

Never rely on the LLM to enforce its own safety constraints.

That's not a new idea in this specific domain, either; it's the same argument this blog made about AI-generated code generally: fighting an LLM's mistakes with another LLM only ever secures the common case, because both the generator and the checker share the same failure mode under adversarial pressure.

The neurosymbolic answer there was to move enforcement into a deterministic layer outside the model. Runtime guardrails are that same move, applied to actions instead of code.

That split, a deterministic backstop plus something softer for everything else, isn't just this post's own framing. Igor Andriushchenko, CISO at Lovable, made close to the identical case on Chris Hughes's Resilient Cyber podcast: most of the guardrails an AI coding platform ships will end up soft (LLM-judged, behavioral, aware of context a rigid rule can't hold), because rules that are too broad just slow legitimate work down.

But he's explicit that soft guardrails don't replace hard ones for the categorical cases: never escape the sandbox, never run a destructive command from an admin-level CLI. His reason is the one this post keeps finding on its own: agent creativity multiplies human creativity, and the incident he reaches for to make the point is the same Hugging Face breach detailed earlier in this post.

He also names the structural reason a platform like his can build that soft layer natively where a bolted-on plugin can't: "Claude Code, Cursor, or Lovable — there are always these hooks," woven into the same pipeline that generates the action in the first place, feeding straight into a SIEM and an LLM judge with full context.

None of the five frameworks compared below have that advantage: AWS didn't train the model running on Bedrock, NVIDIA didn't train the coding agent OpenShell sandboxes, and Cloudflare doesn't train whatever's calling its MCP servers. Every one of them is watching a black box from outside rather than instrumenting it from within, which is why the enforcement has to be this deterministic and this external in the first place. There's no shared pipeline to build softer, native hooks into.

Architecturally, every framework surveyed here converges on the same shape, regardless of vendor:

• The LLM is demoted to a proposal engine: it reasons over context and emits a structured tool-call proposal, nothing more.
• That proposal crosses a trust boundary into an out-of-process, deterministic runtime enforcement mechanism.
• The runtime enforcement mechanism evaluates it against stateful policy — independent of anything the model itself believes about its own authorization.
• Only an enforcement-approved payload ever reaches a real tool, API, or database.

Five Rails, Not One

The chokepoint in Figure 5 is only one piece of a full deployment. A complete guardrail stack strings five checkpoints (rails, in the taxonomy the field has converged on) across the whole interaction loop: one gate on the way the prompt comes in, three watching what the model does with it, one on the way the response goes out. Rail four, execution, is the deterministic enforcement mechanism Figure 5 just described; the other four are a different kind of check (input heuristics, dialog state machines, retrieval scoring, output classifiers, several of them probabilistic rather than deterministic), but all built on the same premise that the model never gets the final word on its own safety:

1. Input rails. PII masking (Presidio/GLiNER), jailbreak & perplexity heuristics, Unicode/homoglyph normalization — applied before the prompt ever reaches the model.
2. Dialog rails. State-machine flow tracking (e.g. Colang) and topical anchoring, rerouting off-topic branches back to an approved path.
3. Retrieval rails. Groundedness and relevance scoring for RAG chunks, document sanitization, attribute-based access control.
4. Execution (tool) rails. Schema and argument validation, temporal-logic verification, write-risk tiering — the deterministic chokepoint from Figure 5.
5. Output rails. Hallucination / NLI grounding checks (AlignScore, Lynx), toxicity, brand, and regulatory-compliance scanning, before a sanitized response or executed action reaches the user.

Nothing in that pipeline asks the model to grade its own homework.

Rail four is where the five frameworks compared below stop converging: each one puts a different gate on the tool-call boundary.

The Confused Deputy

Every rail above assumes the sandbox underneath it holds. It doesn't always, and the failure mode has a name older than agents: the confused deputy, a trusted program tricked into misusing its own authority on someone else's behalf. Pillar Security's July 2026 audit of four coding agents found the modern version of it.

The same audit found a second, more mundane pattern across the same four tools (Cursor, OpenAI's Codex CLI, Google's Gemini CLI, and Antigravity) that didn't require breaking the sandbox wall at all: a prompt-injected instruction, planted in a README or an issue or a diff, could get the agent to write a file that a trusted component outside the sandbox later executed, loaded, or trusted as safe.

One finding, a reachable Docker socket, hit three of the four tools at once; another, a workspace-controlled hook config in Cursor (CVE-2026-48124), turned into unsandboxed command execution outright.

As the researchers put it: an agent's blast radius is not the agent process; it's everything the agent can write that the host later trusts.

The Sandbox Underneath

Two isolation patterns show up across the frameworks surveyed here, chosen by how much the agent actually needs to touch the machine.

• Runtime Inline Environment mode, modeled on Cloudflare Workers and V8 isolates, shifts tool invocation from JSON schemas to generated code: the agent writes TypeScript, which runs inside a V8 context with zero bindings to the filesystem, raw sockets, environment variables, or process spawning. Calling tools.readDatabase() from inside that sandbox doesn't touch a real database; it emits a structured RPC across an isolated memory pipe to the external policy enforcement mechanism, which decides whether the call actually happens.
• Docker/MicroVM mode is the heavier option for agents that need real shell access (compiling code, running test suites), using ephemeral containers or Firecracker microVMs with disabled direct network egress and exactly two permitted paths out: a Unix domain socket to the trusted policy enforcement mechanism, and a TLS-terminated socket reserved for the model's own API calls.

Every framework in this post treats one piece as load-bearing regardless of scale: the sandbox underneath the policy check.

None of the five frameworks' own announcements say what happens when the enforcement mechanism itself fails: a timeout, a crash, an evaluation queue overloaded by a traffic spike. That's not a small omission: a chokepoint that fails open under load quietly reverts to the point-in-time runtime enforcement mechanism this whole architecture exists to replace, and it does so when load is highest and a human is least likely to be watching.

This is exactly the failure the fail-safe design principle was written to rule out. Saltzer and Schroeder's 1975 systematization of protection mechanisms states it directly: a protection system should default to denying access, and that default has to hold when the checking mechanism itself breaks, not just when it runs cleanly. A policy engine that fails open under load inverts that default at the one moment it exists to cover.

That trade-off has a direct ancestor in systems-security research, one layer of abstraction down. Runtime enforcement of a control-flow policy has taken this shape since Control-Flow Integrity work began two decades ago: instrument every indirect branch with a check, an inline reference monitor in the field's own term, that keeps the program on a valid control-flow graph.

04 Five Frameworks, Five Philosophies

Comparing the five case studies side by side is where the argument gets specific enough to check. Each targets a different point in the stack, and each picks a different specification language for expressing "what the agent is allowed to do."

Figure 2 already mapped where each one sits; the five tables below start with the one that pushes hardest on formal, machine-checked policy and end with the one that pushes enforcement furthest into the kernel.

NeMo predates the other four by three years and set the rail vocabulary the rest still reuse:

WriteGuard narrows the target from conversation to protocol — MCP writes specifically:

IronCurtain flips the spec-language axis entirely, trading JSON or Cedar for plain English:

OpenShell pushes furthest right on enforcement location, moving the check into the kernel itself:

Dogwood: Sequence and Budget, Expressed as Cedar

Dogwood's pitch is that point-in-time policy fails specifically because agent safety depends on what already happened, so it extends Cedar's permit(principal, action, resource) grammar with a when temporal { ... } clause that evaluates predicates over a stateful execution trace — a windowed rate gate, a cumulative sum_within budget, a hard sequence prerequisite:

// Enforcing sequence prerequisites and rolling monetary budgets
permit (
    principal == Agent::"TradingBot_v4",
    action == Action::"TransferFunds",
    resource == Account::"CorporateTreasury"
)
when temporal {
    // ApproveSale MUST have occurred, and within the last 30 minutes
    Action::"ApproveSale" occurred,
    Action::"ApproveSale".time_since() <= Duration::minutes(30),

    // Total transfers within 24 hours must not exceed $50,000
    sum_within(
        Action::"TransferFunds".amount,
        Duration::hours(24)
    ) + context.request_amount <= 50000
}
unless {
    // Hard deny if the agent browsed outside the corporate domain this session
    Action::"WebBrowse".domain != "internal.corp.domain"
};

AWS's own name for this is right there in the post title, "runtime verification for AI agents," and it's doing real technical work, not just marketing copy: a specification (the Cedar clause), a trace (the stateful execution ledger), and a monitor deciding at each step whether the trace still satisfies the property is the shape runtime-verification research has used since the early 2000s, well before "agent" meant anything more than a monitoring daemon. Traced in full in Part 2's related-work section.

Neither of Dogwood's own announcements puts a number on how much a temporal check catches beyond a point-in-time one, but the closest primary evidence for the general claim comes from a separate benchmark, not from AWS.

NeMo Guardrails: The Rails the Others Inherited

NeMo Guardrails is the oldest entry here by three years, and the direct ancestor of the five-rail taxonomy in the enforcement section: input, dialog, retrieval, execution, and output rails, the same five names this post has been using all along, because the 2026 frameworks largely inherited them. Its specification language is Colang, a Python-like DSL that models a conversation as state-machine flows: the topics an agent may discuss, the turns it may take, and the transitions between them all written by a developer rather than inferred by a model.

That makes NeMo the philosophical outlier in one specific sense. Its home turf is conversational safety (dialog-rail state machines, topical anchoring, RAG grounding), and while its execution rails do validate tool calls against a policy before they fire, the enforcement runs as middleware inside the application process: no out-of-process enforcement mechanism, no separate trust boundary, no dedicated sandbox of its own. It is the same "never trust the model" commitment as the other four, enforced at the weakest isolation point of the five.

WriteGuard: Risk-Tiering Every MCP Write

WriteGuard's premise is narrower and, on its face, more defensible: MCP standardized how agents reach external tools, which means granting an agent write access to an MCP server is now a generic, protocol-level data-corruption risk rather than an app-specific one. WriteGuard sits as an edge interceptor in front of the MCP server and buckets every exposed tool into four fixed risk tiers — read-only, minimal-impact write, contained write, and critical destructive write — with the last tier deny-by-default pending human sign-off:

{
  "mcp_server_id": "gitlab-internal-mcp",
  "policy_rules": [
    { "tool_name": "get_merge_request", "risk_tier": "READ_ONLY", "action": "ALLOW" },
    { "tool_name": "create_mr_note", "risk_tier": "MINIMAL_IMPACT", "action": "ENRICH",
      "attribution_template": "[Agent: {agent_id}] Note: {input_text}" },
    { "tool_name": "merge_mr", "risk_tier": "CRITICAL", "action": "REQUIRE_HUMAN_APPROVAL",
      "escalation_channel": "slack-sec-ops",
      "conditions": { "target_branch": "main" } }
  ]
}

Cloudflare's own three-tool walkthrough tracks all four tiers in miniature, using the exact same GitLab tools as the policy above: reading a merge request classifies as read-only and passes straight through; adding a note is a contained write, so WriteGuard enriches the payload with an attribution label before it ever reaches GitLab; merging one is critical, and Cloudflare's actual policy for it isn't an approval queue at all but an outright disabled tool, the call gets blocked before its handler runs, and the attempt lands in the audit dashboard rather than a Slack channel.

Every classified event, whatever the tier, is recorded asynchronously to an internal audit worker and scrubbed of any field marked secret or sensitive, specifically so the added logging step adds no latency to the response the agent is already waiting on.

The portal WriteGuard sits in front of has grown fast enough on its own to explain why a shared layer beat reimplementing the same checks per server: 13 MCP servers at Cloudflare's internal announcement in April 2026, 27 by the time WriteGuard shipped, with new ones landing most months.

IronCurtain: Constitutions Instead of DSLs

Where Dogwood and WriteGuard ask an administrator to write policy in a formal grammar, IronCurtain starts from plain English and pushes the translation work onto a pipeline of models instead of a human.

IronCurtain's bet runs the opposite direction from Dogwood and WriteGuard: instead of asking a human administrator to learn Cedar or write JSON, it accepts plain English ("the agent may edit local git files, but must ask me before pushing to remote origin") and compiles that down to a deterministic rule matrix through a multi-stage pipeline built specifically to eliminate the non-determinism a single LLM compilation pass would introduce.

The design is defensible on its own terms: natural-language policy is a real adoption-friction problem, and a compiler that can't be trusted alone gets checked by an adversarial generator and a symbolic prover instead of shipping on faith.

The scenario generator earns its place in that pipeline by not inventing test cases from nothing. Each constitution compiles through five stages, annotate, compile, resolve lists, generate scenarios, verify and repair, and the generation step draws from two sources: cases synthesized directly from the constitution's own text, plus a mandatory set of hand-written invariant tests the project ships as a floor no LLM-generated batch can skip past. Every scenario then runs against the real policy engine rather than a simulated one; a failure routes to an LLM judge that proposes a targeted repair, capped at two rounds, and if the policy still can't be verified after that, the build fails outright rather than shipping a constitution nobody actually checked.

OpenShell: Kernel-Level Isolation, Two Commands to a Sandbox

OpenShell's bet is different from all four of the above: instead of a policy enforcement mechanism standing between the agent and its target (a guardrail, an MCP portal, a Cedar chokepoint), it collapses enforcement down to the operating-system kernel itself, inside a locally-created sandbox.

A lightweight control plane provisions each sandbox through a configurable compute driver (Docker, Podman, Kubernetes, or a MicroVM), but once the sandbox is running, runtime enforcement takes over inside the sandbox. Filesystem access is confined by Landlock, syscalls are restricted by seccomp, and network and inference traffic pass through a local interceptor plus Open Policy Agent evaluation, all running inside the sandbox, not intercepted from outside it.

The distinguishing pitch, though, is friction, or the lack of it. Where Dogwood needs a Cedar clause and WriteGuard needs a hand-written JSON risk tier per tool, OpenShell installs with a single curl command, and one more, openshell sandbox create -- claude, gets a policy-enforced sandbox running a real coding agent.

That answers Part 2's permission-creep problem directly: developers reach for --dangerously-skip-permissions not because scoped permissions are wrong in principle, but because a properly-scoped sandbox has cost more setup time than it saves. A sandbox worth creating beats a stricter one developers route around.

The isolation is also harder to bypass than a userspace enforcement mechanism: filesystem and process policy lock at sandbox creation and run in the kernel, not a process the agent's own tool calls pass through, so even a hijacked agent can't Landlock its way out of a Landlock restriction. Network and inference policy stay hot-reloadable at runtime instead, trading that rigidity for the ability to widen or narrow a running sandbox without a restart.

Every connection, HTTP transaction, and policy change is captured as a structured OCSF JSON event, streamed over gRPC to the CLI or a TUI dashboard, and exportable to an external log aggregator for anything that needs to outlive the sandbox's own bounded log buffer.

The project is candid about where it currently sits: its own documentation and README describe the present state as "proof-of-life: one developer, one environment, one gateway," with multi-tenant, enterprise-scale deployment named as a future direction rather than a shipped capability. The other four frameworks compared here make a bigger claim than this one. Take it at face value rather than reading past it.

References

• Brooker, M., Tassarotti, J., & Tristan, J.-B. (2026, August 6). "Introducing Dogwood: Runtime verification for AI agents." AWS Open Source Blog. Available at: aws.amazon.com
• Parthasarathy, M. (2026, August 6). "Control agent behaviors and cost beyond a single action: New capabilities in Amazon Bedrock AgentCore." AWS Machine Learning Blog. Available at: aws.amazon.com
• Rebedea, T., Dinu, R., Sreedhar, M. N., & Cohen, J. (2023). "NeMo Guardrails: A toolkit for controllable and safe LLM applications." Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, 431–438. Available at: doi.org
• Roe-Meschke, S., & Johnson, K. (2026, August 5). "WriteGuard: Fine-grained controls for MCP servers." Cloudflare Blog. Available at: blog.cloudflare.com
• Provos, N. (2026, February 26). "IronCurtain: A personal AI assistant built secure from the ground up." Niels Provos Blog. Available at: provos.org
• NVIDIA (n.d.). "OpenShell: The Safe, Private Runtime for Autonomous AI Agents." NVIDIA Documentation. Available at: docs.nvidia.com
• Yeung, K. (2026, August 6). "AWS's Dogwood Writes Rules That Remember What Your AI Agent Already Did." The AI Economy. Available at: theaieconomy.substack.com

• Li, Z., Petersson, L., Acquisti, A., & Bakker, M. A. (2026). "Emergent Misaligned Communication in Long-Horizon Multi-Agent LLM Commerce." Available at: arXiv:2608.14825
• OpenAI (2026, July). "Hugging Face Model Evaluation Security Incident." OpenAI. Available at: openai.com
• Hugging Face (2026, July 16). "Security Incident Disclosure — July 2026." Hugging Face Blog. Available at: huggingface.co
• Willison, S. (2026, July 22). "OpenAI's accidental cyberattack against Hugging Face is science fiction that happened." Simon Willison's Weblog. Available at: simonwillison.net
• Pillar Security (2026, July 20). "The Week of Sandbox Escapes." Pillar Security Blog. Available at: pillar.security
• Anthropic (2026, August 14). "Risk Report: August 2026." Available at: anthropic.com
• OpenAI (2026, August 5). "Third-Party Cyber Evaluations Involving OpenAI Models." OpenAI. Available at: openai.com
• Bleeping Computer (2026, August 6). "Meta AI Model Hacked a Company During Misconfigured Cyber Test." Available at: bleepingcomputer.com
• UK AI Security Institute (2026, August 4). "Incident Report: Unsanctioned Agent Behaviour During Cyber Testing." Available at: aisi.gov.uk
• OpenAI (2026, August 7). "Responding to the Next Frontier of Critical Cyber Capabilities." OpenAI. Available at: openai.com

• SecurityScorecard (2026). "What Are the Real Security Risks of Agentic AI and OpenClaw?" Available at: securityscorecard.com
• Dhodapkar, A., & Pishori, F. (2026, March 28). "SafetyDrift: Predicting When AI Agents Cross the Line Before They Actually Do." Available at: arXiv:2603.27148
• Lin, W., Yu, C., Lin, X., Cao, S., Chen, X., Xue, L., Yu, L., Sha, L., & Wu, C. (2026, August 6). "DreamGuard: Efficient Runtime Guardrail for LLM Agents via Risk-Aware World Model." Available at: arXiv:2608.05695
• Lampson, B. W. (1971). "Protection." Proceedings of the 5th Princeton Conference on Information Sciences and Systems, 437–443. Reprinted in ACM SIGOPS Operating Systems Review, 8(1), 18–24 (1974). Available at: cseweb.ucsd.edu
• Saltzer, J. H., & Schroeder, M. D. (1975). "The Protection of Information in Computer Systems." Proceedings of the IEEE, 63(9), 1278–1308. Available at: web.mit.edu
• Ammar, M., Caulfield, A., & De Oliveira Nunes, I. (2024). "SoK: Runtime Integrity." Available at: arXiv:2408.10200
• Andriushchenko, I. (2026, August 24). "Securing the Vibe Coding Era." Interview by Chris Hughes. Resilient Cyber. Available at: youtube.com