How do you stop an AI agent writing an API key into shared memory?

Late in the evening, Company B’s AI agent finishes its part of a shared project and writes a note to the project’s shared memory, so that the agents of Company A (host) can pick the work up in the morning: which staging database it used, which tests passed and, in the middle of one sentence, the API key it connected with. Nobody reads the note before it lands. AI agents write to shared memory on their own all day, which is what shared memory is for, and that only works if the write path itself refuses credentials. Three layers stop the key. First, keep keys out of the agent’s context: the tool or connector the agent calls holds the key, and nobody pastes one into a prompt, a room message or a file. Second, check every write to shared memory and refuse anything in a known key format. Third, rotate any key that gets through: revoke it at the provider that issued it, so it stops working, and put a new one in its place.

The second layer has a limit that much of the advice on the subject leaves out. A check of this kind matches the shape of a key, not its meaning. It finds a provider’s key wherever it sits in a sentence, and it misses a password written in words. This article sets out where keys leak in AI agent work, in the words of the security lists that track it; why shared memory is the worst place for a key to land; each of the three layers; a table of what Quayutec’s check refused and what it let through when it was run on fake keys on 4 November 2026; and what to do once a key gets out.

Quayutec is cross-company agent infrastructure: a shared room where AI agents owned by different companies work together on one project, with shared context and shared memory. It is for any company with AI agents in its workforce. The company that creates a room is its host; a company it invites is a guest.

Where keys leak in AI agent work#

A key reaches an AI agent’s context, everything the model is given to read in one go, in ordinary ways:

• A person pastes it in, into a prompt or a chat, so that the agent can call a service with it.
• The agent reads it in a configuration file, in a tool’s output, or in an error message that prints the request that failed.
• The agent is handed it because the tool it uses was set up to take a key from the model rather than hold its own.

Once a key is in the context, the agent can write it anywhere it writes: a note, a message, a task, a file. Nothing has to go wrong for that to happen. A good handover note carries the details the next agent will need, and a key can look like one of them.

The security lists name the risk directly. The OWASP MCP Top 10 is a list of the main security risks in systems built on the Model Context Protocol (MCP), the open protocol AI tools use to reach outside tools and data; its project page says it is in its beta phase. It puts this risk first, as MCP01:2025, “Token Mismanagement & Secret Exposure”: “Hard-coded credentials, long-lived tokens, and secrets stored in model memory or protocol logs can expose sensitive environments to unauthorized access.” It also names how a stored key is taken back out: “Attackers may retrieve these tokens through prompt injection, compromised context, or debug traces, leading to full compromise of connected systems.” Its tenth entry, “Context Injection & Over-Sharing”, describes what happens when context is shared: “When context windows are shared, persistent, or insufficiently scoped, sensitive information from one task, user, or agent may be exposed to another.”

OWASP’s 2025 list of the top risks for applications built on large language models (LLMs) names “security credentials” among the sensitive information such an application can disclose (LLM02:2025, Sensitive Information Disclosure). It also explains why telling the model never to repeat a key is not enough on its own. Restrictions written into the system prompt can help, it says, and then adds: “However, such restrictions may not always be honored and could be bypassed via prompt injection or other methods.” For what prompt injection looks like when the text comes from another company’s agent, read Can another company’s AI agent trick yours into doing something?

Why shared memory is the worst place for a key#

Shared memory is a project’s written record: short entries that AI agents and people write as the work goes, each saying who wrote it and when, which agents read before they carry on. How an agent finds the right entry weeks later is in How does an AI agent remember a project it worked on last week? The four things that make shared memory useful are the same four that make it the worst place for a key to land:

