Secrets and logins

For most websites, the AI never sees a password. It reuses a login the owner already made. API keys are different: the AI has to see them to use them, and this page says so plainly. Those keys only travel between machines in a locked, encrypted form.

At a glance

Where you see it

Invisible day to day. Logins just work. The daily checkup flags a key file that has drifted out of sync with its locked copy.

What powers it

Saved browser sessions, the .env key files, secrets.vault (the encrypted copy), age (the encryption tool), healthcheck.py.

When it runs

Logins: whenever an agent opens a site. Keys: whenever a tool calls a service. Drift check: once a day.

Where you see it

You see it once per website: the first login. After that, it's quiet. If a key file on one machine stops matching the locked copy, the daily checkup says so.

Two kinds of secret

Website logins (Facebook, LinkedIn, Google, and so on). The owner logs in once, on a screen, like normal. The browser keeps that session. The AI reuses the saved session after that. It never sees the typed password, because it was never typed to the AI.

API keys (the codes that let a tool talk to a service like Stripe or OpenAI). These can't be hidden from the AI. To use a key, a program has to send the real key to the service. If the AI runs that program, the AI can see the key. There is no trick around it.

The honest line

"Anyone who claims the AI never sees ANY secret is lying; an API key is unhideable from the thing that uses it." That is from the system's own design notes, and it stays true here.

What happens, step by step

How a new API key gets from one machine to another.

1. The owner adds a new key on one machine. It goes in a .env file (a plain list of keys). Only the owner's account can read that file, and git is told never to save it.
2. A lock step encrypts the file with age (a small, well-known encryption tool). The locked copy goes into a folder called secrets.vault.
3. The locked copy is saved to git. That is safe, because without the secret key it is just scrambled bytes.
4. The other machine pulls from git and runs the decrypt step (turning it back into plain text) with its own key. Now it has the same .env file.
5. Once a day, the checkup compares each .env file to its locked copy. If they differ, it flags the drift so a key doesn't quietly go stale on one machine.

What powers it

Part	What it does
Saved browser sessions	Keep a site logged in so the AI never handles the password.
.env files	Hold API keys. Readable only by the owner's account. Never saved to git.
secrets.vault	The encrypted copies, which are saved to git.
age	Encrypts and decrypts the key files.
healthcheck.py	The daily checkup. Flags a key file that drifted from its locked copy.

Why it works this way

There are three ways to connect the AI to a service. The system prefers them in this order.

1. Give the AI its own login, where the service allows it. Then the owner's password change breaks nothing, and removing access is one click.
2. Reuse a saved browser session. This is the default today.
3. A password manager the AI can pull from. This was looked at and left out on purpose. It would add setup work for a non-technical owner. It would not remove the first login either, because the site's "are you human?" check still happens once. The gain was too small for the cost.

Some things stay manual by design. When a site sends a "tap yes on your phone" login check, a real person taps it. Nothing automates that, and nothing should.

Connected to

• Services: the list of every service the box is connected to.
• Many machines: how the vault stays the same on every machine.
• The daily checkup: where key drift is reported.
• Known limits: API keys are visible to the AI, and there is no log of key use.