In plain terms — no computer science degree required

Where your keys stay when an AI works for you

Technical appendix to the Sunday edition

This page belongs to the Sunday edition “Passwords, personal data, AI: who is protecting whom?”. That text covers the why — this one covers the how: a single drawing that shows why an AI agent can use your passwords and API keys without the AI — or the company behind it — everreceiving them. Ten minutes, no expertise required.

The drawing

YOUR MACHINEVaultpassword manager:all keys, encryptedkey is fetched only atthe moment of useAI agenta program on your machine:runs commands, inserts the key,never writes it anywhereno key evercrosses this lineAI VENDOR (CLOUD)Language modelsees only text — thinks, plans,proposes the next steptext only: task, context, resultstext only: “run this command”SERVICEe.g. mail system, git serververifies the key, does the work —it issued the key to you itselfcommand with key — direct,encrypted, bypassing the AI vendor

The three parties

Your machine is the only place where everything comes together. The vault lives here (the password manager holding every key), and the AI agent runs here — an ordinary program, the way your browser is one.

The AI vendor operates the language model in its datacenter. The model is the “brain”: it reads text, thinks, and answers with text. That is all it can do — it has no hands. It cannot run a command, open a file, or unlock a vault.

The service is the system where the work actually happens: the mail sender, the git server, the accounting tool. It issued your key in the first place, and it is the only party that ever needs to see it again.

What travels where?

What flows to the AI vendor is text, and nothing but text: the task (“send the newsletter”), context (which tools exist), and later the results (“delivery confirmed, 214 recipients”). What comes back is also text — including the proposal for which command to run next.

But the model does not run that command — the agent on your machine does. And only at that moment, locally, does it fetch the key from the vault and insert it into the command. The finished command then travels encrypted and directly to the service: from your machine to the mail system, never routed through the AI vendor. That is the red line in the drawing: the key travels to the lower right, never to the upper right.

A picture for it: the model is an advisor on the phone. It tells you which door to open — but the keyring is in your hand, and no key has ever fit through a telephone line.

Staying honest: where the boundary leaks

Three things need saying, or this drawing would be advertising rather than explanation:

  • Copy-paste breaks everything. Paste a password into the chat window and it travels to the vendor as text — the architecture only protects what you leave to it. Hence the rule: keys get used, never dictated.
  • Whatever the agent reads, the model sees. Results flow back as text. If the agent opens a file full of customer data, its contents travel to the vendor. That is why an agent gets access only to what the task requires.
  • The key must never enter the log. A well-built agent uses it without ever displaying it — because a password that never appeared in any transcript cannot be stolen from one.

You do not have to believe this — you can verify it

The nice thing about this architecture: it is checkable. Every session leaves a transcript recording what went to the vendor as text. Look inside and you will find tasks, commands, results — and in the place of the key, only a reference to the vault. Exactly as it should be.

Why all of this matters — and the four questions every company should answer before opening doors to an AI — is in the Sunday edition: “Passwords, personal data, AI: who is protecting whom?”

← Back to the Sunday edition