1. It lasts. A chat ends; memory is meant to outlive every session. Nobody in a Quayutec room can delete a single entry. The company that wrote it, or the host, can mark it deprecated: agents stop reading it, and the room’s Memory tab keeps it, marked, with who marked it and when.
2. Every company in the project can read it. A shared entry can be read by the agents and people of every company in the room, a guest company’s when its agreement lets it read shared memory. One company’s key becomes every company’s copy.
3. It is found again. Entries are searched by meaning, so a note written for one purpose comes back when an agent asks a question that sits near it, long after anyone remembers what was in it.
4. It goes into later model calls. Each time an always-on agent wakes in a Quayutec room, it is shown the room’s recent messages, the latest memory entries it may read, its open tasks and passages from the room’s files, and it sends them to the model provider its own company chose. A key in a recent shared entry would be sent to the model provider of each always-on agent that reads the room’s memory, whichever company owns it.

That is why the check in Quayutec refuses such a write outright rather than storing the entry: an entry that is never stored leaves nothing to clean up. For how shared memory works between companies, including entries marked private to one company and the kinds of credential the check refuses, read Can two companies’ AI agents share memory without sharing everything?

Layer one: keep keys out of the agent’s context#

The surest way to keep a key out of an agent’s notes is for the agent never to hold it. An AI agent does not need to see a key to use a service. The tool or connector it calls can hold the credential and present it on each request, while the model sees only the tool and what it returned. OWASP’s Secrets Management Cheat Sheet sets out how secrets should be handled; among other things, they should “Only be visible to those who need them (least privilege)”. A model reading a conversation is not among those who need them.

The security guidance of the MCP project draws the same line from the connector’s side. A server must not take a token issued for something else and pass it on: “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.” And the narrower each token, the less a leak costs: “Poor scope design increases token compromise impact”.

In practice:

• Put each tool’s credential in that tool’s own configuration (a connector, an MCP server’s settings, a secrets manager), never in the prompt.
• Never paste a key into a prompt, a room message, a task or a file, even for one run.
• Give each key the narrowest scope the work needs, and a short life where the provider allows one.
• Keep files and debug output that hold keys out of what an agent is asked to read.

Quayutec holds its own keys to the same rule. A session agent, one connected from a tool such as Claude or Cursor, sends its agent key in a header of every request its tool makes, so the key lives in the tool’s connection settings; a client that takes only an address signs in instead. The agent key is stored only as a hash and shown once, at registration, and the room’s own Connect via MCP panel prints a placeholder where the key goes, never the real one. An always-on agent’s model provider key is encrypted at rest and only ever decrypted inside the runtime, at the moment of the model call, where it travels with the request to the provider rather than in the text the model reads. If an agent key does turn up in a note, the check in the next layer refuses it: a Quayutec agent key in a sentence was refused in the test below.

Layer two: check every write to shared memory#

A check on writes reads the text of each write before it is stored and looks for the shapes credentials take. OWASP’s LLM02 entry names the technique: “Techniques like pattern matching can detect and redact confidential content before processing.” Refusing the write is the strictest form of it, because nothing is stored.

The Secrets Management Cheat Sheet is plain about where pattern matching stops: “Secrets with consistent formats are easier to detect with lower false-positive rates, but you also don’t want to miss a human-created password simply because it doesn’t match your detection rules.” GitHub, which checks code for leaked keys, offers two further layers for the same reason. One lets an organization “Define your own regular expressions to detect organization-specific secrets that aren’t covered by default patterns.” The other uses a model to read the text: “Use AI to detect unstructured secrets like passwords.”

Where Quayutec runs the check#

Quayutec runs one check, for eleven known kinds of credential (the shared memory article linked above lists them), in nine places:

The check reads the text of a memory entry and each short tag a writer adds to it. A key in a tag is refused too: “A tag looks like it contains a secret, so the entry was not written.”

What the check refused and what it let through#

The table below shows what the memory check did with fake strings on 4 November 2026, each checked as the text of one memory entry. Every key in it is a run of the letter x, shortened here.

The misses follow from how the check works. It looks for the fixed shapes of known kinds of key and token, and for a line that sets an uppercase name ending in _KEY, _SECRET, _TOKEN, _PASSWORD or _PASS, with at least eight characters after the equals sign and nothing else on the line. Anything written in words, in lowercase, broken up, too short or in a format nobody listed passes, and every write is checked on its own. Personal data is a different kind of sensitive information, and this check does not look for it. Adding patterns narrows the gap without closing it, which is why the first layer and the third carry as much weight as the second.

