All Tokens Are Created Equal: CxBOM at [un]prompted II

To a model, a token from the attacker looks like a token from you. That is the claim in "All Tokens Are Created Equal, Including the Attacker's", a talk at [un]prompted II (also written "unprompted II"), the AI security practitioner conference in San Francisco on 27-29 October 2026. Our conference guide lists every session.

Rock Lambros (Zenity) and Fred Wilmot (Detecteam) speak on Day 1, Stage 2, at 09:35, per the official agenda as published on 2026-10-12. This is a preview written from the published abstract, before the talk. We are independent coverage, not the organiser, and we follow remotely. The agenda can change.

What the talk says it will show at [un]prompted II

The abstract uses the EchoLeak zero-click Copilot exploit to show that models do not distinguish trusted tokens from untrusted ones. The speakers measure attention decay under attacker flooding. They then release CxBOM, a bill of materials for the context window, with a live demo. The abstract does not give the schema or the measurements, so we quote none.

Why this is the hard part

A software bill of materials lists what went into a build. A bill of materials for the context window would list what went into a prompt: the system text, the user's request, retrieved documents, tool output, memory. Each entry would say where it came from. We think the idea is sound, and it follows a familiar pattern in supply-chain risk in agentic pipelines. These points are our analysis.

The hard part is that the context window is a flat sequence. The model has no field that marks one token as trusted. A record outside the window can describe the origin of each span, but the model still reads them all the same way. The record helps a defender, a monitor or a human after the fact. It does not by itself make the model resist. That limit is why attention decay matters: if a flood of attacker text pushes the trusted instructions out of the model's effective focus, the record tells you who flooded it, not whether the model obeyed.

Another Day 3 talk is a useful sibling. On Day 3, Stage 2, at 10:00, Aishwarya Athreya (Visa) and Kavia Venkatesh (Cigna) present the open Pipeline Bill of Materials specification, which records a build's execution context. Both talks bring the bill-of-materials idea to a new object. The glossary entry in our unprompted glossary defines the terms used here.

The abstract's use of EchoLeak as a worked example matters for a defender, because a real exploit gives the schema something concrete to be tested against. A bill of materials answers the first question an investigator asks afterwards, which is which spans were in the window when the action happened. We think a talk that starts from a real exploit and ends with a released artefact is the right shape for this audience. The risk is the usual one with any new inventory: it goes stale, nobody reads it, and it becomes a compliance file. We will check whether the release is designed to be consumed by a machine in real time.

What we will be watching for

• The schema: which fields each entry carries, and which are required.
• Whether the demo shows CxBOM built live from a real agent run, or from a prepared one.
• How attention decay is measured, and over what range of flood sizes.
• Whether the talk shows a defender decision that CxBOM changes, such as blocking a tool call.
• Whether the release comes with a specification or only a tool.

If this holds, what changes on Monday

Our inferences, conditional on the talk. Start recording the origin of every span that enters a prompt, even in a plain log. Mark tool output and retrieved text as untrusted by default. Use the record in incident work: our guide to audit log evidence requirements lists what an investigator will want. Treat the record as evidence, not as a control.

Three questions for Rock Lambros and Fred Wilmot

These are the questions we would ask. The page stands without any reply.

1. What is the minimum useful CxBOM schema, and which field would you remove last?
2. Does provenance survive summarisation and tool output, or is it lost when text is rewritten?
3. What does attention decay mean operationally: a point at which a defender should treat a context as compromised?