AI Context Secret Leak

What Is AI Context Secret Leak?

An agentic coding assistant reads the working directory to answer you, and it writes into artifacts you publish. Here it read a local secret file while debugging a test, then quoted the live key in a pull request description that went public. You'll seek a session's flight recorder to the read of the secret and the write that carried it out, see why .gitignore did not stop it, rotate the exposed key in the right order, and add an .aiignore so the assistant can no longer read it.

What You'll Learn in AI Context Secret Leak

• Describe how an agentic assistant can read files it was never explicitly handed, because it reads the working directory to build its own context
• Explain why .gitignore does not restrict an assistant, since it governs version control rather than what the assistant may read
• Use a session flight recorder and context map to locate the read of a secret and the write that carried it into public output
• Rotate an exposed key in the correct order: revoke the compromised key first, then issue a replacement
• Scope an assistant's file access with an .aiignore so secrets stay out of its context, and confirm the read is blocked

AI Context Secret Leak — Training Steps

1. A scanner hit

   Bob runs a scanner across public code hosts. This morning it flagged a new pull request on github.tullowick.dev whose description quotes what looks like a live payment key. The feed is up on Bob's screen. Look it over.

2. A live key, in public

   The feed pulled the key straight out of the pull request description. It carries the live prefix, not a placeholder. The feed marks it verified, but Bob wants to see what it opens.

3. Using the key

   A production key is a bearer token: whoever holds it is the account. Bob points the API Tester at Quellby's payments endpoint and carries the key in an Authorization header. If the key is still live, the response is the account's real charges. Nothing here needs a breach. A published key opens the door on its own.

4. The alert

   Quellby's security team runs their own secret scanner. It caught the same key and emailed the account owner.

5. Reopen yesterday's session

   Alice opens the billing workspace in the Code app. Yesterday she asked the assistant to debug the failing billing test. The four files it touched are here, and its memory of the session loads: the files it had in context, the steps it took, and the lines it wrote.

6. Where the key was read

   The flight recorder holds yesterday's session as a timeline. One event is flagged: the assistant read .env.local , a secret file, while debugging a test that never needed it. Find it on the recorder: the first red (hot) mark, in the read lane at 14:01:22, labelled .env.local .

7. Git ignored it. The assistant did not.

   The context map now shows .env.local selected, flagged as a secret. Open .gitignore on the map: the file is listed there, so git never tracks it. But .gitignore only tells version control what to skip. The assistant reads the working directory directly, so an ignored file is still fair game for its context.

8. Where the key went out

   Reading the secret was only half of it. The recorder's next flagged event is an edit to the pull request description. Find it: the second red (hot) mark, in the edit lane at 14:01:58, labelled PR-218 description.md .

9. Written in, never reviewed

   The PR description opens. To make the 'verifying locally' section concrete, the assistant filled the example with the real values it had in context, including the live key. The provenance gutter marks those lines violet and dashed: written by Claude, never reviewed by a human before the PR went public.

10. What let the key leave?