Answers
Can an AI agent's memory leak my API keys, and how do I keep secrets out?
Yes, it can, because anything you paste into a session may end up in what the agent remembers. In an interview published by Help Net Security on 28 September 2026, Chris Latimer, CEO of Vectorize, says developers send API keys, credentials and sensitive documents to coding agents, that much of it ends up in long-term memory, and that he has found it in plain text on developer workstations, in cloud memory services and in markdown files. A fifteen-minute check is enough to start: find where each AI tool you use keeps memory, search those places for key prefixes, passwords, private-key headers and addresses that carry a user and password, rotate whatever you find, because deleting a note does not revoke the key, and from then on keep keys in a secret manager and give the AI only the name of the variable. Arroway adds one gate at the point of writing: when an assistant tries to record something shaped like a credential, the write is refused, the value is not repeated, and the assistant is told to use a reference instead. The detector is a heuristic and does not scan what other tools keep. The install page is the first step.
Last updated October 15, 2026
The fifteen-minute check
First, list where each tool you use keeps memory: the folder, the file, the cloud service. The documentation of each tool says; Claude Code's, for example, describes a folder under your home directory for each project. Second, search those places for what a credential looks like: well-known key prefixes, the words password, secret and token followed by a value, private-key headers, and web addresses with a user and password inside them. Third, rotate every credential you find, because the note is only one of the places where it was exposed. Fourth, agree on one rule for the team: keys live in a secret manager, and an AI is given the name of the variable, never the value. Fifth, find out who can read memory that several people share.
Why shared memory raises the stakes
A note in one person's folder exposes one machine. Memory that a team shares, or that a plugin or an MCP server can read, exposes everyone who reads it, and the interview describes a malicious plugin that scans memory for keys and sends them out. The risk grows with the number of places memory is written, so the useful control is at the point of writing: do not store a credential, store where to find it. That control is imperfect, and a secret that was never written anywhere cannot be read by anyone, which is why the fourth line of the check matters more than any scanner.
When to use Arroway
Use Arroway when assistants write to a memory several people and tools read. A write that contains a private key, a bearer token, a JSON web token, a web address with credentials, a value with a well-known key prefix, a named password or a long high-entropy string is refused before it is stored, and the answer tells the assistant to put the credential in a secret manager and call again with a reference. The value is not echoed back. This is a screen on what is written to Arroway: it does not scan the memory of your other tools, and a secret in an unusual shape can pass a heuristic. The rule that keys never go in is the stronger one, and the install page is the first step.
What it looks like in practice
A developer asks an assistant to remember how the project connects to the payment provider, and pastes the connection details, including the live API key, into the chat. In a memory with no gate, the note is saved as written. Next week a teammate's session reads it, and so does a plugin the teammate installed that day. The key is now in a note, a transcript and a plugin's reach. In Arroway the write is refused, the key is not repeated in the answer, and the assistant is told to ask for a reference. The developer puts the key in the secret manager and the note says the connection uses the variable named PAYMENT_API_KEY and where it is configured. The developer also rotates the key, because the chat already held it. The developer and the project are illustrative; nothing here was measured on a real team.
Questions people ask about this
- Does Arroway scan the memory of my other AI tools?
- No. It screens what is written to Arroway. What Claude Code, ChatGPT, Cursor or any other tool keeps on its own is outside it, which is why the check starts with finding where each of them keeps memory.
- Can the screen miss a secret?
- Yes. It recognizes private keys, bearer tokens, JSON web tokens, web addresses with credentials, named passwords, well-known key prefixes and long random-looking strings. A credential in a form it does not recognize can pass, so the rule that keys stay in the secret manager still applies.
- How do I try Arroway?
- Install it in the tool you already use — the install page has one route for Claude, ChatGPT, Codex, Cursor or any MCP tool — and sign in when the tool asks. From then on, sessions open by reading the project and close by recording what was decided.
Where this is verifiable
The Help Net Security interview with Chris Latimer of Vectorize, "If you do one security check this quarter, make it agent memory", published on 28 September 2026 (helpnetsecurity.com/2026/09/28/chris-latimer-vectorize-agent-memory-security), and the memory page of the Claude Code documentation (code.claude.com/docs/en/memory), both read on 15 October 2026 — the interview is reported only as it states it on that date and the tools as their documentation describes them, and both can change. Product documentation on this site (How it works, Install), the answer on write policy for shared memory, and the product's own screening of credential-shaped values at the moment of writing. Everything described here about Arroway is behaviour the tools apply today, not roadmap. The developer in the example is illustrative.
https://www.arroway.app/en/answers/keeping-secrets-out-of-shared-ai-memory