Security at Ahena

Outside your runtime path

Ahena is a control plane, not a runtime proxy. It connects, configures, verifies and diagnoses your providers, but your application calls Supabase, Stripe, Resend and the others directly, with code that uses the providers' official SDKs. No Ahena API route forwards your application's traffic, and generated code imports nothing from Ahena and calls nothing at Ahena. So Ahena never sees your users' requests, payments, emails or completions.

Read more: Control plane, not a runtime proxy and the guide Control plane vs runtime proxy.

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; master keys can be rotated by rewrapping, without decrypting values.
• Bound to their scope. 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. Revealing an application secret's value is a separate, permission-checked and audited action.
• Not from command-line arguments. The CLI reads credentials from an environment variable, stdin or a hidden prompt, so they don't land in shell history.
• Least privilege, where providers allow it. Each integration page lists the permissions Ahena needs, for example a Stripe restricted key with only the permissions it uses. Where a provider can't scope a token (Supabase personal access tokens), Ahena says so when you connect.

Disconnecting a provider deletes the credential Ahena stored. It never deletes anything at the provider, and Ahena tells you where to revoke the key there.

Where credentials can go

Every provider integration 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 parsed through allowlists, so third-party secrets in them (for example OAuth client secrets in Supabase's auth configuration) are dropped at the boundary.

Organizations, projects and environments

• 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.
• Authorization is checked inside Ahena's core services, so the API, dashboard, CLI and MCP server can't disagree about it.
• Four roles: owner, admin, developer and viewer. Production is stricter: changing its providers or secrets needs an admin, and billable or destructive changes need a separate permission.
• Each environment has its own connections and credentials. Ahena checks that production doesn't share them with other environments, and, for example, refuses a Stripe test key in production.

Production changes and approvals

Ahena changes a provider only through a plan. Each operation is classified (safe, needs confirmation, billable, destructive or manual) and the plan is bound to a fingerprint of the provider state it was planned against: if the provider changes before apply, the plan is refused. After applying, Ahena reads the provider back and reports a change as verified only when it sees it.

Manual steps are never applied by Ahena. An approval is used once, for exactly the plan that was reviewed, and expires after 60 minutes. See Approvals and the guide Plan, approve, apply, verify.

AI agents

ahena mcp gives an AI coding agent its own agent session (valid for 12 hours), created from your CLI session. It can read your stack, run Doctor and plan changes, and it can ask for approval, but Ahena refuses it for:

• approving or declining requests, or approving a CLI sign-in;
• revealing secret values;
• managing members, billing or the organization, or deleting projects;
• creating CI tokens or further agent sessions.

Changes that matter are approved only in a signed-in browser, which an agent running in your terminal doesn't have. The honest limits: an agent that controls your browser or knows your password can act as you (two-factor sign-in raises the bar for the password case), and outside production an agent with shell access to your CLI token can approve reversible, non-billable "needs confirmation" changes. See MCP for AI coding agents and the guide Giving AI agents infrastructure access safely.

Sign-in and sessions

• Passwords are hashed with scrypt. Two-factor sign-in with an authenticator app is available for every account.
• Session 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 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. CI tokens are read-only and limited to one project.
• The dashboard and this site send a strict Content Security Policy: scripts run only with a per-request nonce.

Audit log

Every change writes an audit event in the same database transaction: who did it, how (web, CLI, MCP or CI), where (organization, project, environment and provider), what changed, the result and a request id. Events are append-only 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; periodic external anchoring is planned.

Redaction

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. Audit metadata is redacted before storage, so events name secrets and resources, never their values.

If Ahena is unavailable

Your application keeps running: it talks to your providers directly and has no runtime dependency on Ahena. What you lose while Ahena is unreachable is management: plans, applies, Doctor runs and drift checks. The CI deploy check (ahena deploy-check) fails closed when it can't reach Ahena, so a deploy isn't waved through unchecked. Current state: Status.

Where Ahena runs

Ahena's website, dashboard and API run on Cloudflare's Workers platform, served only over HTTPS. Ahena's own data (accounts, organizations, configuration and encrypted credentials) is stored in a managed PostgreSQL database. Payments for Ahena plans go through Stripe Checkout; Ahena never sees your card number.

What we don't claim

Ahena doesn't hold SOC 2, ISO 27001 or similar certifications, and hasn't been through a third-party penetration test. We won't say otherwise until it's true. Each integration page shows its verification status: Beta, or Live verified with the capabilities tested against the real provider API. If you need answers for a security review, ask us.

Reporting a vulnerability

Email privacy@ahena.io with "Security report" in the subject. Include what you found, how to reproduce it and what it affects. Please test only against your own account and organizations, never other people's data, and give us a reasonable chance to fix an issue before you disclose it. We'll acknowledge your report by email.

More detail: the security model in the documentation, and the Privacy Policy.