Trust travels on the author field.
In a substrate memory graph, openness to many writers is also an attack surface: a write can influence every later reasoning step that reads it, whether or not the write is honest. Provenance and trust from authorship names the design property that resists this by binding trust to who authored an entry rather than to what the entry claims.
The distinction matters because content is cheap to fake and identity is not. A forged citation or a fabricated decision reads the same as a real one to a model scanning for a plausible-sounding claim. A legitimate author record, an entry correctly stamped as written by the identity that actually wrote it, is a harder thing to counterfeit.
A named, cross-vendor problem.
Memory poisoning moved from a theoretical concern to a named, documented attack surface across 2026, with incidents reported against agent memory systems from multiple vendors, including Gemini, Microsoft Azure, and Amazon Bedrock.
| Source | What it documents |
|---|---|
| OWASP ASI06 | The 2026 Agentic AI Top 10 added memory and context poisoning as its own category, naming persistent-state attacks as a distinct surface not covered by earlier LLM-focused controls. |
| MINJA | A memory-injection attack that plants poisoned entries through ordinary query-only interaction, reported with injection success rates above 95% under its benchmark conditions. |
| AgentPoison | A backdoor-style attack against retrieval-augmented agents, reported with at least 80% attack success at under 0.1% poison rate and under 1% impact on benign behavior, requiring no retraining of the underlying model. |
| MemoryTrap | A disclosed incident affecting Claude Code's own memory, showing a single poisoned memory object propagating across sessions, users, and subagents. |
These figures describe vulnerabilities documented in other systems, not a benchmark of Vinculum's own defenses against these specific attacks. They establish why an authorship-based design constraint is a reasonable response to a current attack surface, distinct from a claim of immunity to it.
Detect and sanitize.
ASI06 prescribes five defense layers, most of them applied after a write has already landed:
Two of the five, memory sanitization with provenance and trust-aware retrieval, already treat authorship as part of the answer. The remaining three are monitoring and detection: they look for poisoning after it has entered the store, rather than making a false identity structurally harder to write into the store in the first place.
Make the identity hard to fake, not just the content plausible.
The Vinculum Standard states this as one of its epistemic guarantees: “Trust is derived from who wrote an entry, not from what the text claims. A poisoned entry can forge a citation; it cannot forge the identity that authored it. Trust travels on the author field.”
Rather than scanning written content for signs it might be false, the guarantee is placed on a separate field that content does not touch. A write can still contain a false statement; it cannot silently reassign who is on record as having written it.
Author, and its cross-instance reach.
In the Standard, author is a MUST field on every entry: who or what wrote it, a human or a model identity. Content is never validated against it; the field simply records which identity is on record for a given entry, and that record does not change after the fact.
The project's federation specification extends the same constraint across trust boundaries. Where entries are exchanged between separate Vinculum instances, the design specifies authenticated encryption, pairing X25519 with XSalsa20-Poly1305, chosen specifically because it authenticates the sender as part of the same primitive that provides confidentiality. An alternative, age encryption, was considered and set aside for this purpose because it deliberately does not authenticate the sender, which the design treats as a requirement rather than an optional extra. Peer instances are pinned on first contact rather than re-verified from claims made at exchange time.
A bounded claim, not immunity.
None of this makes a system immune to memory poisoning. A written entry can still make a false claim, cite a source that does not say what it is claimed to say, or reach a wrong conclusion from real premises. Provenance does not check any of that content for truth.
What it bounds is narrower and more mechanical: forging the identity on record for an entry is a different, and harder, problem than forging the entry's content. The Standard groups this guarantee alongside two others, kept contradictions and reasoning traces, as the three properties that move a memory store past plain storage.
Common questions.
Is provenance the same as authentication?
Authentication verifies who is making a request at the moment it is made. Provenance is the persistent record of who authored an entry, carried with that entry afterward, including in later sessions where the original author is no longer present to reauthenticate.
Does this stop prompt injection?
No. Provenance addresses a different problem: it makes the record of who wrote a memory entry hard to forge. Prompt injection targets what a model does with content already in its context, a separate attack class that authorship provenance does not address on its own.
Is this immunity to memory poisoning?
No. An authored entry can still contain a false claim. Provenance narrows the harder-to-fake dimension to authorship: an attacker can write something untrue, but not easily write it under someone else's identity.