Do the passwords and keys you give the AI stay in the chat logs?

#One download link holds a live token

Connect the AI to your company database and a cloud drive, and you have handed it the database password and access to the drive. Ask it to fetch a file from the drive and tidy it up, and the AI gets a download link and opens the file. That link is an address more than 2,000 characters long with a live access token embedded in it. If the address lands as is in chat history, server logs and requests to an outside AI company, it's no better than writing passwords on a notepad and passing it around.

In OwlAI, that token never reaches the AI's conversation context or the server logs. The original address is encrypted and held on the server for one hour, and the AI gets a 19-character reference instead. Passwords and keys sit in a vault that is locked twice from the start.

#Passwords and keys live in a vault locked twice

Database passwords, tokens and API keys for external services, AI model keys, SSH keys for database connections, and two-factor authentication secrets all go into the credential vault. The vault uses envelope encryption: each secret is locked with a data key, and that data key is locked again with a master key. Even if the whole database leaks, nothing unlocks without the master key.

A locked secret is bound to where it is stored, its organization and its purpose, so copying it into another organization's row does not unlock it. A server whose vault key isn't ready does not store secrets, and a wrong key setting keeps the service from starting at all. On premises, the master key comes in through server configuration or a secrets management tool; in SaaS, the cloud's key management service holds it.

The admin console does not show secret values either. Additional credentials attached to an external service appear by name only, with the values masked. If you try to register a server address with a password or token written into it, the console rejects it and points you to the separate authentication field, because the address is shown as is on screen and in records.

#The AI sees only a 19-character reference

A download link can't simply be locked away, because the AI needs it to fetch the file in the next step. So the address with the embedded token is encrypted in a store on the server, and the AI is shown a short reference in its place. When the AI asks to fetch the file with that reference, the tool looks up the original address in the store and uses it.

A reference expires after one hour, and only the user it was issued to can resolve it. Someone who guesses a reference string and enters it gets nothing. As a side benefit, the AI no longer stalls a task by miscopying a 2,000-character address one character at a time.

#Large results saved to file get masked first

When a result is too large for the AI to take in at once, OwlAI saves the original to a file and has the AI read it in pieces. Addresses with embedded tokens are masked before that file is written, so no token ever sits on disk in plain text. When the file later leaves as an Excel attachment or an email, it passes through the same output boundary as every other exit.

#Lose the master key, and secrets must be re-registered

We made it impossible for anyone to open the vault without the master key, and that is deliberate. If the key is lost, an administrator has to register every secret again. We judged that cost worth paying so that someone who walks off with the whole database cannot unlock the secrets.

That is why the master key is kept apart from both the server configuration file and the database backups. If backups and key leak together, locking twice means nothing. It is also the first thing to settle with your IT team before rollout: where the master key lives, who keeps it, and how it stays separate from the database backups.