Secrets and sensitive data

The previous lesson ends on a single idea worth its own lesson: you cannot leak what you do not hold. Most secret-handling advice is about controlling what happens to a credential once the agent has it. The stronger move is to arrange for the agent never to have it.

Concretely: the agent does not hold the database password, the payment key, or the admin token. Those live in a proxy — a small service the agent calls, which holds the credential, performs the privileged action, and returns only the result. The agent asks 'refund order 4417'; the proxy, not the agent, knows the key that authorises it. The credential is never in a prompt, a log, or a trace, so no injection can reach it and no exfiltration channel can carry it.

The same principle scales down to sensitive data. One case study in the operations course's framework separates all personal data into a trusted execution environment and hands the agent only opaque reference ids and categorical flags — the agent reasons over 'customer A, tier gold, flag: overdue' and never sees a name or a card number. The risk is not mitigated; it is removed, because the sensitive value was never in the context to be exposed.

The lab is the exfiltration attempt again, but read it for the last row this time. Under structural defence, the credential is held by a proxy and never enters the context — so the 'secret in context' row reads absent, and every channel above it comes back clean not because the model resisted but because there was nothing to take. That is the difference between a secret that is defended and a secret that is not there.