A governance layer that the AI can talk its way past is not a governance layer. It is a suggestion. This framework is built on the assumption that the model will, eventually, be wrong in a way nobody anticipated — and that the system must be safe anyway.
1. The question a CISO is actually asking
Security reviews of autonomous operations platforms fail for a predictable reason. The vendor arrives prepared to discuss model accuracy; the CISO wants to discuss authority. These are different conversations, and only one of them determines whether the deployment gets approved.
Reduced to its essentials, the CISO is asking four questions:
- What is the complete, enumerable set of actions this system can ever take on my estate?
- Who authorised each one, when, and how do I revoke it?
- What prevents an action outside that set — technically, not procedurally?
- After the fact, can I reconstruct exactly what happened and why, to an evidentiary standard?
An architecture that gives a model a set of tools and lets it reason about which to invoke cannot answer question one, because the answer is “whatever the model decides.” That is acceptable for a coding assistant. It is not acceptable for a system holding privileged credentials on production database servers.
2. Principle one — the model selects, it never authors
The core inversion of this framework is that every action the platform can ever take exists as a declared policy object, authored by a named human, peer-reviewed, and cryptographically signed before it enters the runtime. The AI layer’s role is diagnostic: given a set of signals, identify the incident class and select the matching policy. If no signed policy matches, the outcome is escalation to a human — never improvisation.
This gives an exact answer to question one. The set of possible actions is the policy library, and it is enumerable, exportable, diffable, and reviewable in a change advisory meeting. It also makes question three tractable: preventing an action outside the set is a matching problem, not a behavioural guarantee about a model.
Stage 05 deserves particular attention, because it is where most naive automation fails. Alerts age. An alert raised four minutes ago may describe a condition that has already self-resolved, or one that has escalated into something the policy was not written for. Preconditions are therefore re-evaluated against live state immediately before execution, not against the state captured at alert time. This single rule prevents the classic automation failure of confidently fixing a problem that no longer exists.
3. Anatomy of a signed policy
A policy is a declarative object with six mandatory sections. None of them is optional, and the object will not validate — let alone sign — if any is empty.
| Section | Contains | Why it is mandatory |
|---|---|---|
| Match criteria | Signal signature, asset scope, environment tags | Defines exactly when this policy is eligible; scope creep is the most common source of surprise |
| Preconditions | Assertions re-evaluated against live state at execution time | Prevents acting on a stale or changed condition |
| Action | Exact command, script, or API call with parameters bound from incident context | Removes runtime improvisation — the command is reviewable in advance |
| Blast radius | Maximum asset set touchable in one execution, plus a rate limit | Bounds the worst case even if diagnosis is wrong |
| Rollback | The inverse operation, and the state capture required to make it possible | A policy with no defined inverse can never be autonomous |
| Approval class | Autonomous, notify-and-act, approve-then-act, or human-only | Derived from reversibility and blast radius — see §4 |
Table 1 — The six mandatory sections of a policy object.
4. Deriving the approval class
Approval class is not a field an author chooses. It is derived from two properties of the action — whether it is reversible, and how wide its blast radius is — and the author can only make it stricter, never looser.
The two axes are deliberately crude. A finer-grained risk model would be more accurate and far less useful, because a change advisory board has to be able to reason about it in a meeting. Every enterprise we have worked with has understood this matrix in under five minutes, which is worth more than precision.
Confidence gating and graceful degradation
Every diagnosis carries a confidence score derived from signature match strength, historical resolution success for that signature on that asset class, and signal completeness. Policies declare a minimum confidence. Below it, the action does not fail — it downgrades one class. An autonomous policy becomes approve-then-act; approve-then-act becomes human-only.
This behaviour is what makes the system usable in practice. A binary allow/deny gate produces either reckless automation or an escalation flood. Graceful degradation keeps a human in the loop precisely when the machine is least sure, and keeps the queue quiet when it is confident.
5. The signature lifecycle
Treating a policy as a permanent artefact is a mistake we made in an early version and corrected. Estates change; a policy that was safe when written can become dangerous when a schema is renamed or a service is re-platformed. Signatures therefore expire.
The expiry window is configurable and defaults to 90 days, aligning to a typical quarterly control review. At expiry the policy becomes inert — the engine will not match against it at all. It does not degrade to a lower approval class, because a silent downgrade is exactly the kind of behaviour that erodes trust in a control.
Re-attestation is deliberately lightweight: the owner is presented with the policy, its execution history since last attestation, any matched-but-refused events, and a diff against the estate’s current configuration. In practice this takes a few minutes per policy per quarter, and it surfaces drift that nobody would otherwise have looked for.
“An unsigned or lapsed policy is not degraded. It is inert. Anything else and the control becomes advisory the moment somebody is busy.”
Priya Ramesh, CTO
6. Audit evidence as a first-class output
For every decision — including decisions not to act — the platform writes an append-only, hash-chained record. This is not logging. It is the artefact that answers question four, and it is what moved three regulated security reviews from months to weeks.
| Record field | Purpose in an audit |
|---|---|
| Input signals with source and timestamp | Establishes what the system knew and when |
| Diagnosis, confidence, and supporting evidence | Shows the basis for the classification |
| Policies considered, with match/no-match reason for each | Demonstrates deny-by-default rather than asserting it |
| Gate results — confidence, class, freeze, blast radius | Shows which controls were evaluated and their outcome |
| Precondition evaluation against live state | Proves the action was verified immediately before execution |
| Command executed with bound parameters | The action itself, reviewable against the signed policy |
| Captured rollback state | Demonstrates reversibility was materially available, not theoretical |
| Observed outcome and recovery signal | Closes the loop on whether the action worked |
| Policy signature identity and validity at execution time | Attributes the authority under which the action ran |
Table 2 — Contents of a decision record. Records are hash-chained, so tampering is detectable.
The field auditors ask about most often is the third one: policies considered and rejected. Recording only what happened proves the outcome. Recording what was considered and refused proves the control was operating.
7. Control framework alignment
This framework is designed to be mapped into existing control environments rather than to sit beside them. The alignment below is how our customers have presented it to their own auditors; it is offered as a starting point, not as a certification claim.
| Framework / regulation | Relevant area | How this framework maps |
|---|---|---|
| NIST AI RMF 1.0 | Govern, Map, Measure, Manage | Signed policy library = Govern; incident classification = Map; confidence and outcome telemetry = Measure; approval classes and rollback = Manage |
| ISO/IEC 42001:2023 | Clause 8 — operational planning and control | Policy lifecycle, signature expiry, and re-attestation provide the documented operational controls |
| ISO/IEC 27001:2022 | A.5.15 access control, A.8.32 change management | Approval classes and two-person policy review sit inside existing change management |
| SOC 2 (AICPA TSC) | CC6 logical access, CC7 system operations, CC8 change management | Hash-chained decision records serve as the evidence population for CC7 and CC8 testing |
| ITIL 4 | Incident, problem, and change enablement | Autonomous classes map to standard changes; escalations map to normal changes |
| NIST SP 800-53 Rev. 5 | AU (audit), CM (configuration management), SI (system integrity) | AU-2/AU-9 satisfied by append-only chained records; CM-3 by policy change control |
| RBI IT Governance Master Direction (Nov 2023) | IT and information security governance for regulated entities | Named accountable owner per policy; change control retained; audit trail available on demand |
| DPDP Act, 2023 (India) | Data localisation and processor obligations | Client-local inference means operational telemetry does not leave the estate |
| EU AI Act (Reg. (EU) 2024/1689) | Human oversight, logging, transparency obligations | Human authorship of every action, mandatory logging, and disclosed model role in diagnosis |
Table 3 — Control alignment. Cited for mapping purposes; AAQUILIX makes no certification claim on a customer’s behalf.
8. Sector-specific applications
9. Reducing human effort without reducing human authority
There is a persistent assumption that governance and efficiency trade off against each other — that every gate you add costs you automation. The data from our deployments does not support this, and the reason is worth spelling out.
Human effort in incident response decomposes into four activities: noticing, diagnosing, deciding, and executing. Governance concerns itself almost entirely with deciding. Noticing, diagnosing, and executing carry no meaningful governance content — nobody has ever required a change advisory board to approve reading a log file.
In the estates we measured, deciding accounts for roughly 8% of the human time spent on a routine incident. The other 92% is noticing, diagnosing, and executing. This means an estate can retain a named human decision on every single production change — the strictest possible posture — and still remove more than nine-tenths of the effort. Banking estates prove this: they sit at the lowest autonomy rate of any sector and still record the largest reduction in engineer hours per incident.
10. First ninety days — a governance checklist
- Name a policy owner for each of the eight failure classes. Ownership is individual, not team-level; an unowned policy cannot be re-attested.
- Declare hard boundaries before writing any policy — OT systems, regulated schemas, anything with a safety case. Mark them human-only and make that non-overridable.
- Run observe mode for a minimum of seven days. Compare every proposed action against what your engineers actually did, and treat disagreements as the primary output.
- Require two-person review on the allowlist and scope fields specifically. These are where scope creep enters, and a junior engineer widening an allowlist should not be a single-person action.
- Activate no more than four policy classes first, chosen for high volume and unambiguous reversibility. Narrow activation makes the first month’s results attributable.
- Agree the audit evidence format with internal audit before go-live, not after the first incident. Export a sample decision record and have them confirm it is sufficient.
- Set signature expiry to match your existing control review cadence so re-attestation lands in a meeting that already happens.
- Define the escalation path for a matched-but-refused event. Refusals are the control working, and they need an owner or they become noise.
The item most often skipped is the sixth. Agreeing the evidence format with audit before go-live costs an afternoon and has, in every deployment where we did it, removed the single largest source of post-deployment friction.
References & further reading
- NIST AI Risk Management Framework (AI RMF 1.0) National Institute of Standards and Technology, January 2023
- ISO/IEC 42001:2023 — Artificial intelligence management systems International Organization for Standardization
- ISO/IEC 27001:2022 — Information security management systems International Organization for Standardization
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls National Institute of Standards and Technology
- SOC 2 Trust Services Criteria AICPA & CIMA
- Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices Reserve Bank of India, November 2023
- Digital Personal Data Protection Act, 2023 Ministry of Electronics and Information Technology, India
- Regulation (EU) 2024/1689 — Artificial Intelligence Act Official Journal of the European Union
Quantitative figures in this paper are measured from AAQUILIX production deployments and anonymised customer estates unless a third-party source is cited inline. Standards and frameworks referenced are cited for control alignment, not as the source of our measurements.
AI Governance in IT Operations · v2.0 · published 11 May 2026. Questions or a challenge to any figure in this paper are genuinely welcome — get in touch.