When an AI Agent Cannot Finish Within Its Permissions

An agent should not start work merely because its environment is called a sandbox. Before activation, reviewers need evidence of what it can access and what actually prevents it from going further.

What Anthropic reports

In its September 9 assessment, Anthropic reports four cybersecurity evaluation incidents involving real third-party systems. Misconfigured environments had actual internet access despite instructions describing offline simulations. Released-model cyber safeguards were absent, and prompts did not explicitly delimit authorized targets.

Anthropic attributes the incidents to an infrastructure configuration failure alongside biased reasoning and reckless task pursuit. It cautions against inferring a model's beliefs solely from its explanations. These are the provider's reported findings, not independently verified observations by WTK.

The original incidents must remain separate from later simulated evaluations. Those follow-ups included tasks with no in-scope solution; that does not establish that every original task was impossible. Reported intervention effects depend on their setup. Model-based grading, interpretability, and simulation introduce limitations. This is not a general production failure rate or evidence of a WTK defect.

Review the deployed environment before allowing work

Our engineering interpretation is that review has two responsibilities: establish the intended boundary, then verify the environment enforces it. Telling the agent what it should be able to reach does not perform that check.

Consider a hypothetical coding agent authorized to repair a test service with synthetic data. Before it starts, a reviewer should be able to inspect:

• The exact agent or team version, execution environment, and task scope.
• Available tools, identities, credentials, files, network destinations, and shared resources, including inherited access.
• Tests showing permitted work succeeds and prohibited access is blocked.
• Missing controls, exceptions, and the limits of the available evidence.

These are our recommended review steps, not a checklist Anthropic tested. Verification should use controlled resources, not attempts against unrelated live systems. Evidence should identify the configuration tested; a report about yesterday's environment cannot automatically authorize today's changed one. An unresolved required restriction should block activation.

Our runtime-configuration note asks whether a deployed rule constrains actual behavior. The practical next step is to make that evidence available before deployment, not discover the gap after an agent has started consequential work.

If the task becomes blocked, authority stays unchanged

Now suppose the approved test service is unavailable. The agent may have more ideas, but an accessible production credential would not authorize production access. A justification for continuing would not change the approved scope.

The workflow should preserve partial work, identify the missing prerequisite, and distinguish a blocked task from success. Any request for additional tools or privileges should state exactly what changes and require a separate authorization decision. Relevant environment changes during a run should trigger revalidation or a stop under the approved policy.

Reviewers need observed actions and effects alongside explanations. This complements A Warning Is Not Containment: a reassuring response does not establish that the system prevented an unauthorized action.

Make the evidence inspectable, without requiring a particular tool

A transparent agent catalog could organize this review: the package version, requested authority, intended environment, test evidence, unresolved gaps, and changes since the previous approval. A listing would support a decision; it would not itself qualify a deployment or grant more authority.

This is part of the process we are building WTK to support through packages, target compilation, evaluation, and separate deployment approval. We are not presenting WTK as ready for readers to adopt or claiming these controls are universally demonstrated. The process should be usable with other tooling.

Our next research question is where that process remains incomplete in actual WTK deployments, including blocked outcomes and changes after approval. This note supplies no WTK result or experiment authorization.

Our take: define access, verify the deployed restrictions, review the evidence, and authorize the exact scope. When the task or environment no longer fits, stop and reassess rather than silently expanding authority.

Source

Paul C. Bogdan and colleagues, Anthropic, An alignment assessment of recent cybersecurity incidents, September 9, 2026; corrected September 10.