YourAirtableAPItoken,keptsecureserver-side

An Airtable token in a web app is a loaded secret. Put it in your frontend code — or let your coding agent paste it into a config file — and anyone who opens the browser's dev tools can lift it and read or rewrite your whole base. Agent-built apps are especially prone to this, because the fastest way to "make it work" is to drop the token where the code can see it.

VibeKit removes the problem instead of managing it. Your token goes into a vault on VibeKit's side, and your website talks to VibeKit — never to Airtable directly.

Paste it once, then it's sealed

You paste your Airtable personal access token a single time in the admin. It's stored encrypted on the server side, and it's write-once: after you save it, it can never be read back — not from the admin, not from an API. Keep your own copy if you need the token elsewhere, because VibeKit won't show it to anyone, including you.

Nothing secret in your deployed site

Your published app holds exactly two things: a public key and an app id. Neither is a secret. There is no token in your code, your environment, or your bundle, so there is nothing for a visitor, a crawler, or a leaked repository to find. Your agent builds against VibeKit's endpoint and never handles the credential at all.

Encrypted both directions

Every request between your site and VibeKit is encrypted end to end, using a hybrid scheme: each request gets its own one-time key, wrapped with the app's keypair. Responses are encrypted the same way — open the browser's network tab and you see ciphertext, not your data or your queries.

No replays, no reuse

Each request carries a short validity window and a single-use nonce, so a captured request can't be replayed later. Combined with the vault, that means the only path to your base runs through VibeKit — where it's also cached at the edge and, if you add login, gated per user with Airtable-backed auth.