Platform
Let AI act within defined boundaries
Simulation, permission checks, action scopes, execution limits, approval gates, a circuit breaker and human override. The policy travels with the call.
At the boundary
Median decision
17ms
Inference calls
0
Fast enough to sit in the path of a live call rather than beside it. A control that adds a second to every action is a control teams disable.
The mechanism
The bound travels with the call.
A policy engine returns a verdict about a request as it was described. Execution control is about the call as it actually goes out — and between those two moments an action can widen without anyone intending it to.
This is the difference between OpsAI and a rules service the agent is trusted to consult. Authorization here is not a gate the action passes and leaves behind; the bound is attached to the outbound request and re-evaluated at the boundary, so the thing that executes is the thing that was authorized.
It also means the agent cannot be the enforcement point. Anything that holds its own permissions can be argued into widening them, which is why the credential and the check both live outside it.
Three ways an action widens after it was approved.
None of these require anything adversarial. They are ordinary behaviour in systems that retry, loop and get extended — which is why a check at the start is not a control.
- A parameter changes
- The action approved at eighteen thousand executes at twenty-eight. Nothing malicious is required — a retry, a recalculation, a currency assumption.
- A loop iterates
- One authorized refund becomes four hundred, each individually inside the bound. The limit control exists because the bound alone cannot see the aggregate.
- A step is inserted
- A workflow gains an extra call between the check and the write. An authorization granted several steps earlier has no opinion about it.
What happens at the boundary
Seven controls, in the order one call meets them.
Presented as a list these read as a procurement checklist. They are actually a sequence in the life of a single request, and the order matters — a rule about amount is meaningless if the action was never permitted at all.
One call, seven controls
17ms median, end to endSimulation
What would happen if this ran — the amount, the target, the record it would write. Computed before anything moves, so a co-signer decides about an outcome rather than a request.
Permission check
Is this agent granted this action against this system at all. Declared reach, evaluated first, because a rule about amount is meaningless if the action was never permitted.
Action scope
The specific subject, amount and target this authorization covers. Not "refunds" — this refund, on this order, at this figure.
Execution limit
Rate and volume across a window. One authorized action repeated four hundred times is a different event from one authorized action.
Approval gate
Above its bound, held for a named co-signer with a clock. The signature is attached to the call, not recorded beside it.
Circuit breaker
Armed for anything acting unattended. A pattern of refusals or an anomalous rate stops the agent rather than continuing to refuse it one call at a time.
Human override
A person can stop an agent mid-flight, and the stop is a recorded decision with a name on it. The last control, and the one that has to exist for the others to be trusted.
The two that surprise people.
- Execution limit
- Because the bound cannot see the aggregate. Four hundred individually legitimate refunds in an hour is not four hundred small events, and no per-action rule catches it.
- Human override
- A person can stop an agent mid-flight and the stop is recorded with a name on it. This control has to exist for the other six to be trusted — a system nobody can halt is a system nobody will authorize in the first place.
What inside the bound means
Not near the limit. Inside it, at the moment it ran.
The canonical refund cleared with room to spare, and the margin is the point: an authorization is a statement about a specific figure against a specific ceiling, checked when the call went out rather than when the workflow began.
issue.refund against refund.ceiling v7
₹18,400 / ₹25,000
At ₹18,400 against a ₹25,000 ceiling this cleared, and the record says so along with the version of the rule in force. The same action at a higher figure would have been held for a co-signer instead, and the record would say that.
What it would never do is execute at the higher figure because the lower one was approved. That is the specific failure the boundary check exists to prevent, and it is the one an approval-at-the-start design cannot rule out.
Authorized
215
ran inside their bound
Held
20
above it, awaiting a name
Denied
5
a clause was not met
Widened in flight
0
refused at the boundary
Illustrative240 decisions from the OpsAI sample estate over 24 hours. Every one of them sealed.
Before the call went out
11msThe agent asked
0 msrefund-resolver asked to run issue.refund against Razorpay for ₹18,400 on ORD-40122. Nothing has run yet.
- Passedidentityworkload-id · mTLS attested
- Passedactionissue.refund
- PassedidempotencyACT-7512
Authority traced to a person
1 msEvery hop holds a subset of the hop before it. A sub-agent cannot be talked into authority it was never issued.
- Priya NairSupport Ops
- refund-resolver⊆ parent · L3
Bounds matched
2 msTwo bounds apply. Both were written by the team that owns the risk — not by the agent, and not by a prompt.
- refund.ceiling
- delegation.depth
Bounds evaluated
6 msEvery bound held. The action is cleared to run exactly as asked — no wider.
- Passedagent.identityworkload-id · attested
- Passeddelegation.depth1 ≤ 3
- Passedamount ≤ ceiling₹18,400 / ₹25,000
- Passedscope == own-orderORD-40122 · placed by subject
- Passedorder.statusdelivered
- Passedrate ≤ 5/hour3 / 5 this hour
Where to start
Ask where your current check happens.
If the answer is at the start of the workflow, the gap between that check and the write is the exposure. Closing it does not require rebuilding the workflow — only moving the check to the boundary.