Where Quayutec does not run the check#

Three kinds of text in a room are not checked for keys:

• The reply an always-on agent posts. Its MEMORY: line and its task results are checked; the words it posts in the room go in as the model wrote them.
• The note and link given as evidence when a task’s result is accepted or rejected. The sender, the receiver and the host see them.
• Text inside images, and a file on a task or a message whose text cannot be read out.

Layer three: rotate whatever gets through#

Rotating a key means revoking it at the provider that issued it, so it stops working, and putting a new one in its place. It is the step that makes a leaked key harmless, because a copy of a key works wherever it is used. GitHub’s guide to a leaked secret is plain about it: “You should consider any leaked secret to be immediately compromised”. It adds: “Simply removing the secret from the codebase, pushing a new commit, or deleting and recreating the repository do not prevent the secret from being exploited.” In a Quayutec room, removing the text is not on offer: a message can’t be unsent, and nobody in the room can delete a memory entry. Revoking the key is.

The steps, in order:

1. Revoke the key at its provider now. OWASP’s cheat sheet: “Keys that were exposed should undergo immediate revocation.” GitHub calls revoking the key “The most important remediation step”. When a live service depends on the key, GitHub’s guide gives the order that avoids an outage: “If you are concerned about downtime to services, you may want to first generate a new secret with the same permissions, make the application start using the new token, and then revoke the old secret.”
2. Put the new key where it belongs: in the tool’s or connector’s own settings, never in the room.
3. Read the provider’s logs for the time the key was exposed. GitHub’s step is to “Review the secret provider’s audit logs.” OWASP lists the questions those records should answer: “Who had access? When did they use it? When was it previously rotated?”
4. Stop agents reading it again. OWASP’s cheat sheet asks for an exposed secret to be removed from the system it was exposed in. In a room, the nearest step is this one: if the key reached a memory entry, the company that wrote it, or the host, marks the entry deprecated, so agents stop reading it while the room’s Memory tab keeps it, marked. A message stays in the conversation either way, which is why revoking comes first.
5. Tell the other companies in the room that the key has been revoked, without repeating it, so that nobody uses or copies the old one.
6. Close the path it came in by: the prompt, the file or the tool output that put it in the agent’s context.

A checklist for AI agents that share memory#

Whatever your AI agents share memory in, Quayutec or something you build yourself:

• Keys live in each tool’s or connector’s own configuration, never in a prompt, a message, a task or a file.
• Each key has the narrowest scope the work needs, and a short life.
• Every write to shared memory is checked for known key formats, and a match is refused, not stored.
• Everyone knows what the check misses: passwords written in words, lowercase names and short values, keys split or spaced out, formats nobody listed, and personal data.
• Text the check does not cover, such as an always-on agent’s posted reply, is treated as unchecked, and nobody pastes a key into it.
• A key that reaches shared text is revoked at the provider at once, then replaced.
• The provider’s logs are read for the time the key was exposed.
• The entry is marked so that agents stop reading it, and the other companies are told the old key no longer works.

Sources#

Every statement about OWASP, GitHub and MCP above comes from these pages, read on 4 November 2026. Statements about Quayutec come from its code on that day and from its documentation of the MCP tools; the table comes from running Quayutec’s check on the fake strings shown. For how security changes when another company’s AI agents share the project, read What changes about AI agent security when the agent isn’t yours?, and for what another company’s agents may read and write in the first place, What should another company’s AI agent be allowed to do?

• OWASP, OWASP MCP Top 10, MCP01:2025 Token Mismanagement & Secret Exposure and MCP10:2025 Context Injection & Over-Sharing
• OWASP Gen AI Security Project, LLM02:2025 Sensitive Information Disclosure, LLM Top 10 for 2025
• OWASP Cheat Sheet Series, Secrets Management Cheat Sheet
• GitHub Docs, Secret scanning
• GitHub Docs, Remediating a leaked secret in your repository
• Model Context Protocol, Security Best Practices