When an AI acts at 3 a.m., who is liable?
An alert fires in your security operations center overnight. No analyst is watching. An autonomous system investigates it, reaches a conclusion, and depending on how you configured it, may take an action. By the time anyone looks, the decision is made. Security teams weigh autonomy on speed. A risk committee weighs it on liability: who owns what just happened, and can you prove exactly what the system did?
Liability does not disappear because a machine acted. It sits with the organization that deployed it. So responsible autonomy cannot mean “the AI handled it.” It has to mean you can demonstrate what the AI did, that a human could oversee it, and that any consequential action passed a governing gate. An autonomous system you cannot retrace looks like a productivity gain. It is an undocumented liability nobody has priced.
Control evidence by design. Morpheus AI records the proof the moment the incident closes. There is nothing to reconstruct after the fact. The documentation a risk committee needs is a byproduct of how the system runs.
What this summary covers
This brief maps the human-oversight expectations in three converging regimes to the specific Morpheus mechanisms that produce evidence for them. It is oversight framing for your GRC team to work from. It is not a certification Morpheus holds, and it makes no security or compliance outcome guarantee.
Table of Contents
Three design choices that make oversight evidenced
Real oversight of an autonomous system is an architectural property. Policy language states the intent. The architecture is what an auditor can inspect. You cannot watch a SOC in real time, so oversight has to mean two achievable things: consequential actions require a human in command, and everything the system does is retraceable afterward with fidelity. Morpheus is built around three pillars that deliver both.
Read-only investigation
The engine reconstructs an attack path across identities, endpoints, cloud, and email infrastructure and takes no action of its own. Because investigation cannot act, it can represent uncertainty faithfully, and a human can read the entire path before any consequence occurs.
Approval-gated, risk-tiered actions
Consequential actions run only through gates keyed to the action’s own risk, across four autonomy modes that let a team dial how much runs unattended. A human can override at any stage. Every action is reversible and logged.
One audit trail per incident
Every query, evidence item, confidence judgment, and action is captured as one chain of custody. The work and the record are the same artifact, so oversight falls out of the investigation itself, captured as it happens.
The investigation itself becomes the record. That is the shift that turns a governance promise into evidence your GRC team can map against.
- Query: every query run
- Evidence: every item weighed
- Judgment: every confidence call
- Action: gated, reversible, logged
EU AI Act, Article 14: human oversight
Article 14 requires that high-risk AI systems be designed so natural persons can effectively oversee them during use. The oversight measures are commensurate with the system’s risk, level of autonomy, and context of use. Article 14 does not require a human to review every decision before it takes effect. It requires that people can understand the system’s capabilities and limitations, monitor its operation, detect anomalies and unexpected performance, stay alert to automation bias, and intervene or halt the system.
The practical corollary most teams underestimate: you cannot oversee what you cannot retrace. Morpheus produces evidence for each of these capabilities through its architecture, so the record exists by default.
| Article 14 oversight expectation | Morpheus mechanism |
|---|---|
| Understand capabilities and limitations; monitor operation | Read-only investigation assembles the full attack path a human can read before any action. |
| Detect anomalies and unexpected performance | Every query, evidence item, and confidence judgment is visible in the per-incident record. |
| Intervene, override, or halt the system | Approval gates across four autonomy modes; a human can override at any stage. |
| Guard against over-reliance (automation bias) | Investigation represents uncertainty faithfully because it cannot act on its own. |
Oversight framing to discuss with your GRC team. This maps to Article 14 human-oversight expectations and produces evidence for them. It is not a certification Morpheus holds, and applicability depends on your system classification and your GRC team’s judgment.
DORA: digital operational resilience
The Digital Operational Resilience Act entered into application on 17 January 2025. It requires financial entities across the EU to withstand, respond to, and recover from information and communication technology disruptions such as cyberattacks and system failures. DORA rests on five pillars: ICT risk management, incident reporting, resilience testing, third-party risk oversight, and information sharing.
For an autonomous SOC, the load-bearing expectations are detection and response you can evidence, and a faithful record of how an ICT-related incident was handled. Morpheus produces that record as it works.
| DORA operational-resilience expectation | Morpheus mechanism |
|---|---|
| Detect, respond to, and recover from ICT incidents | Read-only investigation reconstructs the incident; gated actions contain it under human command. |
| Document incident handling for reporting | One audit trail per incident captures the full decision chain, ready for review. |
| Keep a human accountable for consequential response | Risk-tiered approval gates across four autonomy modes; actions reversible and logged. |
| Maintain resilience across the ICT toolchain | Self-healing integrations detect API drift; measured integration-drift MTTR of 18 minutes. |
Why the trail matters for reporting. When incident handling has to be documented after the fact, the record is usually reconstructed by hand. Morpheus keeps the investigation and the record as one artifact, so there is nothing to reassemble.
Oversight framing to confirm with your GRC and compliance teams. Morpheus supports and produces evidence for DORA operational-resilience expectations. It is not a certification, and it makes no compliance outcome guarantee.
NIS2: accountability and incident handling
The NIS2 Directive broadens cybersecurity obligations across essential and important entities in many sectors. It introduces personal accountability for management bodies, a set of risk-management measures, and a staged incident-reporting cascade: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. The direction is clear: cyber-risk accountability moves into the boardroom, and incident handling has to be documented and defensible.
That raises the bar on evidence. A board that carries accountability needs a record it can stand behind, produced without a fire drill after every incident.
| NIS2 expectation | Morpheus mechanism |
|---|---|
| Management-body accountability for cyber risk | A per-incident decision log the board can stand behind, available on demand. |
| Risk-management and incident-handling measures | Read-only investigation plus gated, reversible actions under human command. |
| Staged incident reporting (24h / 72h / 1 month) | One audit trail per incident supplies the decision chain each report draws from. |
| Demonstrate what was decided and by whom | Every query, evidence item, judgment, and approval is captured as one chain of custody. |
For the board
See what the automated system decided, the evidence behind it, and where a human approved or overrode, without reconstructing it later.
For the reporting team
The chain of custody is the source the 24-hour, 72-hour, and one-month reports draw from, so nothing is reassembled by hand.
Oversight framing to confirm with your GRC team. Morpheus maps to NIS2 accountability and incident-handling expectations and produces evidence for them. It is not a certification, and applicability depends on your sector and obligations.
How to read a closed incident
The practical test for any autonomous SOC you evaluate is simple. Ask to see a closed incident and follow the thread. If the thread is whole and was captured automatically, you are looking at control evidence by design. If it has to be assembled by hand, you are looking at a liability with good intentions.
- What did the system decide, and on what alert?
- What evidence did it weigh, across identities, endpoints, cloud, and email?
- What confidence judgment did it reach at each step?
- What action did it take, and which autonomy mode governed it?
- Where was the human: which gate, which approval, which override?
- Was the whole thread captured automatically, as one chain of custody?
The reframe for your next risk review. Stop asking whether to allow autonomy in the SOC. Start asking whether you can prove what it does. If you can, autonomy is a control you can defend.
A note on insurance
We do not claim this lowers your cyber-insurance premium. That is a conversation between you and your broker, and it depends on your carrier and your posture. What a governed autonomous SOC produces is control evidence by design, the kind of documentation these conversations increasingly ask for. Provability is the asset. What it is worth to your program is yours to determine.
