How wikiTaTa safeguards your secrets.
Generally, "AI security" comes down to: trust the model with your keys, and hope. wikiTaTa takes a different stance — the AI never actually handles the secret values. They live encrypted in a vault, and the agent orchestrates them — the secret values are never routed through it.
How a normal AI handles your keys
An AI assistant with no special infrastructure has exactly one way to use a credential: you give it the credential. You paste the API key into the chat, or you put it somewhere the tool can read it. From that moment the secret is loose — and it is exposed in plain text at every level it touches.
sk_live_51N8aQ2eZ123456789KvWxYz0123456789aBcDeF4242
…and it now lives in the transcript, the model's context, and the provider's logs.
This is a sample FAKE API key. This value does not exist — but in a normal AI chat, people really do paste these in. We put a hard stop to that.
A plaintext file on disk — read by any process, any cat, any backup.
Exported to the shell and passed as an argument — now in history and visible to ps.
Where secrets are frittered away (with a normal AI convo).
In the chat itself
You paste the key to get help. It is now in the conversation — and in the model's context, the provider's logs, and anywhere that transcript is later synced, exported, or in screenshots.
In chat history
That conversation does not vanish. It sits in months of history, searchable, exportable, and replayable — every old key still sitting in plaintext where you left it.
In .env files
The classic "secure" spot is a plaintext file on disk. Any process, any cat, any grep, any accidental commit, any backup reads it in the clear.
In environment variables
Exported to the shell so a tool can use it — and now printenv, a crashed-process dump, a child process, or a logging library prints it back out.
On the command line
Passed as an argument so a script can run — and now it is in your shell history and visible to anyone who can list running processes.
In logs & error reports
A request that echoes its headers, a stack trace that captures locals, an exception reporter that ships context off-box — the key rides along, often to a third party.
None of these are exotic. They are the normal way keys move through a developer's machine — and each one is a place the value sits in plaintext, waiting to be read, logged, committed, or exported. The only way to win this game is to not play it.
wikiTaTa changes the flow: the AI only handles the encrypted value.
In wikiTaTa, a secret never enters the chat and never lands on disk in the clear. When your agent needs a credential, it doesn't ask you to hand it over in the conversation — it raises a request and points you at a secure field. The value travels a path the agent cannot observe.
It starts as an alert, not a chat message. The agent posts a vault request to your Now Board:
That opens a vault card — not a chat box. One card can collect several related values at once, each encrypted in your browser before it leaves your machine, and each format-checked the moment you submit. The card also tells you exactly where to get the credential:
- Open Google Cloud Console → APIs & Services → Credentials.
- Create credentials → OAuth client ID → Web application.
- Add your authorized redirect URI, then Create.
- Copy the Client ID + secret into the fields below — that is the only place they ever go.
Behind that simple form, the value moves in three steps — and the agent is on none of them:
- Sealed in the browser. You drop the value into a secure field. It is encrypted in your browser with the vault's public key (libsodium "sealed box") before it ever leaves your machine.
- Unsealed only server-side. A single edge function opens the "sealed box" and writes the value straight into the encrypted vault (pgsodium AEAD, encrypted at rest). The agent is never on this path.
- Used, never revealed. When a service needs the key, wikiTaTa injects it directly to the target — your computer's keychain, a background service's config, a deploy environment. The value goes vault → target. The agent arranges the delivery but never holds the contents.
When code later needs that credential, it asks the vault for it by name (the agent's entry point is wt_vault_request), and wikiTaTa hands the value straight to the running process — or injects it into the keychain, config file, or deploy environment that needs it. The agent issues the instruction and sees the outcome; it never receives the value itself. There is no step where the plaintext passes back through the conversation.
Your secret is never persisted in the clear — and never crosses an inspectable surface: no chat, no .env, no environment variable, no log. It stays encrypted at rest in the vault, and exists in the clear only in the memory of the one process using it at the moment it runs — plus the single server-side step that seals it away. Every read is scoped and recorded; rotating or revoking a key is one step, not a hunt through everywhere it leaked.
The most powerful feature of key handling is what you cannot see.
Key point (pun, sorry). We feel it's so important that we made it a core component of wikiTaTa — because the premise really is: the agent can work with a key it cannot read.
Every kind of credential has a known shape — a Stripe key, a GitHub token, a Supabase key each follow a recognizable format. When your agent sets up a credential, it declares the type of key being issued. wikiTaTa then validates against that known structure and can even test the key live against its provider — confirming it is well-formed and that it actually works — and reports back a simple valid · works.
What the agent learns is the verdict, never the value. It knows the key is the right shape for its type and that the provider accepted it — without having access to the full secret value.
The AI auto-redacts (read: "cleans") the key into a sanitized representation it can refer to safely — for example sk_live_4eC39H••••4. The encoding prevents the AI from ever seeing the full value of the secret, while still giving it enough of a reference point to communicate clearly with you and to use as an index when troubleshooting. The structure is legible; the secret stays sealed.
Typical AI "handling" vs. wikiTaTa "vault key handling"
| Typical AI tooling | wikiTaTa | |
|---|---|---|
| Where the secret goes | chat · .env · env var | sealed box → encrypted vault |
| Who can read the plaintext | the model, logs, anyone with a shell | only the consuming process, at the moment of use |
| What the AI sees | the key itself | orchestrates it — never the full value |
| At rest | plaintext on disk | pgsodium AEAD, encrypted |
| Audit | none | every access logged, scoped per read |
| Revoke | rotate everywhere it leaked | one-step rotate / revoke |
One key, three states
The same key, secured at rest, handled by the agent, and fired for a single call — handled the whole way through by something that never sees inside the glass. Tap a state to hold it.
Import your chats — and we handle the secrets in them
Bring in your chat history from your agent — do it when you are signing in for the first time, or at any point while you're using wikiTaTa. As your conversations import, the card-creation system gets to work.
A real head start
wikiTaTa processes the chats and creates cards organized by project. Each project then gets a semantic, mid-level summary created automagically — one of the many ways the agent can find your projects efficiently and build on them with accuracy. This process has been tested and will keep being refined over time — and the agent can absolutely help you clean up the data further.
And the secrets inside those chats
Old chat imports may have sensitive values you pasted into those old conversations. As cards are created, anything that matches a common credential format is handled two ways:
- Redaction recommended — sensitive values are stripped out as the data comes in. A feature we're actively testing — we'd love your feedback.
- Semantic assessment recommended, depending on your data — the agent is alerted to values that are typically secrets in programming and development. It is specifically instructed not to store these values; and where it can read the region around a sensitive key, it automatically flags that value for one-step vaulting and attaches a label with its best guess at what the value relates to.
Same principle, start to finish: the matched value is parsed in memory and never written to a card — it is never kept in the AI's context window or any chat history. You're simply handed a one-step path to seal it into the encrypted vault.
wikiTaTa is in private early access. If this is your kind of problem, request an invitation.