Security documentation

Mechanisms rather than assurances. Where something below is a property of the system — true because no code path exists to make it false — it says so. Where it is a policy, it says that instead.

Authentication

API keys are scoped and prefixed by capability, so the blast radius of a leaked key is legible from the key itself. A read key cannot approve a held action or publish a policy version — not by convention, but because the endpoints reject the scope.

sk_read_...     # read the estate, traces, evidence
sk_evaluate_... # evaluate actions; cannot change policy
sk_admin_...    # publish policy versions, manage connections

Keys are shown once at creation and stored as a digest. There is no endpoint that returns a key value, which means a lost key is rotated rather than recovered.

Workload identity

An AI system’s identity is attested, not asserted. A caller claiming to be an agent is not sufficient; the identity has to be provable by something the workload cannot mint for itself. The method depends on how the system runs:

• orchestrator — mTLS client cert
• retrieval — mTLS client cert
• conversational — OIDC workload token
• scheduled worker — Platform-signed JWT

The distinction matters because an asserted identity makes every downstream control decorative. If anything can claim to be the refund resolver, the refund resolver’s bounds are not constraints on anything.

How secrets are held

OpsAI holds the credentials for connected systems. The sample estate has 10. An AI system never receives one — it receives a grant derived from one, scoped to a single authorized action and expiring with it.

This is a property, not a policy. No endpoint returns a stored credential, at any scope, including sk_admin_. Enforcement points also receive derived material rather than the credential itself, so a compromised enforcement point does not yield the secret.

Rotation is four staged steps with a dual-accept window, so it never requires an outage or a code change. The rotation sequence.

Tenant isolation

Every record carries a tenant, and tenant is part of the primary key rather than a filter applied by application code. That is the distinction worth checking in any product making this claim: a filter can be forgotten in one query, and a key cannot.

Policy evaluation, credential storage and the evidence ledger are all tenant-scoped. Evidence chains are per-tenant, so verifying yours does not require access to anybody else’s.

Data residency

Two things are separate here and are often conflated: where OpsAI stores its records, and where the model that serves a request runs.

Storage residency is a deployment choice. Model residency is a property of the model — 4 of the models in the sample estate never send request content to a third party, being either self-hosted or on a private endpoint. The sample estate’s data sources sit across 3 residencies, which is the figure a data-protection review asks for first.

The data boundary

Read access is governed at the source, and export is governed at the destination. The destination list is the control point, and it is deliberately short — the sample estate has 2 approved sinks: warehouse.eu and warehouse.in.

2 sources have no approved destination at all, meaning data may be read into a decision and never written out. That is the strictest setting and the correct one for contracts and payroll.

Reporting a vulnerability

Report to security@opsai.dev. Include what you did, what happened, and what you expected. We acknowledge receipt and will tell you what we intend to do about it.

Please do not test against another organization’s tenant, and please do not run automated scanning against production. A sandbox tenant is available for security testing on request.

The trust centre carries the current status and the subprocessor list.