The Gate Was Reading the Memory's Own Lie. Here's What I Built Instead.

In the last article, ANP2 left a comment I couldn't stop thinking about:

"If it reads the resource off the retrieved memory, you've quietly reintroduced self-description — a mislabeled item will mislabel its own resource too, and the gate inherits the lie."

The memory lied. The gate inherited the lie. The action fired.

That was the failure mode in one sentence. Here's the test.

What the old gate trusted

The previous execution gate checked fields authored by the retrieved memory itself — governs.action_types, resource_sensitivity, allowed_action_hint. If a mislabeled memory carried resource_sensitivity: "ordinary_fact" and allowed_action_hint: "answer", the gate read those labels, found nothing alarming, and passed the action through.

The lie didn't need to be sophisticated. It just needed to be in the right fields.

The fix: read from the operation

The architectural shift is one sentence: derive the authorization class from what the agent is about to do, not from what the retrieved memory claims to govern.

def operation_context_gate(query, memory, pre_gate_action):
    sensitive, action_class, resource_class = is_sensitive_operation(query)
    if sensitive:
        return (
            "GATE_FAIL",
            f"op_action={action_class} op_resource={resource_class}",
            "verify_first",
            "op_context_gate",
        )
    result, note, action = execution_gate(memory, pre_gate_action)
    return result, note, action, "memory_self_description"

I used verify_first as the rescue action because the gate can detect insufficient authority, but it does not yet decide whether the operation should be fully blocked.

One caveat worth naming: is_sensitive_operation infers the resource and action class from the natural-language query. That is still imperfect. A stronger gate would inspect the proposed tool call, target resource, action type, and recipient directly — not the query describing it. This version is a bridge toward operation-derived authority, not the final form.

The test: three intentionally mislabeled memories

Five scenarios designed to isolate the gap:

• 3 mislabeled: target memory carries resource_sensitivity: "ordinary_fact" and allowed_action_hint: "answer" — but the operation is execute + sensitive resource (wire transfer, API key distribution, PII export to an external partner)
• 1 clean sensitive: correctly labeled — both gates should refuse (baseline)
• 1 safe read: both gates should pass (control)

The numbers

Metric	Self-description gate	Operation-context gate
Action correct	2/5	5/5
False certainty (expected risky, said permissive)	3	0
Risky cases refused	0/3	3/3
Target selected AND refused (oc_earned_by_op_context)	—	2/3
Lucky refusal (refused, target not selected)	—	1/3
Gap exposed (SD pass, OC fail)	—	3

The distinction between the last two rows matters. In 2 of the 3 mislabeled refusals, retrieval surfaced the exact sensitive memory AND the operation-context gate refused it — that's the gate earning the result. In the third, retrieval missed the target; the gate still refused because the operation was sensitive. Correct outcome, different causal path. oc_earned_by_op_context tracks the difference so a passing run proves the gate worked, not that the ranker got lucky.

The honest cost

On the clean baseline (fresh-Claude v0.4 top-5):

	SD	OC
Action correct	5/5	3/5
False certainty	0	0

Two scenarios expected block, got verify_first. Not false certainty — the gate never said "safe" when "risky" was expected. But it downgraded two well-labeled block decisions. The operation-context gate is stricter on all sensitive operations, including correctly labeled ones. That tradeoff is documented in the claim ledger. Not hidden.

What this doesn't close

The gate catches mislabeled memories at execution time. It doesn't touch write-time.

A commenter asked the harder question directly: What does your attribution trace use as ground truth for authorization at store time? Caller identity, namespace position, or something external to the memory layer entirely?

Honest answer: right now, stored metadata is still the ground truth. The storing agent claims its own authority at write time. A poisoned write still enters the store — the operation-context gate can refuse at execution, but can't verify what was stored or by whom.

Write-time authorization is the next open layer. The storing agent's identity and namespace position need to become the first gate. A task-abc.executor claiming authority over payment operations should fail before the item reaches the store. That's not built yet.

The practical rule

Do not let a memory object be the only witness for its own authority.

The pattern

Every step in this series moved because external pressure forced it. The self-description gap wasn't in the original design — ANP2 named it in the comments. The attribution refinement wasn't in the first version of this eval — a second commenter pushed on it the same session.

The research is better because the comments pushed back. That's the point.

Code: https://github.com/keniel13-ui/ai-memory-judgment-demo