Governance
Agent governance
AI agents join your team in the same way as a new engineer. Each has its own identity and explicit permissions, is supervised by default, and earns trust through evidence. Agents work within the same approval policies and the same audit lane as your staff, and an emergency stop is always available in one action.
Governed like any member of staff
Many organisations build the agent first and add security and governance later. OpsChain reverses that order. Identity, contract, supervision, evidence and offboarding are in place before the agent does anything, so AI agents can be embedded in your organisation like any other team member.
| An employee has | Your AI team member has |
|---|---|
| A badge | Its own identity and credentials. No shared accounts. |
| An employment contract | A scoped grant that defines what it may access and for how long |
| A manager | A named human supervisor who approves its work |
| A probation period | Supervision first. It proposes before it acts. |
| Spending limits | Hard limits. Every refusal is recorded and visible. |
| A code of conduct | Policy rules enforced on every request |
| Company equipment | Model access brokered by the platform. Keys are never handed over. |
| An HR file | A tamper-evident audit history of everything it did |
| Performance reviews | Evidence you can query, cite and attest |
| Offboarding | A clean end of engagement with a full handover, and an emergency stop when needed |
Onboarded, supervised, audited and offboarded.
A force multiplier for your operations team
Your best operations engineers carry knowledge that no platform can replicate: the systems, their history and the edge cases that only come with experience. The challenge is scale. That expertise has to be applied across a complex, always-on environment without exhausting the people who hold it.
Governed AI agents address this. Your experts define the boundaries and own the operators. The operators extend their reach, apply their runbooks at scale, and refer every consequential decision to a human until the evidence supports more autonomy. Your team stays in control and the operators handle the volume.
Three trust tiers
Trust is granted per asset, environment or project. You start at a conservative tier, raise autonomy on recorded evidence, and can reverse it in one action. Supervised is the default, and autonomy is always an explicit decision.
Advisory
What it means
The operator analyses the situation and reports what it would do and why. Your team makes the decision.
When to use it: While building confidence in a new operator, or when working on sensitive systems
Supervised
What it means
The operator prepares everything needed to act and hands it to your team. Your team executes.
When to use it: When you want the efficiency of AI with human authorisation at the point of execution
Autonomous
What it means
The operator acts within the boundaries you have defined, handles the outcome and reports back.
When to use it: When the pattern is proven by evidence and speed matters more than pre-approval
Every tier produces a complete server-side transcript of what the operator saw, decided and did. No action is hidden.
Controls for enterprise operations
A named accountable human owner
Every AI agent is owned by a named human. Every action is attributable to the operator and its owner. There is no anonymous automation.
The same controls as your staff
Operators authenticate with their own identity, act under the same path-based authorisation, pass the same approval policies and are recorded in the same audit lane as every human operator.
Platform-enforced boundaries
Define what each operator is permitted to do, when, and across which scope. The platform enforces the boundaries. They do not depend on the operator’s cooperation. Overrides are explicit, permission-checked and audited.
Server-side transcripts with redaction
What the operator saw, what it decided and what it did is recorded on the server, where the operator cannot alter it. Sensitive values are redacted.
Rate and budget caps
Budgets are action counts. A misbehaving operator exhausts a bounded, audited budget and is contained.
An emergency stop in one action
Stop one operator, a group or the whole fleet immediately. A reason is required, the stop is audited and the control is protected by step-up authentication. Halting is the first response to a suspected problem.
Your own keys and model host
Model credentials are held in the operator deployment you own. The platform does not hold them. Hosted and local models are both supported, so the choice follows your data-governance requirements.
A complete audit trail
Every operator action, whether advisory, supervised or autonomous, is recorded in the same hash-chained, tamper-evident history that covers all change in your environment.
Two ceilings and a governed raise
A grant records what was intended. A ceiling sets what is permitted regardless of the grant. The decision to raise a ceiling also runs through governance.
The type ceiling
AI agents ship capped at the supervised tier. Whatever the grant, unattended AI change is never the default. Raising the ceiling is an explicit, audited decision for the estate.
The classification ceiling
Assets your estate metadata marks as critical can impose their own cap. If a system is classified as critical, no grant exceeds the ceiling that classification carries. The most restrictive ceiling applies, and a reclassification takes effect on the operator’s next request.
The governed raise
Raising an operator’s authority is a governed change. The raise is held for approval in the same funnel as production change, supported by the operator’s recorded track record. An unapproved raise does not take effect. Lowering authority takes one action.
Governance before enrolment: licensing and signed releases
No embedded LLM without a licence
AI capability is delivered only in the AI entitlement packs. An estate that does not licence them has no embedded LLM anywhere in the product, and an AI agent cannot enrol. The refusal is recorded and audited before any identity exists. An estate that is licensed but runs no agents exposes nothing.
The emergency stop and the audit trail are part of the base platform and do not depend on the packs.
Signed releases promoted as governed change
An operator ships as a signed release. Its manifest and artifact are signed and verified against your key registry, and a tampered or unsigned build is refused at enrolment. Releases are promoted one stage at a time, from development to test to production, and are verified again at each stage. The production promotion is held for human approval in the same funnel as every other change.
The identity your governance acts on is also a build with attested provenance. Fleet and trust reviews show which release each operator runs, and at which stage.
The bundled OpsChain SME
The pack includes a working Digital SME from day one, which answers questions about the product. It answers from the documentation built into your server. The documentation is version-matched, so the SME does not describe a feature your build does not have, and entitlement-gated, so it does not describe a feature you have not licensed.
Estate questions are answered under the asking user’s own authority. The same question from two users produces two answers, each limited to what that user may see. The SME cannot widen any user’s view.
It ships as a signed release, is capped at the supervised tier, seals and redacts its transcripts, and has no write capability.
It is also the reference implementation. Your own Digital SMEs are built from the same governed pattern, SDK and hardened image.
Worked scenario: Felix and a 2 a.m. incident
LimeBank is a fictitious retail bank from our Lime Group worked scenario. It lets us show real mechanisms on a realistic estate without showing any customer's production environment.
The incident
A 2 a.m. alert is raised on LimeBank’s core-banking estate. The estate’s own classification marks the asset as critical, with provenance, so the platform already holds the asset’s criticality before anyone decides how to respond.
The diagnosis
Felix, the bank’s Digital SME, investigates under tiered read access. It reads only what its grant permits. Every read is recorded and the reasoning is captured in the transcript.
The proposal
At the supervised tier, the most Felix can do is propose. The remediation is created as a held change in the same approval funnel as human change, requested by Felix’s service account and stamped with the applied tier.
The humans decide
The CAB approves. The asset owner approves the strict patch-assurance line. A maintenance window admits the change. A named approver releases the tier gate carried by Felix’s grant. Four human decisions, each recorded.
The evidence
The run executes under Felix’s service account. The export is a CAB packet for a change that an AI requested and humans released. It is fingerprint-stamped and includes the sealed, redacted transcript and the operator’s full activity timeline.
The same scenario runs live in our demo, including the enrolment refusal, the cap refusal, the redacted transcript and the halt drill.
The risk committee checklist
Who owns this operator? A named accountable human, recorded on the operator.
What can it access? Only what its explicit authorisation grants, per path and per identity.
Who approved its changes? The quorum your approval policy requires, with self-approval excluded.
What did it do? Server-side transcripts and a hash-chained, tamper-evident history record every action.
What if it misbehaves? Action budgets are bounded, and an emergency stop covers one operator, a group or the whole fleet.
Where did it come from? A signed, verified release, promoted to production under human approval.
These answers support the evidence you take to ISO 27001 and SOC 2 audits, and to CPS 230/234, SOCI and TSSR discussions.
A governed operator in a live demo
We run an operator through a realistic scenario in a governed environment: a supervised proposal, human approval, execution inside a change window, and the audit trail behind it.