The rule about secrets fits in one line: they must not be where the model can read them. Keys are not pasted into a request, not written into rules and skills, not left in source files and not shown in screenshots. Instead there are proper channels - the operating system's credential store, environment variables with a limited scope, and the separate secret storage of cloud agents. The difference between those two lists is the whole practical security of working with secrets. The first list gathers the places from which a value leaks into a conversation and stays there forever. The second gathers the places where a value lives exactly as long as the process that needs it.
The naive defense is to put the path to the key file into the ignore list and consider the question settled. It gives false calm: exclusions limit the editor's features, while the terminal and external tools work within their own rights. A command run by the agent reads the file exactly as any process with your rights would. An external server that was handed credentials asks the editor for permission even less. So a secret is protected not by being hidden from suggestions but by not being in the reachable area at all.
It helps to lay the types of secrets and their proper channels out in a table once. Below is that map: a local key, a key for the command line, a cloud environment secret, credentials for an external server, a build secret. Each has its right channel and its typical mistake: a committed shell profile, command history with the value in the clear, a snapshot of the environment together with the local variables file, an address with a login and password inside, a secret left in an image layer or in a log. The mistakes in the third column share one property: in every case the value outlives the moment it was retrieved for.
| Secret | The right channel | What to avoid |
|---|---|---|
| A local API key | The system store or a single process's environment | A committed shell profile and pasting into a request |
| A key for the command line | A variable for one process or a CI secret | Command history with the value in the clear |
| A cloud environment secret | The cloud agents' secret storage | A snapshot of the environment together with the local variables file |
| External server credentials | OAuth, environment variables, protected headers | A login and password in the address, committed JSON |
|---|
| A build secret | Build environment secrets | The run log and an image layer |
|---|
What this looks like in real work shows on a simple scenario. Someone asks the agent to find out why a service will not connect to an external API. The agent prints the environment variables to see what is set there, and the key ends up in the command's output. From there the output goes into the conversation's context, from the context into the saved session record, and if the task ran in the cloud, into its log as well. One diagnostic action turned one process's secret into text that sits in several places and will outlive both the task and the conversation. No break-in happened here; ordinary debugging did.
A conversation record can also be handed out by link. A transcript is opened either to the team, where only signed-in members see it and it lands in a shared list, or publicly, and then anyone who got the address has access without signing in at all. Such links are capped at fifty per day. Known formats of keys, tokens and passwords are stripped out on publication, but the stripping is declared best-effort: a value without a recognizable prefix or with a custom format will slip through. With the no-storage privacy mode shared links do not work at all. The order that follows is simple: first reread what exactly is going out, then open access.
From that follows what to do when a leak is suspected. Deleting the line is not enough, because the value may already have spread. The right sequence is: revoke the credentials, then check the repository history, logs, session transcripts, build artifacts and any external actions that could have been taken. Revocation is the first action, not the last: while the key is alive, all the rest of the investigation does not stop anyone from using it. And the count is made by possibility rather than by proof: if the value could have reached a place you do not control, it is compromised.
Team work adds a non-obvious risk. If you allow a follow-up to someone else's cloud task, another person can steer a process that holds the creator's secrets and rights. The official documentation compares that with shared access keys - the comparison is precise. For shared agents it is better to create a service account with minimal rights than to share your own. The difference is that after an incident service access is revoked in one operation, without touching anybody's working day.
From this follows the general principle of separation. The agent should have its own credentials with a narrow scope rather than your personal ones. Then a compromise is limited to what that agent actually needs, and revocation breaks nothing around it. It is the same least-privilege rule as for people, simply applied to a process that reads untrusted text and acts on it. A developer's personal key is usually wider than the agent's task by exactly the amount you never meant to hand that agent.
The ignore file meanwhile keeps a real role of its own, and it should not be confused with protection. It is useful as context hygiene: it keeps giant build artifacts, local dumps and vendored dependency directories out of a request, the kind of bulk in which the relevant thing gets lost. The boundary is drawn like this: exclusions decide what the model sees by default, while the sandbox and permissions decide what the process is able to do. The first affects the quality of an answer, the second the consequences. Expecting the second from the first is the very mistake most incidents begin with.
The engineering conclusion is simple: secrets are not protected by exclusions and rules - they are kept out of reach. Everything else is a backstop. Rules are useful as direction, exclusions are useful as context cleanliness, but neither stops a process with rights from reading a file on disk. This is checked with one question asked of every secret: if the agent runs a command printing the whole environment right now, will this value appear in the output. If it will, the wrong mechanism was chosen.
The typical failures are predictable. Treating exclusions as protection from the terminal and external tools. Pasting a key into a request for a quick check and leaving it in the session record. Allowing colleagues to follow up on your cloud task without setting up a service account. On a leak, starting with tidying the repository instead of revoking the key. And debugging configuration by printing the whole environment where checking a single name would have been enough.