Restore into a different Cloudflare account
Most restores put data back where it came from. Two kinds do not necessarily: a Cloudflare config restore and a media restore both write through the Cloudflare API to an account id you supply, rather than to a binding that is already fixed to one account.
That makes a specific mistake possible. Supply the wrong account id, or an id that has drifted since you saved it, and the write lands in the wrong Cloudflare account. It would succeed, because nothing about the request is malformed; it would simply have written your configuration somewhere it does not belong. This is a confused-deputy problem, and the engine guards it.
How the engine knows where the archive came from
Each archive records the account it was captured from, and that origin is signed. It is stamped at seal time by the source adapter itself and pinned by the archive root’s per-shard hash, so a request cannot claim a different origin: the value is not something the caller supplies alongside the target.
That is what makes the comparison meaningful. The engine is not checking your target against another thing you told it; it is checking your target against what the archive itself attests.
What you see, and when
The check runs on the dry run, before anything is written. If the target account you supplied is not provably the archive’s origin, the plan comes back carrying a cross-account warning for each affected leg, naming the leg, the archive’s origin account and the target you gave.
The apply is then refused until you confirm the difference by typing the target account id back. Not a checkbox: you have to reproduce the id, so confirming is an act of reading it. Get the id wrong in the confirmation and the apply stays refused.
On an ordinary same-account restore none of this appears. There is no warning to dismiss and nothing extra to type, so the friction lands only where the risk is.
An archive with no recorded origin is treated as cross-account
If the archive recorded no origin account, the engine does not treat that as “probably fine”. An unverifiable origin is treated as cross-account, so it raises the warning and requires the same typed confirmation.
That is the important asymmetry. The guard cannot be defeated by an archive that simply lacks the information, which is exactly the case where a silent write to an unverified account would otherwise be possible.
When you actually want this
Restoring into a different account is a legitimate operation, and the guard is not trying to stop you. It is worth doing deliberately for a recovery into a rebuilt account after losing the original, a migration between accounts, or standing an isolated copy up for a rehearsal so a drill never touches production.
In each of those the difference is the point, and the typed confirmation is cheap. What the guard prevents is the fourth case: the one where you believed you were restoring into the origin account and were not.
Where this fits
- What restore can and cannot write back covers which legs write through the Cloudflare API at all, which is what makes them account-targeted.
- The restore flow covers the dry run this check runs inside.
- Dual control for restores is a separate gate: it binds an approval to the plan hash, and a cross-account plan needs both the approval and the typed confirmation.
- Granular and targeted restores covers narrowing what a plan touches, which is worth doing before a cross-account apply rather than after.
Last updated .