The model is not a safe place to keep secrets

Here's the rule everyone learns the hard way: every byte you put in a model call is potentially logged, replayed, or echoed back in an answer. If the model can read it, the model can say it. If the model can say it, an attacker can extract it.

A few real failure modes:

• Echo leakage. You put a customer's email in the system prompt for personalization. A different user asks "summarize what you know about this account" and the model dumps the email it saw.
• Vendor leakage. Many model providers log inputs for safety review or fine-tuning. Even when they don't, your inputs leave your network.
• Cross-tenant leakage. A multi-tenant assistant pulls context from tenant A's database and accidentally serves it to tenant B because the context wasn't scoped per-call.

Atlas's rule: classify your data before you wire it. The model is a fast junior employee with a public Twitter account. Don't tell it anything you wouldn't tweet.

Four data classes

PII and secrets belong in the vault. encrypted, audit-logged, never in the prompt. If you need to act on them, design tools that look up by reference (a token id, not the token itself) and execute on the trusted side.

Your exercise

On the right: six data pieces, three destinations. Wire each piece to every destination it's safe to send to. The vault is always safe. it's encrypted and stays on-ship. The model and external log are not always safe.

You pass when your edge set exactly matches the safe-routing set: no missing safe connections, no extra unsafe ones.