Enterprise
Security at OpsAI
Where the control points actually sit: how an agent gets an identity, how credentials are held rather than handed out, and how execution stays constrained.
For an architecture review
This page is about whether the design is sound. The documentation is about working with it, and the solutions page is about why a security team wants it.
Certification status is on the trust center: none held, no dates.
The only question worth asking about a control point
Can it be bypassed? There are four ways, and each has to be closed.
A control that can be avoided is a report. So the useful way to review this architecture is not feature by feature but by asking how an action could reach a system of record without passing the boundary — and there are exactly four routes.
- Claim to be something else
- Identity is attested rather than asserted. A caller saying it is the refund resolver is not sufficient, and if it were, that agent’s bounds would constrain nothing.
- How
- Hold the credential directly
- No AI system ever receives one. There is no endpoint that returns a stored credential at any scope, so this is a property rather than a policy somebody maintains.
- How
- Widen scope mid-flight
- The grant is derived after the decision and scoped to the action that was authorized. Nothing is renegotiated at the boundary, and delegation cannot exceed the delegator’s own scope.
- How
- Act without leaving a record
- The record is a by-product of having decided, not a separate write that could fail. Refusals are recorded as completely as authorizations.
- How
Three of those four are closed by an absence rather than a feature.
No endpoint returns a credential. No endpoint widens a grant. No endpoint amends a record. An absent code path cannot be misconfigured, cannot be granted by mistake, and does not depend on anybody remembering a policy — which is why the strongest claims on this page are about things that do not exist.
Where the control points sit
Five stops, and the ordering is the design.
Identity is established before authority is resolved, authority before the policy is evaluated, and the policy before anything reaches a system of record. Any other ordering leaves a window where an action is in flight without having been authorized.
The workload proves what it iscannot be self-issued
Not a claim in a header. mTLS, a workload token or a platform-signed JWT — something the workload cannot mint for itself.
Authority is resolved to a personfrom your IdP
The chain from the accountable human down to the acting system, read from your directory rather than from a list OpsAI maintains.
The action is evaluatedno inference
Deterministically, with no model call. The rule is not in the context window, so there is no prompt for anything to argue with.
A grant is derived, scoped and shortsingle use
To this action, carrying this subject, expiring in seconds. The credential it came from never leaves the vault, including to the enforcement point.
The record is sealed before the response returnsbefore the reply
Chained to its predecessor. A removed record fails verification rather than merely being absent.
- Why identity first
- Everything after it is scoped by who is asking. Resolving authority before establishing identity would mean resolving the authority of an unverified claim.
- Why the grant comes last
- It is derived from the decision. A grant issued before evaluation would be a capability held while the question was still open.
- Why the seal is before the reply
- A record written after responding is a record that can fail to be written. Sealing first means a decision the caller received always has an entry.
Decision latency
11ms
the canonical action
Model calls in the path
0
deterministic
Credentials reaching an agent
0
grants are derived
Delegation depth cap
3
refused, not truncated
IllustrativeIllustrative figures for the OpsAI sample estate.
The vault
Held centrally, distributed to nothing — including the enforcement point.
That last clause is the one worth reading twice. Handing a credential to whatever performs the action would be the obvious design, and it would mean a compromised enforcement point yields the secret. Derived material means it does not.
How a workload is attested
- orchestrator
- mTLS client cert
- retrieval
- mTLS client cert
- conversational
- OIDC workload token
- scheduled worker
- Platform-signed JWT
Rotation, in 4 stages
- 01IssueA second credential is created alongside the first.
- 02Dual acceptBoth are valid. Every enforcement point takes either one.
- 03Cut overNew grants derive from the new credential only.
- 04RevokeThe old credential is destroyed at the source.
Dual accept is the stage most procedures omit, and omitting it is what turns a routine rotation into an outage. No code change is required at any stage because the AI systems never held the credential.
- 10 credentials held
- 2 past 80% of their policy window in the sample estate, which is deliberate — a vault where everything is always current is a brochure rather than an inventory.
- A grant is single-use
- Scoped to one action, carrying the subject so it cannot be replayed against another record, expiring in seconds. A leaked grant is a bounded incident; a leaked key is an investigation.
- Tenant isolation
- Tenant is part of the primary key rather than a filter applied in application code. A filter can be forgotten in one query; a key cannot. Evidence chains are per tenant, so verifying yours needs access to nobody else’s.
Claims a reviewer can falsify
Properties, not assurances.
Each of these is false the moment a counter-example exists, which is what makes it worth stating. An assurance — that we take security seriously — cannot be checked and therefore cannot be relied on.
- No endpoint returns a stored credential
- At any scope, including admin, including support. There is no code path that reads one back out, which is what makes "the agent never sees the key" a property rather than a policy.
- No endpoint amends an evidence record
- Sealed before the response returns, and chained so a removed record fails verification rather than merely being absent.
- No model call in the decision path
- A policy is evaluated deterministically. The same inputs and the same rule version reach the same conclusion, which is what makes a decision replayable.
- No hold can be extended
- There is no endpoint for it. A hold that can be extended indefinitely is a queue, and a queue defaults to eventually yes.
- Tenant is part of the primary key
- Not a filter applied by application code. A filter can be forgotten in one query; a key cannot.
- Nothing read from a governed source is stored
- OpsAI records that a read happened and what it was permitted to do — not what came back. There is no copy of your data.
Status
Trust center
Certification status stated as status, what OpsAI will not do, and how to report a vulnerability.
Working with it
Security documentation
Key scopes, attestation methods, tenant isolation and the data boundary, as mechanisms.
Where it runs
Deployment
Three options, described by what leaves your network under each.
Where to start
Try to design a bypass. There are four routes and each is closed by an absence.
It is the fastest way to review this architecture, and the fastest way to find out whether the claims hold. If you find a fifth route, that is worth an email to security@opsai.dev.