RazorpayRefunds and payment captures. OpsAI holds the API key; the agent never sees it.
- System
- Razorpay · Payments
- Permits
- issue.refund · capture.payment
Start hereHow an AI system comes under control
The control layer for enterprise AI
Connect the AI systems, agents and models already running across your organization—and govern how they access data, make decisions and take action.
No inference in the decision path
Skip to the system picture- Decisions · 24h
- 240
- Authorized
- 215
- Held
- 20
- Denied
- 5
- Median decision
- 17 ms
- Inference calls
- 0
Decisions over time
AuthorizedHeld or denied
AI system inventory11 systems, every one owned
| AI system | Answers for it | Autonomy | State |
|---|---|---|---|
| refund-resolver | Priya Nair | L3Act with approval | Acting |
| order-lookup | Priya Nair | L1Observe | Acting |
| ap-invoice-agent | Rahul Menon | L2Advise | Acting |
| payout-runner | Rahul Menon | L4Act autonomously | Watched |
| vendor-onboard | Anita Rao | L3Act with approval | Acting |
| inventory-sync | Anita Rao | L2Advise | Acting |
What OpsAI is and is not
OpsAI is
The layer that decides what your AI systems are allowed to do, and holds the record of every decision.
OpsAI is not
An agent framework, a model, or a replacement for the systems you already run. Nothing here builds an agent.
Runtime authorization for AI agents
The shape of it
One way through, and five things that have to be true.
Everything your AI proposes converges on one control point. Identity, accountability, policy, risk and approval are resolved there before the call goes out — and whichever way it goes, the passage leaves a record behind.
Why this is needed now
Enterprise AI is becoming distributed. Control is not.
Nothing here is a failure of any one tool. It is what happens when capability spreads faster than the structures that account for it.
AI arrived one team at a time.
Each purchase brought its own credentials, its own vendor console, and its own idea of what it was allowed to do.
The controls came with the tools.
Every vendor has a settings page. None of them can see the others, so none can say who authorized what.
AI crossed from drafting to doing.
Review-after-the-fact works for a suggestion and is structurally too late for a transfer.
What it sits between
Above the AI you already run. In front of the systems that hold real state.
OpsAI is additive on both sides. Nothing about the model, the framework or the system of record changes — what changes is that every call between them now has to be decided.
- No model changes
- Keep the providers, versions and prompts you already run. OpsAI governs what the model is allowed to reach, not how it thinks.
- No rebuilt agents
- LangGraph, CrewAI, MCP servers and hand-written orchestration connect as they are. The agent does not learn a new framework.
- No new system of record
- Salesforce, NetSuite, Zendesk and your warehouse stay where they are. OpsAI sits in front of the call, not in place of the system.
Connecting a system is what gives OpsAI something to govern.
The actions it permits, the bounds those run inside, and the record of every one. OpsAI holds the credential; the agent only ever holds a request.
Razorpay- RazorpayRazorpayPayments
RazorpayXRazorpayXPayouts
Zoho BooksZoho BooksAccounting
NetSuiteNetSuiteERP
SalesforceSalesforceCRM
PostgresPostgresDatabase
ZendeskZendeskSupport
GmailGmailEmail
SlackSlackMessaging
Amazon S3Amazon S3Storage
BoxBoxDocuments- WorkdayWorkdayNot connected
IllustrativeThe models and systems above are the OpsAI sample estate, not a customer deployment. How an estate is inventoried.
The core loop
Connect, understand, govern, control, observe, improve.
The six stages are the product model and also the structure of the platform. Each one is a place you can go and see the current state of your estate.
Connect
Bring existing AI systems, agents, models, data and tools under one layer.
7 control surfacesUnderstand
Know what AI exists, who owns it, and how it behaves.
3 control surfacesGovern
Identity, accountability, policy and data controls.
5 control surfacesControl
Risk, approval and the boundaries an action runs inside.
3 control surfacesObserve
Activity, traces, incidents and the evidence record.
4 control surfacesImprove
Routing, evaluation, posture and continuous governance.
3 control surfaces
What is checked
Seven questions, answered before anything runs.
These are the seven, in the order they are evaluated. The first five are the rows inside the control layer above; the last two travel with the call itself. Every panel below is the real control surface, running the sample estate.
Identity
Which agent is this, and can it prove it?
Every agent carries an attested workload identity that resolves to a named person, not a shared service account.
Accountability
Who answers for it when it acts?
RACI on every AI system. Authority starts at a person and narrows at every hop — a child may only ever hold a subset of its parent.
depth 1 of 3
Policy
Which rule governs this action?
Authored in the language of the business by the team that carries the risk, versioned, and replayable against past actions before it is published.
v7in force since 30 Jun 2026
- When
- action == issue.refund
- And
- amount ≤ INR 25,000
- And
- scope == order.placed_by(request.subject)
- And
- window == production.write_window
- inside
- authorize + seal evidence
- above ceiling
- hold for named co-signer
- scope mismatch
- deny + record reason
Risk
How consequential is it?
Scored from what the action touches, how much it moves, and whether it can be reversed.
25held or denied, of 240
Approval
Does a person have to co-sign?
An action needing a person is held for a named co-signer, and expires rather than proceeding.
20held for a co-signer
Execution
Can it widen once it is authorized?
The bound travels with the outbound call, so an authorized action cannot grow in flight.
17msmedian decision
Audit
What proves what happened?
Sealed before the response returns, chained to the record before it, naming the policy version in force.
240records sealed, none rewritten
IllustrativeEvery panel above renders the OpsAI sample estate, not a customer deployment. All twenty-five control surfaces. The whole chain, end to end, is in the concepts.
The moment that matters
Every action, authorized.
A refund agent proposes to move money. It is a high-risk action, and it is authorized — because it fell inside a policy someone owns, and every clause of that policy was checked before the call went out.
Action proposed
ACT-7512 · decided in 11 msRisk: High
- Agent
- refund-resolver
- Asked to
- issue.refund
- Target
- Razorpay
- Subject
- ORD-40122
- Amount
- ₹18,400
- Policy
- refund.ceiling v7
- Approval
- Within bound
- 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
Decision: Authorized0 inference callsEV-7512
High risk does not mean stopped.
Risk and outcome are two different judgements. This action was consequential enough that its rule had to be evaluated clause by clause — and it cleared.
Suggesting a refund and issuing one are different acts, and only the second one moves money.
- Why it scored high
- Not the amount. Money leaves the business and cannot be pulled back, and irreversibility is the input people forget.
- What would have changed it
- The same refund above its ceiling, or against an order the requester does not own. Either one holds it for a named co-signer instead.
Before it was decided
The 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
All 5 checks resolved in 11ms, before the call went out.
IllustrativeOne action from the OpsAI sample estate, not a customer deployment. See how activity is reported.
How the decision is made
Policy is not a prompt.
The decision path holds no inference at all. Bounds are declared and evaluated as code, which is why a decision takes milliseconds, why its cost does not track the price of inference, and why the number can be shown without flinching.
refund.ceiling
Finance wrote this · 30 Jun 2026v7
Refunds are capped per order and per hour, and only against an order the requester actually placed.
# what a refund may be — not what a model may say
bound issue.refund {
amount <= INR 25_000
scope == order.placed_by(request.subject)
requires order.status in ["delivered","cancelled"]
rate <= 5 / hour / agent
on_exceed deny + escalate(owner)
}Scope: issue.refund
Change history
- v7In forcetightened after a review30 Jun 2026
- v6scope widened to a second system11 May 2026
- v1first published by Finance24 Mar 2026
Evaluated as code. No model call in the decision path.
A rule you can read, own and replay.
This is the policy the refund above was decided against, in the form it is actually evaluated in. It is written in the language of the business rather than as a resource ACL, it belongs to the team that carries the risk, and it is versioned — so a change can be replayed against past actions before it goes into force.
Nothing in that evaluation asks a model what it thinks. It reads the clauses, in order, and returns the first one that applies.
0
Inference calls in the decision path.
The console reports it as a field rather than as a metric, because it is a property of how the decision is reached and not a number anyone is working towards.
- Deterministic.
- The same inputs decide the same way, every time. There is no temperature and nothing is sampled.
- No model in the path.
- Nothing to jailbreak with a prompt, and no provider outage sitting between an action and its decision.
- Auditable.
- A decision is explained by pointing at a clause and the policy version it came from, not at a probability.
The sample estate, counted
Every action accounted for, and the record only grows.
One figure and one shape. How much was decided in the last day, which way each one went, and what an append-only ledger looks like when nothing is ever removed from it.
240
Decisions in the last 24 hours.
Every one of them evaluated against a policy someone owns, and sealed to the record whichever way it went.
- 215
- Authorized
- 20
- Held for a person
- 5
- Denied outright
IllustrativeEvery figure and the curve above are the OpsAI sample estate, not a customer deployment. See the control surfaces.
Where to start
See what your AI is already allowed to do.
Read the platform in the order the loop runs, connect one system and watch what it asks for, or bring us the action you are least comfortable letting an agent take unsupervised.