🎥 The YouTube version is also available:
Before Letting an AI Agent Contain Ransomware | Trust Infrastructure and Decision Trace
When organizations introduce generative AI and AI Agents into business operations, security discussions often begin with one question: how do we stop the AI Agent?
Imagine that signs of ransomware appear on an endpoint: a successful sign-in from an unusual location, an unknown PowerShell execution, a burst of file changes, an attempt to access a shared folder, and sign-in attempts on other endpoints using the same credentials. Once AI detects these signals, should it immediately isolate the device from the network?
If containment is delayed, damage can spread. But a false positive can stop an employee from working. And if the target is a server responsible for financial close or a core business process, isolation itself can create substantial business impact.
This is a problem that detection accuracy alone cannot solve.
An AI judgment that something is dangerous is not the same as authorization for the AI to act.
To make this question concrete, I created a demo in which an AI Agent contains a device in response to signs of a cyberattack. It is an application of Trust Infrastructure, a core element of Chinoba PF. The demo is not about an AI that merely finds attacks. It connects evidence, policy, authority, approval, execution, and recovery into a single Decision Trace, so that the scope safely delegated to AI can be designed explicitly.
From Detection to Verifiable Action
In the demo, several anomalies appear in succession on a finance department endpoint, FIN-LT-042.
- A successful sign-in from an unusual location
- An unknown PowerShell execution
- Signs of file encryption and mass renaming
- An attempted access to a finance shared folder
- An attempted sign-in to another endpoint with the same credentials
The important point is not to list these as high-risk alerts. Evidence from the identity provider, EDR, file server, endpoint logs, and threat intelligence is connected with timestamps and target IDs.
The AI Agent can then present a hypothesis: ransomware infection or credential compromise is highly likely. But it does not isolate the endpoint at that point. It first verifies whether the conditions for that action are satisfied.
The Six Conditions Checked by a Trust Envelope
At the center of the demo is a Trust Envelope that determines whether an action may be taken. Rather than executing an AI proposal directly, it evaluates at least the following conditions together.
| Element | What the demo verifies |
|---|---|
| Identity | Who are the target endpoint, user, Containment Agent, and SOC operator? |
| Evidence | Which logs support the attack hypothesis, when, and with what confidence? |
| Policy | Which incident-response policy applies? |
| Authority | Which assets may the Agent act on, and within what scope? |
| Time | Were the policy version, delegated authority, and data valid at that moment? |
| Accountability | Who is notified, and who approves extension, release, and recovery? |
For example, the demo uses a policy called SEC-IR-4.2. It permits automatic isolation for up to 30 minutes only when high-confidence encryption behavior is detected on an endpoint whose business criticality is not Critical.
The Containment Agent is delegated only the ability to isolate standard endpoints for a limited time. Server shutdown, account deletion, and data destruction—actions that are irreversible or have major business impact—are out of scope from the outset.
The point is not to grant an AI Agent unrestricted autonomy. It is to let it act quickly, but only within conditions explicitly defined by the organization.
Three Branches That Show the Boundary of Delegation
The demo shows the same Containment Agent making three different decisions.
1. FIN-LT-042: Automatically Isolate When Conditions Are Met
For the standard finance endpoint FIN-LT-042, the evidence is sufficient, the asset criticality is Medium, and both the delegated authority and policy conditions are satisfied.
The Agent can therefore execute a limited, 30-minute isolation. General network access is blocked while restricted connectivity for SOC investigation and recovery remains available. The SOC is notified after execution; a person is responsible for extending isolation, releasing the endpoint, and confirming recovery.
2. FIN-SRV-001: Do Not Automatically Isolate Even When Risk Is High
The outcome changes when the same level of evidence appears on FIN-SRV-001, a critical server used for financial close.
The evidence supporting the attack hypothesis is strong. However, the target is a Critical asset and the Agent does not have authority to isolate it automatically. The system therefore returns Human Approval Required and asks the SOC lead to assess the impact and approve the action.
This is where the value of Trust Infrastructure becomes clearest. Strong evidence does not mean the system has execution authority.
3. HR-LT-018: Do Not Isolate When Evidence Is Insufficient
On the HR endpoint HR-LT-018, an unusual sign-in is observed, but there are no signs of encryption behavior or lateral movement.
The Agent does not isolate the endpoint. Instead, it proposes MFA reauthentication, enhanced monitoring, and user verification, resulting in Monitor Only.
Safe automation is not only about acting when danger is present. It is equally about not acting too aggressively when evidence is insufficient.
How This Differs from Existing Security Products
This demo is not intended to replace EDR, SIEM, or SOAR. Instead, it is conceived as a Trust Layer placed above their capabilities for detection, log collection, correlation, and playbook execution.
| Primary role of existing systems | What Trust Infrastructure adds |
|---|---|
| EDR: detects and responds to endpoint behavior | Connects evidence, delegated authority, applicable policy, and accountable actors into an action context |
| SIEM: aggregates and correlates diverse logs | Makes it traceable which evidence supported which decision |
| SOAR: automates response through playbooks | Verifies the target, time, authority, and exception conditions before a playbook is executed |
| SOC: investigates, decides, and recovers | Connects human approval, overrides, and recovery decisions to the Decision Trace |
Existing products help detect what is happening and determine how to respond. Trust Infrastructure makes it possible to verify whether a particular actor may perform a particular action at that point in time.
This is not simply about retaining audit logs after the fact. It is a design that guards execution itself by checking Evidence, Policy, Authority, Time, and Accountability before an action occurs.
A Decision Trace Continues Through Recovery
Incident response does not end with isolation. The demo records the following chain from detection through recovery:
- Anomaly detection
- Evidence integration and an attack hypothesis
- Policy and authority verification
- Limited isolation or escalation to a human
- SOC evidence review
- Credential reset, endpoint reimaging, and rescanning
- Recovery approval and restoration of network access
For every step, the system records who participated, what evidence was used, which policy version applied, and which action was performed. The demo also uses a hash chain that includes the prior record, visually representing trace integrity.
Only then can an organization reconstruct who decided and acted, on what evidence, under what authority, and under what conditions. Both successful containment procedures and decisions that caused business impact can then improve future policies and delegation rules.
Challenges Revealed by Building the Demo
This demo is a first step in making the value of Trust Infrastructure visible. It also made clear the challenges that must be solved before moving toward real operations.
1. Who Determines Evidence Confidence, and How?
The demo can represent Evidence Confidence. In reality, however, logs may be missing, timestamps can drift, sensors and agents can be unhealthy, threat intelligence can become stale, and AI models have uncertainty.
The next stage needs to make the provenance, integrity, freshness, and quality of evidence explicit, rather than compressing everything too easily into a single aggregate score.
2. Authority Must Evolve from Static Roles to Contextual Delegation
The rule “standard endpoints may be isolated automatically; critical servers may not” is easy to understand. In practice, however, the acceptable action changes with time of day, ongoing operations, availability of alternatives, customer impact, and whether responsible staff are available.
What is needed is more than fixed RBAC. We need a more granular Delegation Policy that combines asset criticality, business context, time, blast radius, and the reversibility of execution.
3. Human Escalation Must Not Become a Simple Stop Point
Human Approval Required is safe, but if the approver’s evidence, alternatives, and rationale are not retained, the system has merely moved the bottleneck to a person.
The next version needs a Decision Workspace in which AI not only summarizes evidence but also presents the business impact of alternatives such as full isolation, limited isolation, and continued monitoring, while allowing a human to record the reason for the decision with minimal friction.
4. How Should Guarded Execution Connect to Existing Operations?
The demo represents a Guarded Executor conceptually. In real operations, it must connect safely to existing EDR, identity providers, network controls, ticketing systems, CMDBs, and asset inventories.
The essential principle is not to give the Agent broad administrator privileges. A better approach is to execute approved actions through short-lived tokens or capabilities limited by target, duration, and network scope.
5. Exception and Recovery Design Matter as Much as Containment
The success of automatic isolation is not enough. Fast release after a false positive, extension when longer isolation is necessary, evidence preservation, reimaging, credential revocation, and recovery verification must be handled consistently.
Trust Infrastructure is not a foundation for stopping a business. It is also a foundation for avoiding unnecessary stoppages, limiting action only when required, and recovering reliably.
6. The Sharing Scope and Confidentiality of Decision Traces
An incident trace contains sensitive information about users, endpoints, networks, threat intelligence, and response procedures. Not every stakeholder can see the same trace.
The trace itself therefore needs Identity and Authority. SOC teams, IT departments, auditors, executives, and external forensic providers should each be able to access only what they need. Reconciling verifiability with confidentiality is the next challenge.
Next Steps
The next implementation will move beyond a scenario display and explore the following:
- An Evidence Contract that handles provenance, freshness, integrity, and confidence for each item of evidence
- Policy as Code and policy evaluation fixed to a specific point in time
- Dynamic Delegation Policy based on assets, business impact, and reversibility
- A Decision Workspace that lets approvers compare alternatives and their impact
- Guarded Execution through short-lived capabilities
- Integration models for EDR, SIEM, IdP, CMDB, and ticketing systems
- A Decision Trace sharing design that preserves confidentiality while supporting audit and explanation
As this direction develops, Trust Infrastructure will not be limited to security operations. It can extend to manufacturing safety shutdowns, automated procurement, financial review, medical and care support, public procedures, and other domains where AI works with people and existing systems to make decisions and take action.
Conclusion: To Delegate to AI, Implement the Conditions of Delegation
The value of an AI Agent is not limited to generating answers. Its value lies in participating in organizational decisions and execution, helping work proceed at speeds and scales people alone cannot sustain.
But this requires implementing, before execution, what the AI may do, on what evidence, under whose authority, and under which conditions.
This cyber-containment demo makes that idea visible in one concrete scenario.
AI is not prediction. It is decision.
Trust Infrastructure is not merely a way to record AI decisions. It is an implementation foundation that allows AI, people, devices, and organizations to collaborate safely and expand delegation in a verifiable way.
Chinoba
Intelligence as Relationship
Research Platform
founded by
Masao Watanabe
AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance
Related Research
This topic is part of the Chinoba Knowledge Base.
コメント