In one paragraph

Security for AI agents splits into two broad problems: catching unsafe code before it ships, and enforcing limits on what a running agent can do. automated-security-helper and threat-modeling-mcp-server address the first, running scanners and structured threat analysis during development. webappsec-dbsc secures the browser sessions that agents or users depend on. dogwood, dogwood-local-engine, and box address the second, combining a temporal policy language with OS sandboxing. What counts here: policy languages, sandboxes and security tooling that limit what an agent may do or check what it builds.

The main approaches

Policy languages

A formal language that expresses what an agent is and is not permitted to do, evaluated at runtime against requests or event histories. dogwood defines Dogwood, a Cedar-derived language that adds temporal predicates so rules can reference an agent’s past actions, not just the current request.

Sandboxes

OS-level isolation combined with policy enforcement that intercepts filesystem access, network calls and tool invocations before they execute. box wraps an agent binary in an OS sandbox, evaluates Dogwood rules against every intercepted operation, and injects credentials into permitted outbound calls without exposing secrets to the agent process. dogwood-local-engine provides the durable, incremental policy engine that Box embeds.

Security review tools

Static analysis, IaC scanning, secrets detection and threat modeling that run before or during development. automated-security-helper orchestrates Bandit, Checkov, Semgrep, Grype and others in one pass and exposes the pipeline as an MCP server. threat-modeling-mcp-server walks an AI agent through nine-phase STRIDE analysis and exports structured reports. webappsec-dbsc is a W3C specification that binds browser sessions to device-held cryptographic keys, preventing stolen cookies from being replayed on another machine.

Map of the theme

flowchart LR
  t["Agent security and policy"]
  t --> f1["Policy languages"]
  t --> f2["Sandboxes"]
  t --> f3["Security review tools"]
  f1 --> r1["dogwood-policy/dogwood"]
  f1 --> r2["dogwood-policy/dogwood-local-engine"]
  f2 --> r3["strands-agents/box"]
  f3 --> r4["awslabs/automated-security-helper"]
  f3 --> r5["w3c/webappsec-dbsc"]
  f3 --> r6["awslabs/threat-modeling-mcp-server"]

Where the new ideas are

Stateful, temporal policy evaluation stands out here. dogwood adds temporal predicates (formerly, since, windowed aggregations) that let a policy say “deny this action because of what the agent did three minutes ago.” That is a different model from access control that only sees the current request.

dogwood-local-engine makes that practical at runtime: it ingests events incrementally, checkpoints derived monitor state to disk, and recovers after a crash without replaying the full history.

box ties the policy engine to OS isolation and credential injection. Secrets never reach the agent process; Box injects them into permitted outbound calls at the proxy layer.

automated-security-helper exposes a multi-scanner pipeline as an MCP server, letting an AI coding agent trigger scans and diff results directly from its tool-calling interface.

webappsec-dbsc moves session binding into the browser itself, requiring only server-side changes at sign-in and a refresh endpoint, rather than a pervasive infrastructure overhaul.

Side by side

Repo	Approach	Runtime enforcement	MCP integration	Output format	Language / spec
awslabs/automated-security-helper	Security review tools	Not stated	Yes, full MCP server	SARIF, JUnit XML, HTML, Markdown, CSV, JSON	Python
w3c/webappsec-dbsc	Security review tools	Specification defining browser-level session binding	Not stated	W3C Bikeshed spec	Bikeshed
awslabs/threat-modeling-mcp-server	Security review tools	Not stated	Yes, 11 MCP tools	Markdown, Threat Composer .tc.json	Python
dogwood-policy/dogwood	Policy languages	No (CLI replay for testing only, not production authorization)	Not stated	Per-event verdicts, lowered Cedar	Rust
dogwood-policy/dogwood-local-engine	Policy languages	Yes, incremental with crash recovery	Not stated	Not stated	Rust
strands-agents/box	Sandboxes	Yes, OS isolation plus Dogwood policy engine	Yes, MCP broker	OTLP JSON telemetry	Rust

How the idea moved

flowchart LR
  n1["started May 2022<br/>awslabs/automated-security-helper"]
  n2["started Jul 2023<br/>w3c/webappsec-dbsc"]
  n3["started Dec 2025<br/>awslabs/threat-modeling-mcp-server"]
  n4["started Jul 2026<br/>dogwood-policy/dogwood"]
  n5["started Aug 2026<br/>dogwood-policy/dogwood-local-engine"]
  n6["started Oct 2026<br/>strands-agents/box"]
  n1 --> n2 --> n3 --> n4 --> n5 --> n6

• started May 2022 · automated-security-helper · Adds: Orchestrates Bandit, Checkov, Semgrep, Grype and other scanners in one pass, normalizes findings to SARIF and other formats, and exposes the pipeline as an MCP server so AI coding agents can trigger scans and diff results directly.
• started Jul 2023 · webappsec-dbsc · Adds: Specifies a browser-native protocol that binds session cookies to device-held cryptographic keys, requiring only server-side changes at sign-in and a refresh endpoint to prevent stolen-cookie replay attacks.
• started Dec 2025 · threat-modeling-mcp-server · Adds: Walks an AI agent through nine-phase STRIDE threat modeling via 11 MCP tools, tracking completion state per phase and exporting Markdown and Threat Composer JSON reports.
• started Jul 2026 · dogwood · Adds: Defines the Dogwood policy language, a Cedar-derived syntax extended with temporal predicates that let rules reference an agent’s past action history, and ships a Rust parser, interpreter and CLI for validation, lowering to Cedar, and trace replay.
• started Aug 2026 · dogwood-local-engine · Adds: Evaluates Dogwood policies incrementally against a stream of agent events, checkpoints derived monitor state to disk, and resumes correctly after a crash without replaying the full event history.
• started Oct 2026 · box · Adds: Wraps an agent binary in OS-level isolation, enforces Dogwood permit/forbid rules against every intercepted filesystem and network operation using an embedded incremental policy engine, and injects credentials into permitted outbound calls without exposing secrets to the agent process.

Easily confused

Not the same as general application security scanning. Tools like Snyk or GitHub Advanced Security scan code bases too, but this theme is scoped to tooling that either targets AI agent workflows specifically (MCP integrations, agent sandboxes, agent governance policies) or defines policy mechanisms intended for agent runtime enforcement. A plain SAST scanner with no agent-facing interface sits outside the theme.

Not the same as AI safety or alignment research. This theme covers technical enforcement mechanisms: policy languages that produce permit/deny verdicts, OS sandboxes that intercept syscalls, and scanners that find vulnerabilities in code an agent wrote. It does not cover training-time alignment, red-teaming models or evaluating model behavior.

Not the same as identity and access management. webappsec-dbsc concerns session credential binding, which might look like an IAM topic. The distinction is that DBSC protects the session tokens an agent or user already holds from being stolen and replayed, rather than defining who is authorized to do what.

Gaps nobody has filled

• No project enforces policies across multiple cooperating agents or multi-agent pipelines: each controls a single agent process or a single code scan.
• No project provides human-readable explanations of why a specific verdict was reached. box records every policy decision as OTLP JSON and dogwood prints per-event verdicts during replay, but neither describes a mechanism for tracing a denial back through the rule logic for a non-technical reviewer.
• box supports macOS on Apple silicon with Linux listed as planned; no project covers Windows-native agent sandboxing.
• The Dogwood language and engine have no stated mechanism for distributing or versioning policies across a fleet of deployed agents.