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.
prod
Protected: org role alone grants nothing here. Access comes from an explicit grant.
| Member | View | Run | Manage | Via |
|---|---|---|---|---|
| Ada LovelaceOWNER | View allowed | Run allowed | Manage allowed | Org role (owner) |
| Bo ChenADMIN | View not allowed | Run not allowed | Manage not allowed | No access |
| Cy OkaforOPERATOR | View allowed, expires in 2h | Run allowed, expires in 2h | Manage not allowed | Grant · expires in 2h |
| Eli NovakVIEWER | View not allowed | Run not allowed | Manage not allowed | No 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.