How does the authorization layer stay outside the poisoned path?

The containment result (Can memory poisoning compromise decision-making even with authorization layers?) depends on the authorization layer sitting outside whatever the attack reached. The excerpt supplies two phrases for that layer: "task-bound signed tokens" and "a separately verified policy oracle." It supplies no design behind them.

What is left open.

• Issuance. Who issues a token, and when? If issuance depends on a Supervisor that reads the same memory the attack poisons, the token inherits the poison. If it is issued before retrieval from the user's request, it does not.
• Binding. What "task-bound" binds to: the user's request text, a task identifier, or a Supervisor's restatement of the task. Each has a different exposure.
• Verification. What "separately verified" means for the oracle: verified by whom, against what, and whether the oracle's policy can be written to by any agent in the pipeline.
• Reach. Whether the tested attacks were positioned to touch any of these at all. The paper's two attacks poison shared memory and a retrieved document, both upstream of the Validator. The 0 percent is evidence about an attacker at that position. An attacker positioned at token issuance or the policy is a different experiment, and the excerpt reports none. Where the attacker stands is the first coordinate in Can adversary position unify fragmented multi-agent attack models?, and where the layer sits relative to that position is the trust-boundary part of Can multi-agent defenses close attack paths completely?. The SoK excerpt names neither the positions nor a definition of the slot, so both mappings are the vault's.

The pattern in the vault. The same question recurs wherever a guardrail is called independent. Can optimizers learn to evade guardrails through repeated verdicts? asks what the guarded party can see, and How reusable is BenchShield if task bindings require per-task work? asks who writes a binding. What would make policy violations truly unavailable to an agent? puts the general form: availability is relative to what the policy can see and write, and whether the enforcing component lies outside both. The black-box excerpts leave the condition open twice for an evidence layer, for the capture point (Can a black box see communication through unauthorized channels?) and for who may anchor (What can a blockchain anchor actually prove about records?). Those are also the vault's pairings, and the black-box paper is a position paper with no attack tested against it.

The same condition in a benchmark and in a self-editing loop. Two more notes leave it open, both as vault pairings with settings that involve no authorization layer. Can runtime instrumentation distinguish hacking exposure from actual exploitation? rests a benchmark's validity claims on infrastructure-side records without saying whether the recorder is out of the agent's reach, and the recorder there stands where the token issuer and the oracle's policy stand here. What exactly does hidden mean in AIDE2's evaluation system? does not say whether the guard against untrustworthy wins sits inside the code the agent may rewrite or in the harness that scores it, which is the reach question with the rewriting agent in the attacker's place. And Can a correct scoring function still mislead about task performance? gives the general form for the issuance and binding items above: a check can be correct and still attest to the wrong thing if what it reads was shaped upstream, so a validly signed token would still mislead if the poisoned path shaped what it was issued for. That note argues this for scores and reports no authorization layer, and this excerpt reports no attack on the layer.

What would move the answer. The paper's threat model and its token and oracle design, or an attack conducted against the authorization layer itself. A result of 0 percent under an attacker who can reach the layer would be a different and stronger claim.