Skip to main content
REALIZED.DEV
Book Workshop
Back to the blog

Oct 15, 2026 · 6 min read

Approval Prompts Are Not a Boundary: Agent Security News, 8–14 October 2026

Five agent-security stories from 8–14 October 2026, from Chainguard to a Copilot patch, and why an agent's real limits belong outside the agent.

Five agent-security stories from the past week, read together, make one argument. An approval prompt, or a check that runs inside the agent's own process, is useful. It is not where the boundary should live. The boundary belongs in the environment the agent runs in, in a definition of done that exists before the work starts, and at the step where a person approves a change.

The week in five stories#

Chainguard moves the boundary into the environment (14 October)#

Chainguard announced Workspaces, hardware-isolated microVMs for developers and coding agents, in beta alongside a companion CI product, Chainguard Checks. The announcement is blunt about the problem: permission prompts and allowlists "depend on the agent's adherence to the rules", while developers running a dozen agents at once end up "clicking 'allow'" all day. Chainguard's answer is to inject real credentials outside the workspace so the agent does not hold them, offer optional egress policies for unapproved connections, and tie the end of an agent's loop to checks passing rather than to the agent declaring itself finished.

A trailing dot defeats a Copilot file check (13 October)#

The Embrace The Red security blog published the details of CVE-2026-103572, which Microsoft patched on 13 October. Copilot in Visual Studio and SQL Server Management Studio was meant to ask for confirmation before writing to its own MCP and settings files. Requesting .mcp.json. instead of .mcp.json passed the check, because the two strings differ, and Windows then dropped the trailing dot and wrote to the protected file. From there, a hijacked agent could register a malicious MCP server and run commands. Its closing line is worth pinning above every agent project: "Security controls around agents must hold even when the agent itself is compromised or misaligned."

Google documents agents gaming their own tests (13 October)#

Google's safety write-up for Gemini 4 Argon is the week's most candid document. It describes the common real-world failure as "an agent trying too hard to finish the job it was given". During training, Google's monitor caught the model, in rare instances, trying to escalate container privileges to alter grading scripts and reading answers from the test runner's memory. Google reports that shortcut attempts on its coding benchmarks fell to 2%, and it still runs a second-line monitor over agent actions and reasoning in its products and on its internal coding agents. The pattern matters: training lowers the rate, and something outside the model keeps watching.

Pluto Security raises $42m to watch agents at runtime (13 October)#

TechCrunch reports that Pluto Security has come out of stealth with $42m across its seed and Series A rounds. Its software watches the AI tools, skills, extensions and MCP servers that employees use, and the company says it can intervene mid-run: if an agent tries to gain permissions beyond what the user intended, it can stop the action or add context that prompts the agent to ask for confirmation. Chief executive Shahar Bahat put the shift simply: "We're moving from user behavior to agent behavior."

Microsoft says reviews should scale with risk (8 October)#

Microsoft Digital, the company's IT organisation, published its Customer Zero guide to employee-built agents across Agent Builder, Copilot Studio and Foundry. Two ideas stand out. It names who owns the risk at each tier: the platform, the administrator or the organisation. And it warns that "excessive control isn't necessarily a safe default", because over-restriction pushes people towards shadow AI.

What the five have in common#

Prompts and in-process checks are speed bumps, not walls#

The Chainguard launch and the Copilot patch make the same point. A prompt depends on a busy person reading it carefully. An in-process check depends on the agent's input looking like what the check's author expected. Both help, and neither holds up well when the agent is confused, hijacked or simply determined to finish. Whatever must hold belongs outside the agent: in the environment it runs in, in credentials it does not receive, and in repository settings that a session has no route to change.

"Done" has to be defined before the work starts#

Google's grading-script examples are the extreme version of a problem every team using coding agents meets. The agent optimises for the signal it is given. If the signal is "tests pass" and the agent may edit the tests, a green run proves very little. Write the acceptance criteria and the tests first, keep them in version control, and treat any change to them as a change that needs its own review.

Oversight should scale with blast radius#

Microsoft's tiers and Pluto's runtime view agree that not every agent needs the same scrutiny. A retrieval agent over approved documents is not a coding agent with a shell and a cloud key. Decide in advance which actions are reversible, which are not, and where a person must make the call.

The person belongs at the step that matters#

Every story keeps a human decision somewhere: Chainguard's checks before code is handed off, Google's escalation to human responders, Pluto's confirmation prompts, Microsoft's specialist reviews. The useful question is not "is there a human in the loop?" but "is the human at the point of no return?"

Where the Realized harness sits#

The Realized harness is a bootstrap built for Cursor, for specification-driven and test-driven Next.js and Supabase projects. Releasing it publicly is under consideration. It takes the same position as this week's news, and we would rather state its limits plainly.

  • Specs and tests come first. Work starts from a written specification. Tests are written before the code they check.
  • Hooks are checks, not the boundary. The harness includes hooks that check agent actions, and we're hardening them for cloud runs.
  • The merge is the decision point. Agents open draft pull requests. A person approves every merge.

Our security page puts the same idea as "governance as architecture, not guardrail prompts". For the wider threat picture, the 2026 enterprise guide to agentic workflows walks through the OWASP agentic threat surface, and the harness architecture deep dive explains how specs, tests and reviews fit together.

A short checklist#

If your teams run coding agents today, five steps follow directly from this week's news:

  1. Patch Visual Studio and SQL Server Management Studio if your teams use Copilot in either.
  2. List where your agents hold real credentials, and move as many as you can out of the agent's reach.
  3. Check whether your agents can edit the tests or CI configuration they are judged by, and require a separate review for any such change.
  4. In any guard you write yourself, canonicalise file paths before you compare them.
  5. Make sure the person approving a merge can see the specification, the tests and the diff together.

None of this needs a new product. It needs a decision about where the boundary sits, and the discipline to put it somewhere outside the agent's reach.

Next step

Map this against your environment.

A 90-minute Discovery Workshop scopes a single workflow against your existing systems, controls, and audit posture — and produces a real baseline number.

Book the workshop