# Evolution 18 — research and closest prior art

Method and limits: `research_manifest.json` lists every source, how it was checked (fetched from this host on
2026-10-12) and the exact statement relied on. Five entries of the inherited manifest were removed because the citation
did not exist, pointed to an unrelated paper, or could not be reached. No patent search was done. Where a statement
below comes from general knowledge rather than a page that was read, it says so.

## What each kind of statement establishes

| Statement | Who makes it | What it establishes | What it does not |
|---|---|---|---|
| agent-reported intent | the agent / the tool call | what was asked for | that it was allowed, or done |
| authorization | approver key | that this exact effect set, on these exact objects, was allowed until a time | that anything ran |
| enforcement decision | enforcer key | that the enforcer admitted or refused | that the executor did only what was admitted |
| executor claim | the executor | nothing beyond "it says so" (`SELF_REPORTED`) | the effect |
| enforcer's own measurement | enforcer process | state of the declared objects before and after (`INSTRUMENTED`) | anything it did not look at; anything if the enforcer is the liar |
| observation | a sensor process with its own key | what that method could see in its scope in the window | what the method cannot see; anything outside scope; truth if the kernel or a same-user debugger interferes |
| signed receipt | enforcer key | that the enforcer assembled these records | that they are true |
| verified claim | a verifier that trusts none of the above code | that the records are intact, linked, and support the claim at a stated level | ground truth |
| ground truth | nobody | — | not available from software on the same host |

## Closest prior art, by mechanism

**Observing file effects from outside the acting process.** File-integrity monitors (Tripwire/AIDE, general
knowledge) compare snapshots; inotify (S01) and fanotify (S02) deliver kernel events; Falco (S17) and Tetragon (S16)
observe, and Tetragon can enforce, from eBPF programs in the kernel. Evolution 18's sensors are the weakest of these:
unprivileged, same user, same kernel. What they add is that each is a separate process with its own key whose signed
statement is bound to one authorized action, and that two methods with *different* blind spots are compared. The
inotify man page's statement that mmap writes are not reported (S01) is reproduced by corpus scenario CX-02, where it
surfaces as a contradiction between the two sensors instead of as silent agreement.

**eBPF as an observer.** Not used. It would move the sensor's failure boundary out of user space, which is what
"independent" should mean on one host; it needs CAP_BPF/root and this environment forbids kernel changes. An in-kernel
observer is still not independent of a compromised kernel. (An earlier evolution's notes in this repository already
record that its eBPF tracepoint is telemetry, not enforcement.)

**Binding an action to an object, not a path.** The standard defence against check/use path races is to resolve once
and act through a descriptor: `openat`-family calls, `O_NOFOLLOW`, and since Linux 5.6 `openat2` with
`RESOLVE_BENEATH` / `RESOLVE_NO_SYMLINKS` (S03, S04). Evolution 18's pinning walk is that technique. What is added
around it: the *approver* signs the object identity (device, inode, size, content digest, parent directory) next to
the effect digest, and the last check before the mutating call re-reads revocation and expiry.

**Provenance graphs.** W3C PROV (S08) defines typed relations among entities, activities and agents; in-toto (S09) and
SLSA (S10) define signed statements about steps and say that who generated a provenance statement decides how far to
trust it. The Evolution 18 graph is a small model of the same kind. Its two specific rules are: every node states
whether its source signed it or the recorder merely wrote it down, and only causal relations make a causal path — a
`TEMPORAL` or `CORRELATES` edge never does (Lamport, S07: order consistent with causality comes from logical clocks,
not from timestamps).

**Appraisal by someone other than the claimant.** RATS (S11) separates attester, verifier and relying party, with the
verifier appraising evidence against reference values it holds. The clean-room verifier is that role: it re-derives
the level and the verdict from the signed records and is given the sensor keys by the reader, not by the receipt.
Unlike RATS attesters, the sensors have no hardware root.

**Transparency.** Certificate Transparency (S12) and SCITT (S13) make equivocation visible to third parties through
append-only logs. Evolution 18 has no log: a verifier detects a replayed receipt or a second execution of one
authorization only among receipts *it* has seen.

**Agent tracing.** OpenTelemetry's GenAI conventions (S14) name `execute_tool` / `invoke_agent` operations and
`gen_ai.tool.call.id`. They are produced by the instrumented process. They are useful for correlating a receipt with a
trace (carry `task_id` and `auth_id` as attributes) and are evidence at `SELF_REPORTED` or `INSTRUMENTED` level at
most. Not implemented in this evolution; recorded as a mapping only.

**Agent security work.** Indirect prompt injection (S18) is the reason an executor's report is not evidence. AgentDojo
(S19) is the reference for measuring attack success and benign utility separately; the corpus here follows that
separation at a much smaller scale and without a model in the loop. CaMeL (S20) and AgentSpec (S21) bind or enforce
before execution; neither observes effects afterwards.

**Privacy of evidence.** Not researched to a usable depth and not addressed in code. Receipts carry absolute paths and
content digests, and WRITE authorizations carry the content itself in the effect material. See
`limitations_and_open_risks.md`.

## Is the thesis true?

*Can CAIN-42 link an authorized canonical action to independently observed effects and say when observation is
incomplete or possibly compromised?* For file effects under one directory on one host: yes, to the level the sensors
support, and the code says which level. For network, process and memory effects: no method exists here and the verdict
is `UNSUPPORTED`. "Possibly compromised" is detectable only as disagreement between sensors or between a receipt and
the sensor keys a reader anchors; a deception both sensors share (the kernel) is not detectable.