An AI "migrated" my site — and left it publicly exposed to the world (#71882)

An AI coding agent was asked to migrate a site to a new location. It reported "migration complete." The content did move. But none of the original access policies came across, so a site that was meant to be private was left publicly readable by anyone — and the only signal was that the reporter happened to go look later.
This is a real, filed incident (anthropics/claude-code #71882), not a hypothetical. It generalizes to any agent-driven operation on a resource that carries access control: site migration, bucket copy, service-config clone.
The danger is the direction of the failure:

• When content migration fails, the page 404s. It fails loudly, so you notice.
• When access-control migration fails, the resource defaults to public. And the run still reports "success." It fails silently, and in the unsafe direction. That asymmetry is the whole bug. The word "complete" masks the exposure. In the filed report, errors: [] — nothing surfaced. Surfacing nothing is itself part of the bug. Until the tool itself carries access policies across, you can defend operator-side. One idea underneath all three: never mistake the absence of a check for the result of a check. Provision the destination private / deny-all first, move the content, and only then apply the verified policy set. If a policy is dropped, the resource fails closed (inaccessible — annoying) instead of open (a breach). Never let the migration step double as "flip it public." Before calling a migration of an access-controlled resource done, enumerate the effective policies / ACLs / visibility on both source and target and confirm they match. Not just that the content moved. If public access wasn't intended, end the migration by mechanically checking that the public endpoint returns 401/403 (or that the bucket/site ACL is not public). This turns an invisible failure into a loud one.

code=$(curl -s -o /dev/null -w '%{http_code}' "https://example.com/should-be-private")
[ "$code" = "401" ] || [ "$code" = "403" ] || echo "WARNING: possibly public — HTTP $code"

The risk isn't "migration" specifically — it's the pattern of treating a check that never ran as the result of a check. "deleted," "deployed," "uploaded," "migrated": for every irreversible, outward-facing verb, verify against the authoritative source (the live endpoint, the bucket ACL, the remote state) rather than the narrated "success."

• Confirm "it isn't public" from curl's status code before believing it.
• Don't let "already migrated / already deployed" become a team's working assumption without the one-line check first.

- Put irreversible, outward operations behind a gate that stops them before execution or verifies the real state immediately after.

This is exactly the kind of verified incident — detection → recovery → prevention, with the hook — that goes out monthly in the Agent Safety Brief: one incident a month free by email (Substack), or the full monthly digest of every failure that landed on the tracker that month, with paste-ready prevention for each, at $5/month (cancel anytime). A free sample issue is the complete public version of one paid month. Free hooks: cc-safe-setup.
The AI's "complete" is not evidence that a check ran. For anything that fails silently and in the public direction, default to closed and verify against the real thing.