Security patterns for agent memory

Your agent has persistent memory now. It can store facts, preferences, corrections, project context. The question nobody asks until it's too late: what should it actually be remembering?

I've seen agents store API keys in memory. I've seen plaintext passwords. One user's agent was helpfully storing their database connection strings, complete with credentials, as "important project context." The agent wasn't wrong about relevance. It was very wrong about what belongs in a memory service.

Here's the short version: treat agent memory like a notebook you might leave at a coffee shop. Write down preferences, decisions, and context. Don't write down your bank password.

The no-secrets rule

This one is absolute. Never store:

• API keys or tokens
• Passwords or passphrases
• Private keys (crypto or SSH)
• Session tokens or JWTs
• Database connection strings with credentials
• OAuth client secrets

MemoClaw encrypts data at rest and in transit, but that's not the point. Memory is designed to be recalled — by your agent, potentially across sessions, possibly across multiple agents sharing the same wallet. Secrets in memory become secrets your agent might surface in a response, quote in a log, or reference in a way you didn't anticipate.

If your agent needs to use an API key, it should read it from environment variables or a secrets manager. The memory should store that the key exists and where to find it:

# Bad
memoclaw store "OpenAI API key: sk-abc123..." --importance 0.9

# Good  
memoclaw store "OpenAI API key is stored in OPENAI_API_KEY env variable in ~/.bashrc" --importance 0.7 --tags references

Store the reference, not the value. This pattern works for everything sensitive.

PII: it depends

Personally identifiable information is more nuanced. Your agent storing "Ana prefers direct communication and hates status update meetings" is fine. That's a working preference. Your agent storing "Ana's SSN is 123-45-6789" is not fine.

The line: store behavioral information and preferences. Don't store identity documents, financial account numbers, health records, or anything that would be a problem in a data breach.

For contact information, store what the agent actually needs. "Ana's timezone is GMT-3" is useful for scheduling. "Ana's home address is 123 Main St" probably isn't needed for an AI agent to function.

When in doubt, ask: if someone got access to this wallet's memory pool, would this fact cause harm? If yes, don't store it.

Wallet-based auth: what it means for you

MemoClaw uses Ethereum wallets for identity. No usernames, no passwords, no API keys to rotate. Your wallet address is your account, and your private key signs requests.

This has a security benefit that's easy to miss: there's no credential to leak on the MemoClaw side. No database of user passwords that could get breached. No API key that a compromised third-party could use. The authentication is cryptographic, tied to a key that only exists on your machine.

The tradeoff: your private key is your identity. If someone gets your private key, they can read and write to your entire memory pool. Protect it the way you'd protect any crypto wallet key — environment variables with proper permissions, never hardcoded in config files that get committed to git.

# Good: key in environment
export MEMOCLAW_PRIVATE_KEY=0x...
memoclaw-mcp --private-key $MEMOCLAW_PRIVATE_KEY

# Bad: key in committed config
# Don't put this in a file that goes to version control

Store references, not data

This is the general pattern for anything sensitive. Instead of storing the thing itself, store how to find it.

# Instead of storing the actual config:
memoclaw store "Production database: PostgreSQL on Neon, connection in NEON_DATABASE_URL env var. Schema has 12 tables, main ones are users, memories, embeddings." --importance 0.7

# Instead of storing credentials:
memoclaw store "AWS credentials configured via aws configure, profile name is memoclaw-prod. Region is us-east-1." --importance 0.6

Your agent gets the context it needs (which database, which AWS profile, which region) without the memory pool becoming a credential store.

Namespaces as security boundaries

Namespaces aren't just organizational. They're a way to control what context your agent accesses.

If you're building a project that handles user data, put that project's memories in its own namespace. Your agent working on a different project won't accidentally recall specifics about user data from the first one.

memoclaw store "Client X prefers weekly reports via email" \
  --namespace client-x --importance 0.7

memoclaw store "Internal API rate limit is 1000 req/min" \
  --namespace internal --importance 0.6

When your agent recalls in the internal namespace, client-specific information stays invisible. It's not access control in the IAM sense, but it prevents accidental cross-contamination, which is the more common failure mode.

Auditing what your agent stored

MemoClaw's list and export endpoints are free — no API calls deducted from your tier. Use them.

# See everything your agent has stored
memoclaw list --private-key $MEMOCLAW_PRIVATE_KEY

# Filter by namespace
memoclaw list --namespace work --private-key $MEMOCLAW_PRIVATE_KEY

# Search for potential problems
memoclaw recall "password key token secret" --private-key $MEMOCLAW_PRIVATE_KEY

That last command is worth running periodically. Semantic search means it'll catch memories that mention credentials even if they don't use those exact words. If something sensitive shows up, delete it:

memoclaw delete mem_abc123 --private-key $MEMOCLAW_PRIVATE_KEY

Memory expiration

If you're storing time-sensitive information, consider how long it should persist. A project deadline that passed six months ago is clutter. A correction about your coding preferences might be relevant forever.

MemoClaw supports expiration through the API. For memories that have a clear shelf life, set it:

curl -X POST https://api.memoclaw.com/v1/store \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Sprint deadline is March 20, 2026",
    "importance": 0.8,
    "metadata": { "tags": ["deadlines"] },
    "expires_at": "2026-03-21T00:00:00Z"
  }'

After expiration, the memory stops appearing in recalls. Less stale context, better results.

The checklist

Run through this before your agent goes into production:

Never store:

• [ ] API keys, tokens, or secrets of any kind
• [ ] Passwords or passphrases
• [ ] Private keys (crypto, SSH, GPG)
• [ ] Social security numbers, government IDs
• [ ] Financial account numbers
• [ ] Health records or medical information

Always do:

• [ ] Store references to secrets, not the secrets themselves
• [ ] Keep your wallet private key in environment variables, not config files
• [ ] Use namespaces to separate project contexts
• [ ] Audit stored memories periodically with memoclaw list
• [ ] Run memoclaw recall "password key token secret" to catch mistakes
• [ ] Set expiration on time-sensitive memories
• [ ] Review what your agent stores during the first few sessions

Consider carefully:

• [ ] Contact information (store only what the agent actually needs)
• [ ] User preferences that could identify someone in context
• [ ] Project details that include client-specific information

The mindset

Agent memory is a tool for context, not a database for everything your agent encounters. The best agents store less, not more. A focused memory pool with 50 high-quality memories beats 500 that include sensitive data, stale facts, and things the agent never needs to recall.

Store decisions. Store corrections. Store preferences and working context. Keep secrets where they belong — in environment variables and secrets managers, not in your agent's head.

---

MemoClaw docs: docs.memoclaw.com. Free list and export endpoints for auditing are available at any time.