Skip to content
    Security and trust

    Guardrails before autonomy.

    Opafra runs commands on your production servers. Here is exactly how that is constrained.

    Last updated: September 2026

    Automation that can change production is only as trustworthy as the limits around it. This page describes the architecture and the controls as they exist today. For a Data Processing Addendum or a security questionnaire, contact [email protected].

    Architecture

    • Agentless. Nothing is installed on your hosts. Opafra connects over SSH and leaves nothing running, so there is no agent to patch, no daemon listening, and no new attack surface on the machines you are protecting.
    • Ephemeral SSH certificates. In certificate mode Opafra signs a short-lived certificate per connection through an internal CA or HashiCorp Vault. No long-lived private key for your fleet is stored anywhere in the product.
    • Tenant isolation, fail closed. Every tenant-owned query is scoped to the caller's organization at the data layer, and access defaults to denied rather than allowed. A resource belonging to another tenant returns "not found", never "forbidden", so identifiers cannot be probed for existence.
    • Append-only audit. Security-relevant actions are written to a log that is never updated in place and survives deletion of the user or organization that produced them.

    Who can touch production

    A protected environment ignores organization role entirely. Being an admin is not access. Someone must be granted it explicitly, and that grant can expire on its own.

    Who can touch

    prod

    Effective access to prod per member.
    MemberViewRunManageVia
    Ada LovelaceOWNERView allowedRun allowedManage allowedOrg role (owner)
    Bo ChenADMINView not allowedRun not allowedManage not allowedNo access
    Cy OkaforOPERATORView allowed, expires in 2hRun allowed, expires in 2hManage not allowedGrant · expires in 2h
    Eli NovakVIEWERView not allowedRun not allowedManage not allowedNo access
    • Role-based access control (Owner / Admin / Operator / Viewer) with per-collection and per-environment grants.
    • Time-boxed access. A grant can carry an expiry, so "two hours of production" is a fact in the record rather than a promise someone has to remember to undo.
    • Approval gates. A run against a protected environment stops before it starts and waits for a person. The approval records who decided, when, and against which revision of the plan.

    Credentials and secrets

    • Stored credentials (SSH passwords, keys, provider tokens) are encrypted at rest with AES-256-GCM. All data in transit is protected with TLS.
    • Opafra integrates with external secret managers (HashiCorp Vault, Infisical). When you use one, Opafra stores only a secret:// reference, never the secret value.
    • Secret values are resolved at execution time and are not persisted.
    • Known secret patterns are redacted from execution logs before they are streamed or stored.

    Authentication

    • Authentication uses signed JWTs; passwords are hashed with bcrypt.
    • Sign in with GitHub, Google, Microsoft or GitLab. SAML and OIDC single sign-on on the Business and Enterprise plans.
    • Per-route and global rate limiting protect sensitive endpoints.

    Data ownership

    • Your plans, inventory and execution history belong to you and are scoped to your organization.
    • For customers with strict requirements, a customer-hosted execution model, where credentials never leave your network, is available on request.

    Accessibility

    • Opafra targets WCAG 2.2 Level AA. Color contrast and component semantics are verified automatically on every build, in both themes, so a regression fails the build rather than reaching you.
    • We can describe what is verified and how, per surface. There is no Accessibility Conformance Report yet; when one exists it will be a document with a date on it rather than a line on this page.

    Security questionnaires

    We complete security questionnaires and will walk your team through the architecture. Reach [email protected]. A Data Processing Addendum and a current subprocessor list are available on request.

    Reporting a vulnerability

    We welcome responsible disclosure. Please report suspected vulnerabilities to [email protected] and allow reasonable time to remediate before public disclosure.

    Send us the questionnaire.

    We answer security questionnaires and will walk your team through the architecture on a call. A DPA and the subprocessor list are available on request.