Security & trust at OpsCodex

Deployment & tenancy

OpsCodex is deployed single-tenant, on-premise, inside your own environment. Your documents and process models never leave your tenant, and you decide where — and whether — AI inference runs. There is no shared, multi-tenant data plane.

Access & authentication

Role-based access control

Granular roles map to the governance workflow — author, reviewer, approver, administrator, auditor and documentation editor. People see and do exactly what their role allows, and nothing more.

Single sign-on & MFA

OpsCodex sits behind a Zero-Trust access layer that authenticates against your own identity provider over SAML/OIDC (for example Microsoft Entra ID or Okta) and enforces single sign-on and multi-factor authentication before a request reaches the application.

Sessions

Sessions use short-lived, HttpOnly, Secure cookies. Sign-out, deactivation and role changes take effect immediately.

Local accounts

Where local passwords are used, they are one-way hashed (bcrypt) with a minimum-length policy; changing a password requires the current one and invalidates existing sessions.

Data protection

In transit

All traffic is encrypted with modern TLS; weak ciphers are not offered.

At rest

Application secrets — such as AI provider keys — are encrypted with AES-256-GCM, and account passwords are one-way hashed. In an on-premise deployment you hold all key material yourself.

Uploaded files

User-uploaded content is served as a download with MIME-sniffing disabled, so untrusted files cannot execute in the browser.

Auditability

Governance actions are written to an append-only audit trail. This is enforced in the database, not in application code: a trigger on the audit table rejects every UPDATE and DELETE, and the database role the application runs under has those rights revoked. The application cannot rewrite its own audit history even if it is compromised — only the separate migration role used for schema changes and test teardown can, and that role is never used to serve a request.

To be precise about the boundary: the trigger covers row-level modification and deletion. It does not cover TRUNCATE, and it does not defend against someone with superuser access to your own database server — no application-level control can. Treat the trail as tamper-evident within the application's reach, and pair it with the backup and database-access controls you already run for other systems of record.

When an auditor asks who approved a model and when, the answer is on record: author, reviewer, approver, timestamp, and the export hash of what was released.

Application hardening

Every response carries modern browser security headers — Content-Security-Policy, HTTP Strict Transport Security, clickjacking and MIME-sniffing protections, and a locked-down Permissions-Policy. Request rate-limiting protects authentication and other sensitive endpoints, and dependency and security checks run in continuous integration.

Data ownership & privacy

You own your data

Your content is yours. It is available for export at any time; on termination it can be exported immediately and deleted on request. On-premise, you control destruction directly.

GDPR

The operator is EU-based (Mews Group SAS, France). On-premise, your process data stays in your own infrastructure and your own jurisdiction — it is not transmitted to us, so there is no cross-border transfer on our side to justify.

No third-party tracking

No third-party sharing of personal data, no third-party cookies, and no access to contacts, calendar or other device data.

AI

AI is an optional assist layer: it proposes, a human approves, and the content of your prompts is never stored. See AI governance for how provider keys, data retention and private or self-hosted inference work.

What we do not have yet

A security page that lists only what exists tells you half of what you need. These are the gaps you would otherwise have to find by asking — named here so you can weigh them early rather than late.

Certifications

No ISO 27001, no SOC 2, no TISAX. Not obtained, and no certification date is committed. On-premise deployments run inside your own certified environment, which is why this has not been the blocking question so far — but if a certificate is a hard requirement in your procurement, raise it early rather than late.

Independent penetration test

None commissioned to date. What does run: an automated dependency vulnerability scan every day in CI, and a regression test that fails the build if the security headers above are dropped. Neither is a substitute for someone attacking the application under contract, and we would rather say so than let the two be mistaken for each other.

Public status page

None. For a single-tenant on-premise deployment the availability that matters is your own infrastructure's, so this ranks low — but the absence is worth stating rather than leaving you to notice it.

Data classification and DLP labels

No sensitivity-label or DLP feature. Access is controlled structurally instead: roles, team-scoped permissions, and a hard boundary between internal drafts and the published portal.

Managed key service

Every secret lives in your own environment and we hold none of them — but there is no managed KMS or HSM integration to plug into if that is how your organisation prefers to hold keys.

If you find a gap this list does not name, tell us and it goes on the list. A page like this is only worth reading if it is the whole set.

Found a security issue? Please email [email protected] rather than opening a public report. We acknowledge reports within three business days.