Platform
Connect the AI you already run
Bring existing agents, AI applications, models, automation and MCP tools under one control layer. No replacement AI stack, no rebuild.
How a system comes under control
Six steps, and none of them is a rebuild.
The order matters more than the steps. Naming the accountable person comes second — before a credential is attached and before a single rule is written — because a system whose owner is settled last is a system nobody chose to own.
Register the systemno rebuild
Declare the agent, application, model or job that already exists. However it was built, and whoever built it.
Name who answers for itaccountability first
A person, not a team alias and not a service account. Everything below this point inherits from that name.
Attach an identity
The system gets an attested workload identity, so a later decision is about this system rather than about whoever holds a key.
Declare what it may reachthe agent never sees the key
Which systems, which datasets, which tools, which actions. OpsAI holds the credential from here on; the system holds a request.
Set the bounds
The team that carries the risk writes the rules, in the language of the business. Replay them against past activity before publishing.
Watch the first actionsraise on evidence
Start at an autonomy level you are comfortable with and raise it on evidence. Every decision is on the record from the first one.
What does not change.
- No SDK rewrite
- A connected system keeps its own control flow. OpsAI sits at the boundary where it calls out, not inside its loop.
- No credential handling
- The key moves out of the agent and into OpsAI. From then on the agent sends a request and receives a decision — it never holds the secret it used to.
- No migration
- Salesforce stays Salesforce. OpsAI is in front of the call to it, not in place of it, so there is nothing to move and nothing to re-point.
- No all-or-nothing
- Connect one agent, at the autonomy level you are comfortable with, and raise it when the record gives you a reason to.
What can connect
Whatever your teams already chose.
OpsAI has no preferred framework and no preferred provider. The systems below are the ones an enterprise typically already runs, and the layer is the same for all of them.
Enterprise systems in the sample estate
RazorpayRazorpay
RazorpayXRazorpayX
Zoho BooksZoho Books
NetSuiteNetSuite
SalesforceSalesforce
PostgresPostgres
ZendeskZendesk
GmailGmail
SlackSlack
Amazon S3Amazon S3
BoxBox- WorkdayWorkday
However it was built
Agents
Who owns it, which model it calls, what it can reach, and what it has actually been doing.
However it reaches out
MCP
MCP gives an agent reach. OpsAI decides what that reach may do, on every call.
Whoever provides it
Models
Every model your organization calls, with the owner who approved it and the rule that constrains its use.
The change worth understanding
OpsAI holds the credential. The agent holds a request.
This is the single structural difference connecting makes, and everything else follows from it.
The agent holds the key.
Whatever the key can do, the agent can do. A prompt that talks it into a wider action succeeds, because nothing between the agent and the API is in a position to refuse. What was allowed is whatever the token was scoped to, months ago, by whoever created it.
The agent asks, and OpsAI decides.
The agent never sees the secret. It describes the action it wants; identity, accountability, policy and risk are resolved; and the call goes out with the bound attached, so it cannot widen in flight. Either way the decision is on the record before the response returns.
Credentials are held centrally, attested, and rotated on a schedule rather than when someone remembers. How identity and credentials work · What it means for a bound to travel with the call
The systems it reaches
Every connection, with the actions it permits.
A connection is not access to a system. It is a named set of actions against that system, and anything outside the set is refused rather than logged.
Enterprise connections
11 of 12 connected| System | Category | Actions it permits | State |
|---|---|---|---|
| RazorpayRazorpay | Payments | issue.refund · capture.payment | Available |
| RazorpayXRazorpayX | Payouts | initiate.payout | Available |
| Zoho BooksZoho Books | Accounting | post.journal_entry | Available |
| NetSuiteNetSuite | ERP | create.vendor · update.vendor | Available |
| SalesforceSalesforce | CRM | update.record | Available |
| PostgresPostgres | Database | adjust.stock · update.row | Available |
| ZendeskZendesk | Support | close.ticket | Available |
| GmailGmail | send.email | Available | |
| SlackSlack | Messaging | notify · request_cosign | Available |
| Amazon S3Amazon S3 | Storage | export.dataset | Available |
| BoxBox | Documents | read.contract | Available |
| WorkdayWorkday | HR | — | Planned |
- Razorpay · Payments
- Refunds and payment captures. OpsAI holds the API key; the agent never sees it.
- RazorpayX · Payouts
- Outbound money movement. Every payout above two lakh needs a named co-signer.
- Zoho Books · Accounting
- Journal entries, bounded by account, size and whether the period is still open.
- NetSuite · ERP
- Vendor records. New payees cool for twenty-four hours before money can move.
After the first connection
The first one usually tells you something.
Most teams find their agent is reaching for more than anyone realised. That is the moment a bound is easy to write, because you are describing something you just watched happen.