Secrets Stay Out of Context

Everything the agent reads becomes part of a request to a model, and with a hosted model that request leaves your machine. A key it reads by accident is a key you sent to a third party, wrote into a session log on your disk, and may find hard-coded in the next diff. The fix is not telling the agent where not to look. It is arranging the working tree so that there is nothing secret to find.

This chapter covers only what is new because an agent sits in the loop. Secret stores, scanning and rotation as general practice belong to CyberSecurity Deep Dive, and this page assumes them. What changes with an agent is the number of ways a secret can be read without anyone deciding to read it, and the number of places it goes once it has been.

Where Context Goes

One secret that enters a session can end up in five places. It goes to the provider's servers with every turn that includes it, because the whole context is sent each time, as Chapter 4 described. It may stay in the provider's retention and abuse-monitoring logs for whatever period the plan's terms allow, which is a team policy question for Chapter 13. It sits in the session transcript, which agents commonly keep on your disk so a session can be resumed. It travels with any transcript you share with a colleague. And it can end up in the code itself, if the agent decides to reuse it. Deleting it from one of those places does not reach the others.

Four Ways a Secret Gets In

Reading is the first. The environment file is ignored by git but present on disk, and the ignore file is git's rule, not the agent's. Whatever an agent's search tools skip by default, a plain request to "open the config and check the database settings" usually reads the file by name. Pasting is the second. Kai pastes a stack trace from staging into the session, and the trace contains the staging database connection string, password included. Running is the third. The agent runs a command that prints the environment, or a verbose test that echoes request headers, including the payment provider's key. Committing is the fourth: a key left in a configuration file, or written into the project instructions file as "the test key to use", where every session reads it on start-up.

Notice that none of the four needs a mistake by the agent. Each is the agent doing what it was asked, with a secret in reach. The defence therefore cannot be "tell the agent to be careful". It has to remove the reach.

Keeping Them Out by Construction

Secrets live outside the working tree and are injected into the process at run time from the team's secret store. A file that is not on disk cannot be read, by the agent or by anything else. Configuration names the variable that holds a secret and never contains its value. Development and test keys belong to a sandbox account at the provider, where a leaked key is worth nothing to anyone.

For whatever must remain on disk, the agent's permission settings from Chapter 3 deny reads of secret-file patterns. The difference between that and a sentence in the instructions file is the whole point of this page. A deny rule is enforced by the tool: the read never happens, whatever the model concluded. An instruction is a request the model weighs against everything else in its context, including text written by an attacker, which is the next page's subject. Test the deny rule once, with a request the agent should refuse. A rule nobody has seen refuse anything is an assumption.

Pasted errors need the same treatment by hand. Before a stack trace or a log excerpt enters the session, replace the secret with a placeholder and keep everything else.

pasted:   could not connect: postgres://booking:Tr4v3rse-91c@staging-db.internal:5432/booking
redacted: could not connect: postgres://booking:<password>@staging-db.internal:5432/booking

What the Agent Does With a Secret It Saw

It uses it. That is not malice; it is helpfulness. Asked to make a failing integration test pass, an agent that has seen the payment sandbox key hard-codes it into a test fixture, because that makes the test pass. It puts a token on a command line, where it lands in shell history. It prints one in a debug line to confirm a connection works. Any string shaped like a credential in a diff is one of Chapter 6's "new and unasked-for" items, and reading the diff is the first line of defence.

The backstop for the one a reader misses is secret scanning, run as a pre-commit hook and again in CI. It does not know what a secret is; it knows what secrets look like, and that is enough for the common cases.

$ git commit -m "refunds: integration test against the payment sandbox"
secret scan: staged lines that look like credentials
  fixtures/payment-sandbox.json:4
commit rejected: move the value to the secret store; rotate it if it was ever real

When One Leaks

Rotate, do not delete. Removing the line from the file, the chat or the history does not un-send it: the copy at the provider, the copy in the local transcript and any shared copy are all still there, and none of them is yours to delete. Rotation is the only response that changes anything, because it makes every copy worthless at once.

At Cragmoor the staging database password from Kai's stack trace is rotated the same afternoon, a twenty-minute job. The same leak of the live payment key would be a much longer day: a production credential, a provider support ticket, a deploy to pick up the new key, and a review of every charge made while the old one was exposed. That difference is why live keys never sit in a working tree where an agent runs, which the last page of this chapter makes into a rule.

Data That Is Not a Key

Member names, email addresses and phone numbers are the same problem with legal weight. A production export used as a test fixture puts thousands of members' personal data into every session that opens the fixture, and from there into every place listed at the top of this page. What personal data may enter a context at all is team policy, Chapter 13's subject, and the default answer is none: test fixtures are synthetic, generated for the tests, with names nobody owns and addresses on a domain reserved for examples.