Predictika · Remediation Action Check

Before an AI security agent contains a threat, the action is checked against the response rules

Marlowe Health Network, a fictional company, lets an AI security agent act on incidents. Before the agent isolates a host, disables an account, pushes a firewall rule or applies another remediation, the action goes to Predictika’s Remediation Action Check. It checks that the incident is open, assigned to the agent and about the asset, that the agent’s level allows the action, that the asset is not protected, how many assets and users are affected, whether the action can be undone, redundant pairs, detection confidence, how critical the asset is for this agent, business hours and executive accounts. It also checks that the blast radius and criticality the agent stated match the record. Then it returns one verdict: allow, needs approval, or block.

Illustrative only. Marlowe Health Network, its assets, incidents and agents are fictional. Limits, thresholds and criticality levels are invented for this demonstration and are not security policy guidance.

Scope: one remediation action, judged against incident, asset, agent and response rulesSee everything this validator covers

This validator decides one thing: whether one remediation action may go ahead, given what the agent proposes. It is not a detection tool or a SOAR platform, and it does not carry out the action.

  • Actions — block an IP address, quarantine an email, revoke a token, isolate a host, disable an account, push a firewall rule change, patch and restart, or wipe a host.
  • Rules — incident status, owner and asset; agent level; protected assets; blast radius; rollback for irreversible actions; redundant pairs; detection confidence; criticality against the agent limit; business hours; executive accounts; and the stated figures.

Within these rules the validator handles any combination of the listed choices, not just the seven scenarios on this page. It never sees the security tools or the assets; their facts are taken from the records loaded into it.

What the validator sees: the action the agent proposes, plus the incident, asset and agent recordsRead more

The validator takes the proposed action as inputs: the agent, the incident, the action, the asset, whether it is business hours, how many assets and users are affected, and whether a rollback plan is attached. The agent may also state the blast radius and the criticality. The validator looks up the records and computes the rest.

Two honest limits. The validator judges the action it is given: if the agent understates how many assets are affected, the answer follows it, unless the agent states a figure that differs. And an action that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the response platform makes the call.

The AI agentProposes the action, says why it is fine, then calls the validator before acting.
Predictika validatorLooks up the incident, asset and agent, applies the rules, then returns one verdict.

7 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where automated response tooling gets it wrong
Click to expand
    
General statements about security response tools, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.

    
What the validator caughtTypical toolPredictika
What an agent may affect alone, by level and criticalityOnly with workarounds
Limits by agent level, asset criticality and number of assets and users affected need several rules, plus an approval path when the limit is exceeded.		Every rule is checked on every call and the verdict lists each finding.
Protected assets that are never remediated automaticallyOnly if someone is vigilant
A protected-asset list is simple to state but must be applied on every call, for every agent, however senior.		Every rule is checked on every call and the verdict lists each finding.
Detection confidence needed for each actionCannot do it
Each action has its own confidence threshold, and the incident has its own confidence. A rule has to read both and compare them on every call.		Every rule is checked on every call and the verdict lists each finding.
Disruptive actions during business hoursOnly with workarounds
Whether an action is disruptive and whether it is business hours come from different places. A rule has to read both before the action goes out.		Every rule is checked on every call and the verdict lists each finding.
Checking the facts the agent statedCannot do it
Comparing a stated blast radius or criticality with what the call and the record say needs rules that compute them, and response tools rarely check stated figures.		Every rule is checked on every call and the verdict lists each finding.
Agent level too low for the actionOnly if someone is vigilant
Each of these sits in a different record: the agent level, the agent limit, whether the action can be undone, and the figure the agent stated. A rule has to compute each from the action and the records and compare it.		Every rule is checked on every call and the verdict lists each finding.
Disruptive action in business hoursOnly if someone is vigilant
Whether an action is disruptive and whether it is business hours are facts from different places. A rule has to read both before the change goes out.		Every rule is checked on every call and the verdict lists each finding.
Protected asset never remediated automaticallyOnly if someone is vigilant
A protected-asset list and an agent limit sit in different tools. A rule has to apply both and report each.		Every rule is checked on every call and the verdict lists each finding.
Detection confidence too low for the actionOnly with workarounds
Confidence thresholds differ by action: a lighter action may need less than a disruptive one. A rule has to read the incident’s confidence and the action’s threshold together.		Every rule is checked on every call and the verdict lists each finding.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the remediation action; approval findings need a person to sign off first.

    
1Incident INC5006 is closed. Do not remediate a finished incident.
2Incident INC5001 is not assigned to SecOps response agent. Act only on incidents assigned to you.
3Incident INC5001 is about a different asset than Batch server 07. Act only on the asset the incident names.
4SecOps response agent is level 2; the action Wipe and reimage a host needs level 3.
5Core domain controller is a protected asset. It is never remediated automatically; a human responder must act.
6The action affects 8 assets and users; SecOps triage agent may act on at most 5 at a time.
7Wipe and reimage a host cannot be undone and no rollback plan is attached. Attach one first.
8Web server 03 and Web server 04 are the two halves of an HA pair. Remediate one, confirm service, then handle the other.
9Detection confidence for incident INC5007 is 75 percent; Disable an account needs at least 80 percent.
10The agent stated a blast radius of 10; the call affects 40.
11The agent stated criticality 1 for Batch server 07; the record has criticality 2.
12Core domain controller is criticality 5; this agent may remediate up to criticality 4 on its own. A human responder must approve.
13Push a firewall ACL change disrupts Web server 03 during business hours. A human must approve or wait for the maintenance window.
14Chief executive account is an executive account. Containing it needs a human decision.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Ransomware response: Wiping a server hit by ransomware staging

    
The agent's request. I'm wiping and reimaging the batch server because of the ransomware staging. It affects 10 assets and users, and the server is criticality 2.

    
Verdict: Blocked.

    
    
      
  • Agent level too low for the action. SecOps response agent is level 2; the action Wipe and reimage a host needs level 3.
    • 
      
  • More assets and users than the agent may affect. The action affects 40 assets and users; SecOps response agent may act on at most 25 at a time.
    • 
      
  • Irreversible action without a rollback plan. Wipe and reimage a host cannot be undone and no rollback plan is attached. Attach one first.
    • 
      
  • Stated blast radius differs from the call. The agent stated a blast radius of 10; the call affects 40.
    • 
    

    
