Platform
Control what AI can use
A registry of the tools AI systems may call, who owns each one, what permissions it carries, and which actions need an approval before they run.
Declared reach
Actions
10
Systems
10
Every one carries a bound and a named grantee. Anything outside this list is refused before it reaches a system of record.
What a tool actually is
Not a capability an agent has. A permission it was granted.
Those two framings produce different systems. If a tool is a capability, an unexpected call is a gap in your logs that somebody has to notice. If it is a permission, an unexpected call is a refusal — and the refusal is the log.
Every agent framework has a tool abstraction, and none of them is a permission model. A framework's tool list says what the agent is able to attempt; it has no owner, no ceiling, no write window and no way to refuse. That is not a criticism of the frameworks — it is simply a different job, done in a place that cannot see the other ten agents in the estate.
A declaration lives outside the agent for the same reason a lock lives outside the thing it secures. An agent that could edit its own reach has not been granted anything.
What a declaration has to say.
- The action, not the endpoint
- `issue.refund`, not `POST /v1/refunds`. A rule written against an endpoint has to be rewritten every time the vendor reshapes their API.
- The system it lands in
- Named, and connected through a credential OpsAI holds. The agent describes the action; it never carries the key.
- The rule that governs it
- A bound, owned by the team carrying the risk. A tool with no bound is not declared, it is merely known about.
- Who it was granted to
- A specific agent, not a role that anything can assume. Reach is issued per agent so it can be withdrawn per agent.
Every action, and what governs it
Keyed on the action, not on the agent.
An action against a system under a rule is one governed thing, whether one agent may attempt it or four. Reading the register this way is what makes the money-moving rows stand out from the rest.
Tool registry
10 actions · 3 carry a ceiling| Action | System | Governed by | Ceiling | Granted to | Write window |
|---|---|---|---|---|---|
| issue.refund | RazorpayRazorpay | refund.ceiling | ₹25,000 | 1 | — |
| post.journal_entry | Zoho BooksZoho Books | close.controls | ₹5,00,000 | 1 | — |
| initiate.payout | RazorpayXRazorpayX | payout.dual_control | ₹2,00,000 | 2 | — |
| update.record | SalesforceSalesforce | write.window | — | 2 | enforced |
| send.email | GmailGmail · customer | comms.approved_templates | — | 3 | — |
| create.vendor | NetSuiteNetSuite | vendor.new_payee | — | 1 | — |
| export.dataset | Amazon S3S3 · analytics | pii.export_block | — | — | — |
| close.ticket | ZendeskZendesk | write.window | — | 3 | enforced |
| adjust.stock | PostgresPostgres · inventory | write.window | — | 1 | enforced |
| read.contract | BoxBox · legal | pii.export_block | — | 1 | — |
Declared actions
10
nothing implicit
Carry a ceiling
3
money or the ledger
Highest ceiling
₹5,00,000
above it, a person co-signs
Write window enforced
3
queued outside it, not denied
IllustrativeThe OpsAI sample estate reaching 10 of 12 connected systems. Every connection and what it permits.
What happens outside the list
Refused before it lands, and still written down.
The interesting half of a permission model is what it does with the calls it does not recognise. 3 things happen, and the second is the one teams do not expect.
- Refused, not recorded for review
- An undeclared action never reaches the target system. There is no window in which it has happened and is awaiting somebody noticing.
- The attempt is still evidence
- A refusal is sealed into the ledger exactly like an authorization. An agent repeatedly reaching for something it was never granted is a signal, and losing it would be the expensive kind of tidy.
- Widening in flight fails too
- A declared action attempted with a wider parameter than the bound permits is refused at the boundary, because the bound travels with the call rather than being checked once at the start.
A write window is a queue, not a denial.
3 of these actions write to a production system and are governed by a window. Outside it they are held until the window opens rather than refused, because the action was legitimate and only the timing was wrong. Denying it would train teams to route around the control; queueing it does not.
Actions carrying a ceiling
3 of 10- issue.refund₹25,000Razorpay · refund.ceiling
- post.journal_entry₹5,00,000Zoho Books · close.controls
- initiate.payout₹2,00,000RazorpayX · payout.dual_control
However it reaches out
MCP
MCP gives an agent reach. The declaration decides what that reach may do, on every call.
Reading, not writing
Data access
A read is a grant too. What an agent may be given is governed separately from what it may change.
Including the refusals
Audit
Every decision is sealed, whichever way it went. A denial is a record, not an absence.
Where to start
Declare what one agent may reach.
Most teams find the first declaration narrower than the access the agent already had. That gap is the finding, and closing it is a single bound.