Security

Security model

Ahena holds credentials that can change your infrastructure, so security is part of the product, not a layer on top. This page summarises how it works; the linked pages have the details.

Provider credentials

Envelope encryption. Each credential and secret gets its own random key and is encrypted with AES-256-GCM. That key is wrapped by a master key kept outside the database, and master keys can be rotated by rewrapping, without decrypting values.
Bound to their scope. The ciphertext is bound to its organization, project, environment and name, so a copied value can't be decrypted anywhere else.
Never returned. No API, dashboard page, CLI command or MCP tool returns a provider credential. Lists show names only.
Sent only to their provider. Every provider declares the hosts it may call, and Ahena's core refuses any other destination. A credential for Stripe can only ever reach Stripe's API.
Provider responses are filtered. Responses are parsed through allowlists, so third-party secrets in them (for example OAuth client secrets in Supabase's auth configuration) are dropped at the boundary.
Credentials never come from command-line arguments. The CLI reads them from an environment variable, stdin or a hidden prompt, so they don't land in shell history.

Secrets never enter browser bundles, logs, audit metadata, AI prompts or MCP tool output, error messages, generated source, ahena.config.ts, ahena.lock or git. Revealing an application secret's value is a separate, permission-checked and audited action. See Secrets.

Tenant isolation and roles

Every request is scoped to the organization, project and environment in its route, and Ahena checks your membership before anything else. Ids from another organization behave as if they don't exist (not_found).
Four roles (owner, admin, developer, viewer). Production is stricter: changing its providers or secrets needs an admin, and billable or destructive changes need a separate permission. See Projects and organizations and Environments.
Authorization is checked inside Ahena's core services, so the API, dashboard, CLI and MCP server can't disagree about it.

Approvals

Changes to your providers are planned, classified (safe, needs confirmation, manual, billable, destructive) and bound to a fingerprint of the provider state they were planned against. If the provider changes before apply, the plan is refused. Changes that matter (anything that isn't safe in production; billable or destructive anywhere) are approved only from a signed-in browser. The CLI and AI agents can ask, never approve. See Approvals.

Tokens are random, stored only as SHA-256 hashes, expire, and can be revoked.
The dashboard keeps its session in an httpOnly, Secure, SameSite=Lax cookie on its own origin and calls the API server-side. The API accepts bearer tokens only and never reads cookies.
The CLI signs in with a device code approved in the browser and never sees your password.
Two-factor sign-in (authenticator app) is available for every account.
The dashboard and this site send a strict Content Security Policy: scripts run only with a per-request nonce.

See Signing in.

Audit log

Every change writes an audit event in the same database transaction: who did it, how (web, CLI, MCP or CI), the organization, project, environment and provider, what changed, the result and a request id. Metadata is redacted before storage, so events name secrets and resources, never their values.

Events are append-only (the database rejects updates and deletes) and form a SHA-256 hash chain per organization, so editing or reordering them is detectable. Known limit: removing the newest events, or rewriting the whole chain, needs an external anchor to detect. Planned: periodic external anchoring of the chain head.

Disconnecting

Disconnecting a provider deletes the credential Ahena stored. Disconnecting, or deleting a project or account, never deletes anything at the provider.

Reporting a vulnerability

Email privacy@ahena.io. Please don't test against other people's organizations or data.