01 · Mental model
Connection, retrieval, and persistence fail differently
An MCP server can expose unexpected capabilities or return hostile content. Retrieval can surface poisoned, stale, or access-inappropriate passages. Tool results can contain injection payloads or malformed data. Memory can preserve a malicious or incorrect state long after the original input disappears.
Secure each boundary with identity, allowlists, provenance, schema validation, access-aware retrieval, content labelling, TTL and deletion rules, environment separation, and monitoring for capability or data changes.
02 · Visual explanation
03 · Compare and decide
Control the boundary that actually changed
| Decision lens | Primary threat | Control emphasis |
|---|---|---|
| MCP | Untrusted server or capability change | Server allowlist, versioning, consent, scoped transport |
| Tool output | Malformed or adversarial observation | Schema, size, content and destination validation |
| RAG | Poisoned or overshared evidence | Provenance, ACL filtering, freshness, citation |
| Memory | Persistent false or sensitive state | Typed fields, source, TTL, user control, deletion |
04 · Cybersecurity example
A poisoned runbook becomes durable memory
A retrieved runbook tells the agent to bypass an approval and the agent stores that as a future preference.
Retrieval marks source and trust level.
Policy blocks instruction-like content from becoming memory.
Memory accepts only typed, user-owned fields.
A security signal records the rejected persistence attempt.
Outcome: The attack is contained before it outlives the original retrieval event.
05 · What to remember
The 60-second recall
MCP is a protocol, not a trust decision.
Memory writes need stricter controls than temporary context.
Provenance and access filters must survive retrieval and handoff.
Teach-back prompt: Explain this concept to a teammate using the diagram, then name one failure mode and the control that stops it.
06 · Questions people ask
FAQ
07 · Primary sources