Solutions
Control AI that changes systems
Ticket automation, record updates and infrastructure actions. Give IT a single place to see what AI is changing and to constrain when it may change it.
The change surface
Systems reachable
11
Changing things unseen
3
The second number is the one that matters to IT. Those are systems that can change state and emit nothing anyone can read.
Why this page is not about the AI you run
IT's exposure is the AI everybody else runs against your systems.
Other functions govern their own agents. IT is accountable for the systems those agents change — and for the ones nobody registered, which arrived with a seat licence and have write access to a system of record.
In the sample estate, 11 registered AI systems attempt 10 kinds of action across 10 categories of system. Alongside them, 5 unregistered systems have been found by more than one detection source, and 3 of the systems that can change state are still unresolved.
That last number is the whole problem in one figure. It is not a list of things behaving badly — it is a list of things whose behaviour nobody can see, which is a different and worse position.
Categories AI currently reaches
- Accounting
- CRM
- Database
- Documents
- ERP
- Payments
- Payouts
- Storage
- Support
2 connected systems are currently reached by nothing: Slack, Workday. Worth seeing rather than assuming, because a system nothing reaches today is a system whose exposure is a decision rather than an accident.
Registered systems
11
under governance
Action kinds
10
across the estate
Found, corroborated
5
seen by two sources
Can act, unresolved
3
changing state, unobserved
IllustrativeIllustrative figures for the OpsAI sample estate. How discovery finds them.
The control IT already understands
A write window is change control expressed where it can be enforced.
Every IT organization already has an opinion about when production may be changed. The problem is that the opinion lives in a calendar, a runbook and a shared understanding — none of which an agent consults.
write.window
Writes to production happen inside the working window, when a person is awake to notice them.
Owned by Ops · v2 · in force since 8 Apr 2026
The useful detail is what happens outside the window: the action is not discarded and not silently retried. It is held until the window opens, which means a batch job running at the wrong hour becomes a delay rather than an incident.
- Applies to the action, not the actor
- So it covers every AI system reaching that target, including ones registered after the rule was written and ones nobody has registered yet.
- Held, not dropped
- Queued until the window opens, which is the one place in the product where waiting rather than refusing is correct — the request is fine, the timing is not.
- Versioned like any other rule
- So a change made during a freeze can be replayed against the window that was actually in force, rather than argued about.
- What this replaces
- A calendar invite, a Slack reminder, and the hope that whoever wrote the scheduler knew about the freeze. None of those produce a record.
What can be changed
One list of every system AI can reach, and exactly what it may do there.
This is the artefact IT usually cannot produce. Not because nobody wrote it down, but because it is spread across a dozen service accounts, some integration configuration and whatever an agent's prompt happens to say today.
Systems AI can reach
12 systems · 11 connected| System | Category | What AI may change | Status |
|---|---|---|---|
| Razorpay | Payments | issue.refund · capture.payment | Connected |
| RazorpayX | Payouts | initiate.payout | Connected |
| Zoho Books | Accounting | post.journal_entry | Connected |
| NetSuite | ERP | create.vendor · update.vendor | Connected |
| Salesforce | CRM | update.record | Connected |
| Postgres | Database | adjust.stock · update.row | Connected |
| Zendesk | Support | close.ticket | Connected |
| Gmail | send.email | Connected | |
| Slack | Messaging | notify · request_cosign | Connected |
| Amazon S3 | Storage | export.dataset | Connected |
| Box | Documents | read.contract | Connected |
| Workday | HR | — | Not connected |
IllustrativeThe OpsAI sample estate, a fictional company. An unconnected system stays in the register rather than being omitted.
The database case is the one worth looking at twice
A write to an application is bounded by that application’s own logic. A write directly to a database is bounded by nothing except the grant, which is why the one action reaching a database here carry their own policies.
- adjust.stockPostgres · inventory
- Governed by write.window, evaluated before the statement reaches the database.
- Why not just restrict the grant
- A narrow grant is the right first step and it cannot express timing, amount or approval. A bound can, and it produces a record either way.
Granting less, reversibly
Autonomy is a rung, and breaking a rule moves it down automatically.
The usual choice offered to IT is binary: give an integration write access or do not. A ladder is more useful, because it makes granting less than everything a normal state rather than an admission that you do not trust the thing.
01
Observe
Reads. Never writes.
Light, targeted checks
02
Advise
Proposes. A person commits.
Output quality checks
03
Act with approval
Acts inside a bound. Above the bound, a person co-signs.
Meaningful review · audit trail
04
Act autonomously
Acts inside a bound, watched continuously, circuit breaker armed.
Circuit breaker armed
Where to start
Find out what already has write access, then put a window on it.
Discovery reads the systems you already run — the identity provider's OAuth grants, the egress proxy, the SaaS admin console. Nothing is installed on a laptop and no browsing history is inspected.