How to keep an AI agent's memory secure
Treat an agent's memory like a shared database that an untrusted program can write to, because it is one. Secure it with four controls: a person approves writes that others will rely on, credentials are refused at the door, every call is recorded in a tamper-evident log, and each agent gets the least access it needs and can be revoked on its own.
Morphika builds those controls into the memory itself, so they hold no matter which agent is connected.
About Morphika: Morphika is secure, shared memory for personal AI agents like Claude Code, Codex and Claude Desktop. How it is secured.
What can go wrong with agent memory?
| Risk | What happens |
|---|---|
| Memory poisoning (prompt injection) | Text the agent reads, such as a web page, an email or a README, tells it to save a false fact or an instruction. Every later session trusts it. |
| Secrets in memory | An agent saves an API key or password it saw, and later repeats it to another tool or person. |
| Silent or unattributed changes | A memory changes and nobody can tell which agent changed it, when, or who allowed it. |
| Over-broad access | An agent that only needs to look things up can also write, approve or read the logs. |
| Cross-context leaks | A poisoned entry persuades an agent to copy a team's memory into a personal context, or the other way round. |
| Long-lived keys | A static API key in a config file is copied, committed or leaked, and works until someone notices. |
How does Morphika handle each risk?
| Risk | Morphika's control |
|---|---|
| Memory poisoning in shared memory | A write to a workspace waits for another member to approve it. Nobody can approve their own request, and a request left undecided expires after one hour. |
| Secrets in memory | A save whose content looks like a credential or financial detail is refused before it is stored or queued for approval, and only the type of finding is logged, never the value. Secrets and personal details are masked in what Morphika returns to an agent. |
| Silent changes | Every call (allowed, denied, pending or failed) is written to a SHA-256 hash-chained audit log. You can re-check the chain with audit_verify or Verify now in the dashboard. |
| Over-broad access | An agent that should only read connects to https://mcp.morphika.ai/read/mcp and gets 7 recall tools: it can read, search and list memory, entry history, the profile and uploaded documents, but never write, forget or delete. Approvals, the audit log and connection management are never on that address. |
| Cross-context leaks | The workspace is chosen by the connection URL, never by a tool argument, so nothing an agent reads can redirect it into another workspace. |
| Long-lived keys | There are no API keys. Agents sign in through the browser with OAuth 2.1 and PKCE; access tokens last one hour, and you can revoke any single agent from the dashboard. A revoked connection is refused immediately and permanently. |
Why does shared memory need a human approval step?
Because an agent cannot reliably tell a real instruction from an injected one. Filters catch some attacks; a person reading “this agent wants to save X to the team's memory” catches the rest. The approval request shows who asked, which tool and the entry it would change.
On the Morphika iPhone app the notification carries only an id. The details load after you unlock the app, and every approve or deny needs Face ID. You can also decide from the web dashboard.
What about personal memory?
Personal memory saves straight away, without approval, because you are its only owner and the approval would be yours. That is a deliberate trade-off. The safeguards there are the credential scan, the audit log (which shows every write and which agent made it) and the read-only address for agents that handle untrusted content.
Rule of thumb: an agent that browses the web or reads other people's documents should connect read-only. Give write access to the agents you drive yourself.
What does a hash-chained audit log prove?
Each log entry includes a SHA-256 hash of the entry before it, so editing or deleting any past entry breaks every link after it. Verifying the chain proves the recorded history of calls was not altered after the fact. Call arguments and results are stored as hashes, not as raw content; a few descriptive fields are kept as text, such as the name of the memory entry a call targeted and any note an approver adds.
It does not stop a bad write by itself; it makes one visible and attributable. Attribution details such as the client name are stored beside the chain, not inside it.
A checklist for any agent memory
- Can you see every entry, and which agent wrote it?
- Does anything a group relies on need a person's approval before it changes?
- Is there a tamper-evident log, and can you verify it yourself?
- Are credentials refused rather than stored?
- Can you give an agent read-only access?
- Can you revoke one agent without affecting the others?
- Is your data used to train models? Can you delete it yourself?
Morphika's answers are on the security page, and what is collected and who processes it is in the Privacy Policy.
Related guides
Published September 25, 2026 · Last updated