Resources

Supervised by default, with a named human owner. Trust tiers raised on evidence, server-side transcripts with redaction, action-count budget caps and an emergency stop - now with many instances behind one agent, lanes, governed release rollovers held in the approval funnel, the approval context that shows why a change was raised, and an AI management system aligned to ISO/IEC 42001.

• ✓Three trust tiers - Advisory, Supervised, Autonomous - granted per asset, environment, or project; supervised is the default and autonomy is earned on recorded evidence.
• ✓A named accountable human owner for every AI agent; every action attributable to both.
• ✓One agent, many instances, in lanes - the platform picks the instance; a shadow lane runs the same work with every write forced to advise.

Learn how OpsChain helps banking and financial services organisations meet PCI-DSS and APRA CPS 234 requirements while automating change governance.

• ✓PCI-DSS compliant change management workflows
• ✓APRA CPS 234 information security alignment
• ✓Tamper-evident, hash-chained audit history for regulatory evidence

Approvals enforced, not hoped for. Approval-as-policy bound to the estate path - quorum, self-approval exclusion, change windows with audited overrides - a checklist frozen at creation, the approver sees why a change was raised, every decision in the history, and the reason a step failed on the step itself.

• ✓Approval-as-policy on your environment paths - quorum enforced, self-approval excluded by the platform, a checklist frozen at creation so no later policy edit can loosen a pending change.
• ✓The approver sees why - the rationale, the recommendation the change implements, who raised it and in which tier, and the correlation chain behind an agent's work.
• ✓Decision history - an approver reviews their own past decisions; the governance administrator reviews every decision, exportable line by line.

Cloud and identity operations as governed actions, signed by LimePoint. The AWS, Azure and PingOne Advanced Identity Cloud content packs and the MintPress SDK - what each governs, the entitlement that unlocks it, and the rules every pack obeys: signed, vault-custodied credentials, self-sufficient on a fleet, references visible before a delete.

• ✓AWS (packs:aws) - ten services as 1,600+ typed operation actions and 90+ waiters from the official SDK, aws:api for any operation, curated lifecycle actions; credentials from the vault, masked
• ✓Azure (packs:azure) - the ARM management surface as 1,700+ typed actions plus azure:api for any resource provider and API version; deployments, VM provisioning and run-command, blobs and resource groups curated; long-running operations report progress
• ✓PingOne Advanced Identity Cloud (packs:ping-aic) - a tenant's configuration as YAML reconciled by plan, apply and export; identities, service accounts, environment secrets, tenant logs and environment promotion as typed actions

Integrations that don't leak authority. Tool-agnostic automation out of the box - Terraform, Ansible, scripts, RPC - plus shipped connectors for ITSM, GitHub, SIEM, vaults, identity and notifications, and signed content packs for AWS, Azure and PingOne Advanced Identity Cloud. Inbound signed and replay-protected, outbound credentials just-in-time, every crossing audited.

• ✓Tool-agnostic execution out of the box - Terraform, Ansible, Bash, Python, Java, CLIs and RPC connectors shipped as ready-to-use action packs
• ✓Signed content packs - AWS, Azure and PingOne Advanced Identity Cloud as native governed actions, signed by LimePoint and unlocked by entitlement; author your own with the MintPress SDK
• ✓Inbound events signed and replay-protected, executing as named service accounts - never an ambient admin

Governed operations that stay available - multi-server active HA, automatic takeover of in-flight work, multi-site operation with site affinity, near-zero-downtime upgrades, and rehearsable disaster-recovery tiers.

• ✓Multi-server active high availability - multiple servers against one governed estate, coordinated with fenced leases; no idle standby, no split brain
• ✓Automatic takeover of in-flight work - lose a server mid-run and a surviving server drives the run to completion, in the same audit lane
• ✓Runners that ride through failure - ordered server lists and failover keep scheduled work flowing through maintenance and outages

Who can act, what they can touch, and the evidence that the controls held. Path-based RBAC, vault custody of secrets, a hash-chained tamper-evident ledger that now records the origin of every action, a signed and verifiable supply chain, and secure-development practice attested against OWASP and ISO/IEC 27001 Annex A on every release.

• ✓Path-based RBAC & per-identity policy - explicit authorisation on every request, per path and identity.
• ✓OIDC and LDAP identity providers plus local accounts, managed sessions, and step-up authentication for sensitive operations.
• ✓Vault custody of secrets - built-in or your own - never inlined into automation, masked in every log.

Learn how OpsChain helps telecommunications providers govern network change management across 5G, IMS, and hybrid infrastructure.

• ✓IEC 62443 aligned network change governance
• ✓5G and IMS infrastructure automation support
• ✓Cross-domain orchestration for network and IT operations

Learn how OpsChain helps utilities and energy companies meet NERC CIP and IEC 62443 compliance requirements while automating operational change management.

• ✓NERC CIP compliance-ready change governance
• ✓IEC 62443 aligned security controls
• ✓Automated audit trail generation for regulatory reporting

GitHub Actions is built for CI. OpsChain is built for governed operational change. How the two compare for operations work - and how the GitHub connector makes them stronger together.

• ✓CI pipelines vs. governed operations - Actions ships your code; OpsChain changes your estate under enforced approval policy
• ✓Repository-scoped permissions vs. estate-path authorisation with quorum, change windows, and audited overrides
• ✓Workflow logs vs. a hash-chained, tamper-evident audit lane with legal hold and SIEM streaming

JSM runs your service desk. OpsChain executes the change behind the ticket - governed. How the two compare, and how the JSM connector turns tickets into governed runs with evidence written back.

• ✓Service desk vs. governed execution - JSM tracks the request; OpsChain governs and executes the change it asks for
• ✓Approval workflows on tickets vs. approval-as-policy enforced on the estate path where the change runs
• ✓Ticket comments and history vs. a hash-chained, tamper-evident execution record with legal hold

ServiceNow records change. OpsChain executes it - governed. How the two compare, and how the ServiceNow connector closes the loop between change approval and change execution.

• ✓Record-keeping vs. governed execution - ServiceNow confirms a change was approved; OpsChain enforces the approval on the execution itself
• ✓Native execution engine with tool-agnostic automation vs. third-party integration and scripting
• ✓Approval-as-policy bound to the estate path vs. approval workflows disconnected from what actually runs