Security

Keiki runs agents that hold your API keys, talk to your customers and call your tools. This page covers how that is protected. It describes the controls, not how they are built.

Encryption

Bring-your-own keys are encrypted at rest with AES-256-GCM. This covers model, memory, browser and scraping keys you save under Settings → Secrets. Each value gets its own random nonce and an authentication tag, so a stored value can't be read or quietly changed without the platform key.
The same encryption covers other credentials Keiki stores for you: other secrets you save, personal secrets, channel credentials (Slack, Teams, X, email), MCP server headers and OAuth client secrets, webhook signing secrets and wallet grants.
The encryption key lives in a managed secret store. It is never kept in the database or in source code.
All traffic to Keiki uses TLS. Session cookies are HttpOnly, Secure and SameSite.

If you run the agent loop yourself with the SDK, the agent's history, profiles and usage records are stored in your own database. Messages that go through Keiki-provisioned channels are also stored by Keiki so they can be delivered. To keep message storage entirely on your side, self-host the transport as well. The SDK ships adapters for Postgres, MongoDB and Cloudflare (D1, KV and R2), and you can implement a Storage backend of your own. See Storage.

Credentials that can't be read back

Keiki keeps only a hash of each API key and each OAuth access or refresh token. The full API key is shown once, when you create it. Keys can be scoped to one agent, given an expiry, rotated and revoked.
Passwords are stored as salted, slow hashes, never as plain text.
Once you save a secret, its value can't be read back from the dashboard or the API.

Keeping your keys out of the agent

A secret can be bound to a host. The agent's sandbox then gets only a placeholder. The real value is added to outgoing requests to that host and removed from the replies. Shell commands, tools and the model can't see it. If the placeholder leaks to any other host, it is just a string.
Secrets never enter the prompt, the transcript, traces or tool arguments.
Keiki's own provider credentials never reach a sandbox, generated tool code or a prompt.

Tenant isolation

Every request is scoped to an organization on the server, based on who authenticated it. An ID sent by a client or a model is used to look up records you own. It never addresses another tenant's data or a provider resource directly.
The database enforces row-level security on organization data, as a second layer under the application's own checks.
Each agent runs code in its own isolated sandbox. Throwaway runs, such as the playground and evals, never share a machine with your live conversations.
Requests Keiki makes to addresses you configure, such as webhooks, MCP servers and API specs, are checked first, so they can't reach private or internal network addresses.

Accounts and access

Organizations have four roles: owner, admin, member and viewer. Members can manage only what their role allows.
SAML SSO is available on qualifying enterprise plans, and you can require it for your verified domains.
Sign-in attempts are rate limited per account and per client. A refused attempt doesn't reveal whether an account exists.
Sessions expire, and signing out ends them on the server.

Inbound traffic and agent safety

Webhooks from signing channels (Slack, Teams, WhatsApp, Telegram, X) and from billing providers are checked for a valid signature before Keiki acts on them.
Webhooks Keiki sends to you, such as actions and identity lookups, are signed with HMAC-SHA256 under your own secret, with a timestamp, so you can check where they came from and reject replays.
Conversation auth and identity checks let you decide what a given sender may ask an agent to do. Tool calls that need approval wait for a person to approve them.
Optional prompt-injection screening checks inbound messages before they reach the model.

Audit and operations

Changes made through the dashboard and the API are written to an append-only audit log. Owners and admins can view it under Settings → Audit log, and export it on plans that include audit exports.
Internal staff access to the admin console is limited to an allowlist and is itself audited. The console hides credential fields and redacts known secret formats.
Production runs on managed cloud infrastructure, with private database networking and managed backups. Deploys go out only from the main branch, after CI passes.

Compliance