Security

OpenAuditor separates account access, request handling and verification execution. This page explains the implemented controls and the practical steps you can take when connecting business records to the service.

Protect access to your account

You sign in with a one-time code sent to your email address; there are no OpenAuditor passwords. Codes expire after ten minutes, work once and allow at most five verification attempts. The code must be entered in the browser that requested it. Code requests are limited per email address, per IP address and across the service.

A signed-in session lasts up to 30 days. Session and challenge cookies use the Secure, HttpOnly and SameSite=Lax attributes. Signing out removes the current session. Access to your email account is therefore part of the security of your OpenAuditor account.

API keys and sessions are stored as SHA-256 digests rather than readable credentials. A newly created API key is shown once, expires after 365 days and can be revoked sooner from your account page. A Free account can hold five active keys. A key created as read-only can make GET and HEAD requests only, so a key used by a dashboard cannot submit, change or delete anything.

• Name keys for the integration that uses them so you can identify which one to replace.
• Keep keys in a server-side secret store or environment variable, away from source control and browser code.
• If a key is exposed, revoke it and update the integration with a newly created key.
• Protect your email inbox and do not share sign-in codes, even with someone claiming to provide support.

How an authenticated request reaches the service

1. The edge checks access. The Cloudflare Worker validates the API key or console session and applies account limits. Console session requests must come from openauditor.ai itself.
2. The gateway bounds the request. It checks the content type, encoding and declared body size. Compressed bodies are rejected, and the origin call has a 60-second timeout.
3. The origin checks the gateway. The verification service receives a shared gateway secret and account identifier. The caller's API key and cookies are not forwarded.
4. Results remain account-scoped. Reading or deleting an audit requires the account that created it. Knowing an audit id alone does not authorize access.

Public traffic uses HTTPS. The origin's proxy accepts requests from the edge network, and the verification API checks the shared secret. Public schema, evaluation and health endpoints expose service information without exposing an account's audit results.

The verification runtime

The service runs in a container with a read-only root file system, dropped Linux capabilities and no added privileges. Its private container network has no outbound Internet access. The model is mounted read-only; writable audit data and the answer cache use a separate data volume.

The model runs locally on the verification host. Requests are not sent to a third-party AI endpoint. The model artifact identity forms part of the configuration used to identify a result, and the configuration API exposes the model identity.

These controls limit what the service can access and execute. They do not authenticate submitted facts or establish that a model question is qualified. Inspect the result's evidence scope and the qualification attached to the relevant use-case definition; the published evaluations describe the configurations and populations actually measured.

Records remain data

An expense description, contract passage or agent transcript is input to a defined check. It does not authorize a payment, an email, a file change or another external action. SmallDecide scores typed questions; it has no tool-execution role in the hosted verification service.

Relevant use cases include indicators for text that attempts to instruct the reviewer or system. An indicator is a reason to investigate, not a guarantee that every manipulation will be detected. Inspect the original context when a result raises a concern.

Data handling and review records

Authenticated API results and account pages use Cache-Control: no-store. Application logs record request metadata rather than request and response bodies. Batch inputs, results and verification notes follow the retention schedule in Privacy.

Send the fields and comparison population needed for the selected checks. Avoid adding unrelated personal records or credentials to context. When exporting results, remember that facts and evidence excerpts may still contain information from the records you supplied.

Reporting a security problem

Contact ERP.AI through erp.ai. Describe the affected endpoint, the behavior you observed and the minimal steps needed to reproduce it. Include the Request-Id when available and use a sanitized example.

Do not include live keys, session cookies, sign-in codes or confidential audit evidence in the initial report. If a credential has been exposed, revoke it from your account while reporting the issue.