Keeping secrets out of AI project memory

Keeping secrets out of AI project memory means treating every note, task record, handoff and prompt as text that will be copied, committed and sent to a model provider, and writing it accordingly. Project memory is built to travel. A task note is read into a prompt, so it goes to the provider. A handoff is pasted into another tool. Findings are committed and pushed. Logs are attached to bug reports. A token that lands in any of these is now in several places you do not control, and deleting the note later does not recall the copies. The safe habit is simple to state: refer to secrets by name, never by value, and scan before anything leaves your machine. This workflow lists what to keep out, shows where leaks usually start, gives redaction habits that survive a busy day and ends with a packaging scan as a worked example. Broader questions of what runs locally and what goes to providers are in local AI agent workflows.

Where secrets slip into agent memory

Few people type a password into a task note on purpose. Secrets arrive by accident, usually through one of these routes.

Pasted error output. A failed HTTP call logs the full request, including an Authorization header or a URL with a key in the query string. You paste the error into the chat or the findings section to ask for help.

Environment dumps. An agent runs a command that prints environment variables or a config file while debugging, and the output ends up in its summary or its handoff.

Connection strings. A database URL with an embedded password is copied into a note as 'the dev database'.

Example data. Real customer records are used as a test fixture or quoted in a finding about a bug.

Handoffs written in a hurry. The note says 'use this token to reproduce' because it was the fastest way to unblock the next session.

Screenshots and attachments. An image of a dashboard shows an account number or an API key.

Each route has the same shape: a debugging moment, a copy and paste, and a record built to be reused. Handoff notes and per-task records are both exposed, precisely because they work.

What never goes into notes, cards or prompts

Write this list into your project's contributor notes so agents and people see the same rules.

Credentials of any kind: API keys, access tokens, passwords, session cookies, OAuth client secrets, signing keys and private keys, including expired ones, since expiry is easy to get wrong.

Connection strings with embedded credentials. Record the host name pattern and the variable name, not the URL.

The contents of .env files and secret stores, even partially. A partial key still narrows the search for an attacker and still trips scanners.

Personal data about real people: customer names, emails, addresses, account numbers. Use synthetic fixtures with obviously fake values.

Internal details that map your infrastructure, such as private host names, internal IP addresses and full local paths that reveal user names, unless the record is truly internal and never sent to a provider.

What to write instead: the name of the variable and where it is set. 'Uses PAYMENTS_API_KEY from the local environment; ask the owner for access.' That sentence is enough for an agent to work, and harmless if it leaks.

Instruct agents explicitly: never print secret values in output, and redact them when quoting logs.

Redaction and review habits that hold up

Rules fail under time pressure, so make the safe path the easy one.

Redact at the source. Configure your HTTP client and logger to mask Authorization headers and known secret fields. Then pasted logs are safe by default.

Redact before pasting. When you must quote output, replace values with a marker such as REDACTED and keep the variable name, so the reader still knows what was there.

Scan before commit. Run a secret scanner as a pre-commit hook over code and notes alike. Task records and handoffs live in the repository too, so they deserve the same check as source files.

Review handoffs before saving. A ten-second read for anything that looks like a key, a long random string or a real person's details catches most accidents.

Use a read-only session for log analysis. When an agent needs to look at sensitive output, prefer a session that cannot write or push, and keep its summary free of values.

If a secret does get in, rotate it. Deleting the note does not remove it from version-control history, from copies in other tools or from data already sent to a provider. Rotation is the only reliable fix; cleanup is secondary.

Scan before anything leaves: a packaging example

The same discipline applies to anything you ship, including tools you build with agents. Before the BRAIN FLUID v1.8.5 package was staged, it was scanned for owner names, local paths, host names and key markers.

The scan covered 5,468 archive members, including archives nested inside the package. It searched in both UTF-8 and UTF-16, because Windows tools often write UTF-16 and a UTF-8-only search can miss a name sitting in plain view. File names were scanned as well as contents, since a path can leak a user name even when every file is clean. The result was zero first-party hits [C9].

Third-party dependencies sometimes contain strings that match a pattern innocently. Those were allowed only as exact exceptions recording the file, the term and the file's hash, so an exception cannot quietly cover a different file or a later change.

The lessons carry over to project memory: scan everything that will travel, in every encoding your tools produce, including names and nested containers; keep exceptions narrow and pinned to content; and rerun the scan whenever the content changes. A scan you ran last month says nothing about the handoff you wrote today, which is the same point made in stale AI project memory.

QUESTIONS

Is it safe to paste error logs into an AI coding agent?

Only after checking them. Error output often contains request headers, URLs with keys, connection strings or personal data. Mask those values first, or configure your logger to mask them automatically. Remember that whatever you paste is sent to the model provider and may also end up in notes the agent writes.

What should I do if I pasted an API key into an AI chat?

Rotate the key immediately, then remove it from any notes, commits or handoffs where it was copied. Deleting the message alone is not enough, because the text has already been sent to the provider and may exist in history or other tools. Check access logs for unexpected use.

How can an AI agent use a secret without seeing its value?

Keep the value in an environment variable or secret store and give the agent only the variable's name. Code reads the value at run time, so the agent can write and run it without the value appearing in prompts, notes or output. Tell the agent never to print the variable.

RELATED GUIDES

• What is a project management harness?
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• local AI agent workflow A local AI agent workflow keeps project records and agent runs on your own computer. Here is what that gives you and what it costs.
• How to hand off an AI coding session How to hand off an AI coding session: a short end-of-session routine so the next agent or person can continue without guessing.
• Per-task Markdown memory Per-task Markdown memory: one short record per unit of work, with outcome, scope, criteria, findings and next step, instead of one global notes file.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.