Security

Two-factor authentication is available on every plan, including Free. It uses time-based one-time codes from any authenticator app. The seed is encrypted at rest with AES-256-GCM and is never returned by the API, and a code that has been used once is refused along with every earlier time step, so a code read over your shoulder is dead the moment you use it. Enrolment issues ten single-use recovery codes, stored as hashes.

Organisation-wide enforcement. Enterprise organisations can require two-factor for every member. Owners keep a break-glass path so a misconfiguration cannot lock an organisation out of itself.

SAML single sign-on is available on Enterprise, for both dashboard access and for gating a documentation site behind your identity provider. Enforcement is matched to your verified email domains, and provisioning rules are yours to set.

Sessions. Your security settings list every device with an active session, marking the one you are on. Revoking a session invalidates it immediately; an access token already in flight stops working when it expires shortly afterwards. Passwords are stored as bcrypt hashes and never in a recoverable form.

Permissions are granted per organisation, not per account. Someone with access to one of your organisations has no visibility into another, and members can be scoped down to named projects rather than everything you own.

Roles carry granular permissions covering billing, members, projects, specs, SDK publishing and settings. Every authorisation decision is made from the membership record for that person in that organisation, so removing or suspending a member takes effect across the product rather than in one place.

API keys are shown once and stored hashed. They can carry an expiry, they can be revoked instantly, and they are scoped to the organisation that created them. Rate limits on key traffic are applied per organisation.

Documentation access. Each documentation site is public, password-protected, or behind SAML SSO. Gated sites use a signed, HTTP-only session cookie; the access token never appears in a URL.

• In transit: TLS on every public endpoint, including custom documentation domains, where certificates are issued and renewed for you.
• At rest: authenticator seeds and stored webhook URLs are encrypted with AES-256-GCM under keys derived per purpose, so one key cannot decrypt another kind of secret. Passwords, API keys and recovery codes are stored as hashes and never decrypted.
• Secret hygiene: sensitive fields are excluded from queries by default and stripped again during serialisation, so a stray query cannot leak a seed into a response.
• Isolation:every query is scoped by organisation. Documentation sites are resolved per project and cannot read another project’s content.

Our databases, cache and message broker are self-hosted rather than rented from a managed third party, which keeps your content inside infrastructure we control. The vendors that do process data for us are listed on the subprocessors page.

Privileged actions are written to an audit log your organisation can read: sign-ins and failed sign-ins, two-factor changes, session revocations, member and permission changes, SAML configuration, project and spec changes, API key creation and revocation, billing events, and SDK publishing. Each entry records who, what, when, from which IP and user agent, and whether it succeeded. Entries are kept for 365 days.

Actions taken by Octri staff on your organisation are logged in the same place, under the staff member’s own email address, so support access is visible to you rather than invisible.

Rate limiting is applied across the platform and shared between API instances, so a limit is a real ceiling rather than one that multiplies with our server count.

• Cross-origin requests are restricted to an explicit allowlist. There is no wildcard origin in production.
• Responses carry X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin and a Permissions-Policy that switches off camera, microphone and location.
• Session cookies are HTTP-only and signed, so page scripts cannot read them and a tampered cookie is rejected.
• Every request body is validated against a schema before it reaches business logic, and configuration is validated at startup so the service refuses to boot misconfigured.
• Custom code and components you author for your documentation are compiled and scoped before they are served.
• Dependencies are pinned in a lockfile and updated deliberately rather than floating.

Some of the surface is yours to hold:

• Turn on two-factor authentication, and store your recovery codes somewhere other than the machine you sign in from.
• Keep secrets out of your OpenAPI spec. Anything in the spec can end up in published documentation and in SDKs on a public registry.
• Scope what you send to monitoring.Errors and traces carry whatever your application puts in them, including your own users’ data. Strip what you do not need at the instrumentation layer.
• Review access regularly. Remove members who have left and revoke API keys you no longer use.
• Treat registry credentials as production secrets. Publishing runs under them, in your name.

Email founders@octri.dev. Do not open a public issue, and do not post it in Discord. We acknowledge reports and will keep you updated while we work on a fix. Tell us if you plan to publish, and we will agree a timeline with you.

Include

• What the issue is and what an attacker could do with it.
• Clear steps to reproduce, with the affected URL or endpoint.
• Anything you need to demonstrate it: a request, a payload, a short recording.

In scope

The dashboard, the public API, hosted documentation sites, the marketing site, our generated SDKs and the MCP server.

Out of scope

• Findings from automated scanners with no demonstrated impact.
• Missing headers or best-practice suggestions with no exploitable consequence.
• Social engineering, physical attacks, and anything targeting our staff or customers.
• Denial of service, load testing and traffic floods. Do not run them against us; ask instead.
• Issues in a customer’s own API, which we neither operate nor control.

Our commitment

If you act in good faith, stay inside the scope above, use only test accounts you own, avoid accessing or destroying other people’s data, and give us a reasonable chance to fix the issue before disclosing it, we will not pursue legal action against you and we will not ask your provider to. We do not run a paid bounty programme at present. We do credit reporters who want to be named.

We would rather tell you where we stand than imply more than is true. Octri is an early-stage product and we do not hold a SOC 2 or ISO 27001 certification. The controls on this page are the ones the platform actually implements today, not a roadmap.

Our processor terms are published in full as the Data Processing Agreement, pre-signed and in force for every customer, with the Standard Contractual Clauses and the measures above set out as its annexes. For a countersigned copy, a security questionnaire completed, or a written service level agreement, write to founders@octri.dev.

How we handle personal data, and how long we keep it, is set out in the Privacy Policy.