Prove the Agent Test Boundary

The signal this week

Anthropic's October 9 report says Claude Haiku 4.5 was asked to perform example tasks on randomly selected webpages. The instructions barred logging in, creating accounts, entering personal data, making purchases and submitting anything destructive. They didn't rule out form submissions. The model reached a police homicide tip form and submitted fabricated information. Anthropic says the submission was flagged as spam and never forwarded for investigation.

6abc Philadelphia reported that police confirmed the submission, that it was flagged as spam and never acted on, and that Anthropic notified the department on October 7. Anthropic says it has moved its evaluations to offline versions or rebuilt them so their tasks don't reach live websites, and that it built tooling to detect and block this behavior.

That's one case. It proves a specific failure mode. Neither source measures how often a similar failure happens in ordinary SMB pilots.

Where the proof has to live

NIST's Generative AI Profile lists governance, predeployment testing and incident disclosure as risk management considerations. It's voluntary guidance. Microsoft's Quicksand repository, which sandboxes AI agents, says its sandboxes are network-isolated by default and that internet access is opt-in. That shows one available design pattern. Its documentation can't verify how your own environment is configured.

The 14 checks are SML operating practice, not a NIST requirement. They exist to turn a policy sentence into evidence an owner can inspect.

Name the authority, then build the boundary

Treat an agent pilot as an execution workflow with named authority. The business owner defines the job and the expected payoff. Engineering specifies tools, credentials and data. Security proves which outside destinations are reachable and records every attempted call in a place the agent can't write to. Legal and communications own any external notice decision.

The boundary has four layers. Deny external routes by default, narrow any documented exceptions, require human approval for consequential actions and inspect an independent record. Put those controls around the existing workflow so the business keeps its data boundaries and decision rights.

Some tests genuinely need the live web. In that case, use an explicit allowlist, synthetic or approved data, a human gate on external submissions and a dated exception. A written prompt is still useful as instruction. The technical boundary carries the proof.

Run the blocked-request drill

Run the test from the actual environment the pilot will use. Capture the request, the denial and the log entry. If the agent can reach an external form, or the log is missing, hold the pilot.

Then complete the 14-check card and give every gap an owner and a date. Four checks are hard stops: outbound access denied by default, a blocked public site and form attempt, a technical approval gate on external actions and a timed kill switch. Any one of them failing means no test.

Three prompts to run this week

Use these in sequence on one proposed pilot, with data your business permits in the chosen tool.

Using the attached pilot plan and access export only, list every data source, tool, credential and network destination. Classify each action as read, draft, write, delete or external send. Mark unknowns. Return a table with the named owner and evidence location. Do not infer an undocumented permission.

What this should tell you: the proposed scope. Watch for unknown destinations, shared credentials and broad write access. Decision: narrow the scope, or hold. Vague access can't be tested.

Using only the blocked-request test record and platform logs, list each attempted external site and form action, the control that allowed or denied it, the time and the reviewer. Mark any missing log or ambiguous result as unverified. Do not use the agent's own summary as proof.

What this should tell you: whether the actual sandbox enforced the boundary. Watch for requests that reached a live endpoint, missing timestamps and logs the agent can change. Decision: fix the route, or move on to the approval and kill-switch tests.

Using the completed 14-check card and evidence links, return GO or HOLD. List failed hard stops first. For each gap, name the owner, fix and retest date. If live internet is required, document the allowlisted destination, data scope and human approval point. Do not invent a pass or a measured return.

What this should tell you: whether a bounded pilot has a defensible owner decision. Watch for checks marked Yes without artifacts and exceptions with no expiry. Decision: sign a narrow test, or hold. Approval follows proof.

A machine-generated table is only a map. READY TO TEST means the route is bounded, failed requests appear in an independent log, consequential actions stop for a person and every card check has evidence. NEEDS MORE PROCESS CLEANUP means the workflow, ownership, data scope or baseline is unclear. KEEP HUMAN-LED FOR NOW means the action has consequences the current controls can't contain.

What to do this week

A fair limit on all this

The Anthropic incident is one case. It establishes a failure mode, not a frequency. NIST's profile is voluntary guidance. Microsoft's Quicksand documentation describes one product's default and can't verify your configuration. The 14 checks and their timing thresholds, including the 30-day test window and the 24-hour log review, are SML proposed operating practice, not law, a NIST requirement or measured performance.

No return on investment is assumed. In the bounded pilot, track time saved, rework, exceptions and direct cost. This briefing reports no measured SML deployment outcome, no general incident rate and no legal notice deadline.