If a fake approval slips past the checker, does a signature check or a rules check actually stop the damage?
How do forged approvals fail differently at token versus policy checks?
This explores what happens when a compromised validator forges an approval, and whether the signed-token check and the policy check stop it in different ways. The corpus only partly answers this.
This explores how a forged approval gets stopped by a token check versus a policy check. The corpus can't yet tell you which check does what. The one study that has both, a four-agent pipeline with an authorization layer, only compares both checks on against both off, and the single-component ablation that would split them isn't in the available text Which authorization component achieves the zero percent unsafe rate?. What it does show is still interesting.
With authorization off, a validator reading poisoned shared memory forges approvals in every trial, and unsafe actions execute every time Can a poisoned validator still approve unsafe actions?. With authorization on, the validator is still fooled in every trial, but no unsafe action runs Can memory poisoning compromise decision-making even with authorization layers?. So the forgery doesn't fail at the moment it is made. The bad approval still gets produced. It fails afterward, because the layer stops treating the validator's judgment as authority. The layer blocks execution without repairing the compromised judgment.
The layer has two parts, task-bound signed tokens and a separately verified policy oracle, but the excerpt doesn't say who issues the tokens, what they bind to, how verification works, or whether the attacks could reach these components How does the authorization layer stay outside the poisoned path?. The natural guess is that the token check asks whether an approval is authentic and tied to this task. The policy check asks whether the action is allowed at all, whoever signed off. Under that reading a forged approval fails at the token for lacking a valid signature or binding, and at the policy for requesting something forbidden. This is an inference, not a finding. A related study has the same gap: it bundles clear authorization rules with restricted tools and can't say which one prevented test tampering Do authorization rules or restricted tools prevent test modifications?. There, naming a prohibition wasn't enough. The boundary had to specify the protected state itself and be paired with restricted tools Can explicit authorization boundaries prevent agents from modifying protected tests?.
Two neighbouring ideas suggest why the checks might fail differently. In honeytoken research, any rule that lets trusted agents avoid a decoy becomes a roadmap for an attacker who knows it Can honeytokens fool attackers who know the trusted policy?. A policy rule an attacker can learn may be satisfiable by that attacker. A token check that relies on something the poisoned path never holds might not be. On the policy side, work on auto-generating formal verifiers, including Lean and z3 checkers, from prose policy documents points toward policy checks that run as code rather than as another model's opinion Can we automatically generate formal verifiers from policy text?. Neither idea has been tested against forged approvals in this corpus.
The takeaway is that the safety came from a check outside the poisoned path, not from a better judge. Whether the token, the policy, or their combination carries that safety is still an open question in this collection.