Agent memory is getting a new shape.
Not one chat summary at the end of a session. Not a manual "remember this" button. A stream.
Google's Memory Bank IngestEvents API is now generally available. The important bit is not the product name. It is the pattern: teams can continuously stream content into an agent memory system, then trigger memory generation later based on thresholds like event count or idle time.
That is useful.
It is also a trust boundary.
Short answer: continuous memory ingestion needs source receipts before generated memories become trusted context. Every durable memory should keep the event IDs, raw source pointers, scope, trigger window, extraction path, trust label, allowed influence, expiry, and reviewer state that produced it. If the agent cannot show those receipts, the memory should not steer future tool use, approvals, data handling, or external communication.
The new memory boundary
Traditional memory controls focus on a single write.
The agent sees a message. It proposes a memory. A human or policy gate approves it.
Continuous ingestion is different. Events accumulate before generation. The memory system may deduplicate overlapping history, hold events in isolated streams, and flush a batch only when the trigger conditions are met. Google's docs describe streams as isolated buffers keyed by scope and stream ID. They also describe automatic triggers and a 24-hour flush for pending events when no trigger fires.
That means the security question changes.
The question is no longer only, "Should this sentence become memory?"
The question is, "Which events, from which sources, in which stream, under which trigger, became this memory item, and what is it allowed to influence later?"
If that record disappears, memory becomes laundering.
Untrusted content goes in as raw event data. A generated memory comes out looking clean. Later, another agent reads it as context and no longer sees the source, the threat model, or the conflict it came from.
That is the gap source receipts should close.
What the evidence says
This is not a theoretical concern.
OWASP Agent Memory Guard frames persistent agent memory as mutable runtime state. It calls out goals, user context, conversation history, and permissions as memory-like data that can be tampered with through prompt injection, context manipulation, and identity hijacking. Its control set points in the right direction: policy checks on memory reads and writes, integrity checks, snapshots, forensic analysis, and rollback.
The research literature is moving in the same direction.
From Untrusted Input to Trusted Memory identifies four memory write channels and nine structural vulnerabilities in agent memory systems. The useful finding for builders is blunt: agents that write and retrieve memory more aggressively are more exploitable, and existing prompt-injection defenses do not automatically cover memory poisoning.
Hidden in Memory studies sleeper memory poisoning, where adversarial external content causes an assistant to store a fabricated user memory. The attack can stay dormant and reappear in later conversations after the original malicious context is gone.
When Agents Remember Too Much focuses on tool-using personal agents with email, calendar, and code access. Its GhostWriter attack has an injection phase and a later activation phase, which is exactly why memory receipts need to survive past the ingest window.
Memory Poisoning Attack and Defense on Memory-Based LLM Agents is useful because it does not treat memory trust as a binary switch. It evaluates trust scoring, trust-aware retrieval, temporal decay, and pattern-based filtering in an EHR-agent setting. The domain is narrow, but the control shape matters.
MemAudit adds a post-hoc lesson. If a poisoned memory later causes harm, defenders need to identify which stored memories contributed to the bad output. That is much easier if generated memories carry source receipts from the start.
What a source receipt is
Keep reading with free field-guide resources.
VibeSec Advisory publishes practical research, Skills, workflow examples, MCP notes, prompt injection tests, and AI red-team lessons for builders working with agentic AI.
A source receipt is the record that lets a reviewer trace a generated memory back to the evidence and policy path that produced it.
It should be attached before the memory enters trusted retrieval.
At minimum, the receipt should include:
| Field | What to keep | Why it matters |
|---|---|---|
| Event IDs | Stable IDs for every ingested event used in generation | Keeps deduplication auditable |
| Raw source pointer | URL, document ID, ticket ID, transcript span, email ID, file path, or trace ID | Lets a reviewer inspect the original context |
| Scope and stream | User, project, session, tenant, and stream ID | Prevents cross-scope memory bleed |
| Trigger window | Count, idle-time, manual, scheduled, or fallback flush | Explains why generation happened then |
| Extractor identity | Model, prompt, tool, version, and config | Makes drift visible |
| Generated memory | The normalized memory item | Separates source evidence from derived claim |
| Trust label | User-provided, external, internal, agent-derived, unverified, conflict, or approved | Stops clean prose from implying trusted status |
| Allowed influence | Tone, retrieval, planning, tool choice, approvals, data handling, external messages, or none | Keeps memory from gaining hidden authority |
| Expiry | Session, task, date, project, or manual review | Limits stale persistence |
| Rollback pointer | Snapshot, version, delete path, and audit event | Makes recovery real |
The most important field is allowed influence.
A remembered preference can shape tone. It should not shape tool permissions.
A project fact can help retrieval. It should not approve a vendor, override a data policy, or tell an agent that a human already signed off.
Continuous ingestion makes this more important because a generated memory may blend several events. One trustworthy event and one hostile event can produce one polished sentence. The receipt is how you keep that sentence from pretending it has one clean origin.
The pre-generation gate
Source receipts are not only a logging feature.
They belong before generation too.
For every memory generation window, run a small gate:
- Source inventory: list event IDs, sources, scopes, and trust labels.
- Conflict check: flag disagreement between sources before consolidation.
- Sensitive-data check: block credentials, regulated data, secrets, and unnecessary personal data from durable memory.
- Instruction check: separate facts from instructions, approvals, exceptions, and tool-use guidance.
- Authority check: confirm whether the source is allowed to create that kind of memory.
- Allowed-influence assignment: set what the memory may affect later.
- Expiry and rollback: attach a default TTL and a concrete delete or restore path.
If a generated memory cannot pass those checks, store it as pending or discard it.
Do not let it become hidden context.
Red-team the stream, not just the output
Most memory tests still look at the next answer.
That misses the point.
For continuous ingest, test the stream:
- Put hostile instructions in one event and benign context in the next five. Confirm batching does not wash the hostile event into a trusted memory.
- Reuse event IDs and overlapping history. Confirm deduplication does not hide the source trail.
- Mix a real project fact with a fake approval. Confirm the generated memory preserves the distinction.
- Trigger generation through idle time instead of an explicit write. Confirm the same policy gate runs.
- Delete a poisoned event. Confirm every generated memory that depended on it is marked stale, removed, or regenerated.
- Retrieve the memory in a later task with tool access. Confirm the trust label and allowed influence still appear in the prompt or policy layer.
The test is not whether the model can summarize a stream.
The test is whether untrusted stream content can become trusted memory without leaving receipts.
How this differs from memory quarantine
Memory quarantine is still the right control for single writes. I covered that in Quarantine Memory Writes Before Agents Trust Memory.
Source receipts are the batch version.
They answer a slightly different question:
- Quarantine asks whether one proposed memory can be trusted.
- Source receipts ask whether a generated memory can prove where it came from.
Teams need both.
Quarantine keeps bad memory from becoming durable. Receipts keep generated memory from losing provenance after batching, deduplication, summarization, and retrieval.
Pair this with Treat Tool Results as Agent Input, Agent Memory Is a Data Boundary, and Shadow-Mode Traces Before Agent Write Access. The pattern is the same: every agent input that can change future behavior needs origin, authority, and rollback.
The practical control
For a small team, start with one workflow that writes memory from a continuous stream.
Add a pending memory table with these columns:
- Generated memory
- Event IDs
- Raw source pointer
- Scope
- Trigger window
- Trust label
- Allowed influence
- Expiry
- Reviewer
- Rollback pointer
Then set one rule:
No receipt, no trusted memory.
The memory can sit in pending state. It can help a reviewer. It can be regenerated. It can be deleted.
It cannot steer future tool use, approvals, sensitive-data decisions, or external messages until it can show where it came from and what it is allowed to influence.
That is the control continuous memory needs.
Browse the VibeSec Advisory Skill Library for more free agentic AI security patterns.