Memory Guard is the MMW server’s protective layer that every record passes through before it is saved. It has two jobs: reject attempts to poison an agent’s memory, and scrub secrets.
On this page you will learn:
- which records are rejected outright and what the agent sees;
- which secrets are replaced with placeholders and what a placeholder looks like;
- where else the same rules apply.
Rejection: protection against memory poisoning
Section titled “Rejection: protection against memory poisoning”Agents read memory, so a record can become a way to plant instructions for future sessions. Memory Guard rejects record text that looks like such an attempt:
- requests to ignore previous instructions or prior context;
- attempts to override the system prompt;
- instructions to exfiltrate data to an external address;
- instructions to send passwords, secrets or tokens somewhere.
Empty records are rejected as well.
What the agent sees is an error from the remember tool:
Memory rejected by Security Guard: Memory poisoning detected: matching pattern '…'The record is not saved. If you genuinely need to record such an event (“the task contained a prompt injection attempt”), describe it in your own words without quoting the malicious phrase.
Secret scrubbing
Section titled “Secret scrubbing”A secret in a record does not cause a rejection: the record is saved, but the secret itself is replaced with a placeholder. Every persisted field is checked: content, source, source_id, source_hash, source_revision, fact_key.
What is recognized, by category:
| Category | Examples |
|---|---|
| Private keys | PEM blocks, PuTTY keys, including truncated ones |
| Connection strings | The password in database URIs and in user:password@host addresses — only the password is masked |
| Authorization headers | Authorization: Bearer …, Basic … |
| LLM provider keys | OpenAI, Anthropic, Groq, xAI, Hugging Face, Replicate and similar |
| Developer platforms | GitHub, GitLab, Atlassian, npm and PyPI tokens |
| Cloud | AWS, Google Cloud, Azure, DigitalOcean, HashiCorp Vault and others |
| Messaging | Slack, Telegram bots, SendGrid, Twilio |
| Payments and SaaS | Stripe, Shopify, Linear, Notion |
| MMW keys | Keys in the mmw_… format |
| Signed tokens | JWT |
| Assignments | password=…, API_KEY: … and similar secret-name/value pairs |
A placeholder looks like this:
[REDACTED:<rule>:<8-character hash>]Example. The agent tries to save:
Test database: postgres://app:<password>@db.internal:5432/appWhat ends up in memory:
Test database: postgres://app:[REDACTED:db_uri_password:5f1e9c02]@db.internal:5432/apprememberreplies as usual — the agent gets no error;- in
search, the agent sees the text with the placeholder; - the hash is the first 8 characters of the value’s SHA-256: it shows whether two records contained the same secret, but the secret cannot be recovered from it;
- the operation log records only which rules fired and how many times — no values, no hashes.
To reduce false positives, values that look like code or identifiers (such as config.api_key or a variable name), obvious placeholders in example URLs, and already-scrubbed text are left alone.
Where else these rules apply
Section titled “Where else these rules apply”- mmw-agent on your machine — the same copy of the rules scrubs session history before upload. A test checks that the agent’s rules match the server’s. See Session history.
- The server when receiving session history — every chunk is scrubbed again.
- The Telegram bot — notes are saved through the same
remember. - The archivist — its reply is scrubbed before it can end up in a
fact_key.