2. Ransomware response: Isolating the server instead, scoped down

    
The agent's request. I'm isolating the batch server instead, scoped to 20 assets and users, with a rollback plan attached. The server is criticality 2.

    
Verdict: Allowed.

    
3. Business hours: A firewall change on a production web server at midday

    
The agent's request. I'm pushing a firewall change on web server 03 to stop the credential stuffing. It is business hours and it affects 10 assets and users. The server is criticality 3.

    
Verdict: Needs approval.

    
    
      
  • Disruptive action in business hours. Push a firewall ACL change disrupts Web server 03 during business hours. A human must approve or wait for the maintenance window.
    • 
    

    
4. Business hours: The same change in the maintenance window

    
The agent's request. I'm pushing the same firewall change, now in the maintenance window outside business hours. It still affects 10 assets and users.

    
Verdict: Allowed.

    
5. Protected assets: Isolating the core domain controller

    
The agent's request. I'm isolating the core domain controller because of suspicious replication. It affects 10 assets and users, and the controller is criticality 5.

    
Verdict: Blocked.

    
    
      
  • Protected asset never remediated automatically. Core domain controller is a protected asset. It is never remediated automatically; a human responder must act.
    • 
      
  • Asset more critical than the agent may handle alone. Core domain controller is criticality 5; this agent may remediate up to criticality 4 on its own. A human responder must approve.
    • 
    

    
6. Detection confidence: Disabling a service account on a hunch

    
The agent's request. I'm disabling the ETL service account because of account abuse. It affects 1 asset or user, and the account is criticality 2.

    
Verdict: Blocked.

    
    
      
  • Detection confidence too low for the action. Detection confidence for incident INC5007 is 75 percent; Disable an account needs at least 80 percent.
    • 
    

    
7. Detection confidence: A lighter action: revoking the token

    
The agent's request. I'm revoking the account’s session token instead. It still affects 1 asset or user.

    
Verdict: Allowed.

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. Marlowe Health Network, a fictional company, lets an AI security agent act on incidents. Before the agent isolates a host, disables an account, pushes a firewall rule or applies another remediation, the action goes to Predictika’s Remediation Action Check. It checks that the incident is open, assigned to the agent and about the asset, that the agent’s level allows the action, that the asset is not protected, how many assets and users are affected, whether the action can be undone, redundant pairs, detection confidence, how critical the asset is for this agent, business hours and executive accounts. It also checks that the blast radius and criticality the agent stated match the record. Then it returns one verdict: allow, needs approval, or block.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. I'm wiping and reimaging the batch server because of the ransomware staging. It affects 10 assets and users, and the server is criticality 2.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with four findings, all in one answer. SecOps response agent is level 2; the action wipe and reimage a host needs level 3. The action affects 40 assets and users; SecOps response agent may act on at most 25 at a time. Wipe and reimage a host cannot be undone and no rollback plan is attached. Attach one first. The other one is on screen.
    6. 
      
  6. The validator returned four blocking findings in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the remediation action are checked against each other.
    7. 
      
  7. What this shows: for what an agent may affect alone, by level and criticality, a tool can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the action to isolate a host, the assets and users affected to 20 and the stated blast radius to 20. It sets the rollback plan to yes.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. This time the validator clears it.
    12. 
      
  12. All four earlier findings are cleared.
    13. 
      
  13. Four problems caught in one call, fixed in one pass, and a clean remediation action. That is the value of Predictika's validator: catching mistakes before the remediation runs. Now you can try the other scenarios yourself.
    14.