Predictika · Security agent actions

An AI agent's action batch, checked before it runs

An AI security agent, such as a remediation agent working an alert or an identity agent, proposes a batch of actions against the assets and identities of a tenant: policy edits, agent upgrades, firewall rule changes, host isolation, role grants and automatic-response enablement. Before anything runs, the batch goes to the Predictika validator, which checks it against the asset and identity graph (standard hosts and their peer pairs, management planes, crown-jewel vaults, the agent version each runs and the privilege level each account class may hold), the agent version automatic response needs, and the customer's own action policy, and returns every finding in one answer. The validator runs on the graph an asset inventory exports, with the customer's own policy. The tenant, the tickets, the policy, the role levels and the version rule on this page belong to a fictional customer, Meridian Health; they are not Palo Alto Networks product behavior. Palo Alto Networks is not involved with it and has not endorsed it.

Scope: batches of agent actions against assets and identities with peer pairs, management planes and crown-jewel vaults. See everything this validator covers

This validator checks one kind of request: a batch of proposed actions from an AI agent, an automation or a person, against the asset and identity graph and an action policy. It handles any batch of such actions against the targets in the graph, not only the scenarios shown on this page. It does not decide whether an alert is real and does not run anything.

  • Covered: peers — actions on both halves of a peer pair (break-glass accounts or HA partners) in one batch are blocked; the pair comes from the graph. An upgrade that would leave two peers more than one version step apart is blocked, in either direction.
  • Covered: versions and privilege — enabling automatic response on a target whose agent is below the required version is blocked, and an upgrade in the same batch does not count; granting a role above the level an account class may hold is blocked.
  • Covered: scope, rollback and window — a tenant-wide action with no rollback reference, or outside the approved change window, is blocked; a narrower action outside the window needs approval.
  • Covered: agent actions on live state — isolating a host whose primary is degraded while its standby is already down is blocked, because it would take the service offline; with the standby up, the same action is allowed.
  • Covered: approvals and velocity — actions on crown-jewel assets need a minimum approval rank on the ticket, and a limit on privileged and crown-jewel actions per window sends the batch to a person.
  • Supplied by the customer's own systems, not by the validator — the asset and identity graph, the ticket approvals, the policy values, whether each action is inside the approved window, the rollback reference, and the primary and standby state from monitoring.
  • Not covered — alert triage, detection logic, configuration syntax, and any rule the customer has not written into its policy. Other rules can be added.
The AI agentProposes the batch of actions and says it is ready to push.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

8 scenarios in 4 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 rules-based change approval gets it wrong
Click to expand
    
Our assessment of what a typical rules-based change approval workflow (ticket fields, approval chains and validation rules) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

    
What the validator caughtTypical rules-based change approvalPredictika
A feature that needs a newer agent version than the target runsOnly with workarounds
Whether automatic response can be enabled depends on the version the agent runs today, not the one a batch will leave it on. Ticket rules do not know either, so the check is done by an engineer reading release notes, or not at all.		The running version comes from the graph, the feature's minimum version from the customer's policy, and an upgrade in the same batch is correctly not counted.
Peers on versions too far apartOnly with care
An upgrade ticket names one target. Whether it leaves its peer too far behind depends on the peer's version and a policy limit, which approval rules rarely hold side by side.		The target version is compared with the peer's running version from the graph, in either direction, against the customer's limit.
Both halves of a break-glass or HA pair in one batchOnly with workarounds
A change-approval workflow looks at one action at a time. Seeing that two actions in the same batch hit both halves of a pair needs a view across the whole batch and the pairing from the inventory, which is usually done in a script outside the workflow.		The whole batch is evaluated together against the graph; both actions are reported, each naming its peer.
Privilege limits per account classOnly with care
Which role an account class may hold is a table that grows with every role and class, and a role grant that is fine for one class is wrong for another.		Each role carries its level and each target its class limit; the grant is compared on every call and a shortfall is reported with both numbers.
An agent action that depends on live stateOnly with workarounds
Whether it is safe to isolate a host depends on the state of its standby at that moment. Ticket rules do not see telemetry, so the check ends up inside the agent or not at all.		The monitoring state travels with the action as a field, so the same isolation is blocked with the standby down and allowed with it up.
Approval rank by asset tier, plus a rate limitOnly with care
A rank requirement for crown-jewel assets and a limit on privileged actions per window are separate thresholds that approval chains handle one at a time.		Both are checked on every batch and reported together, with the numbers behind them.

  

  

    
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 batch; approval findings need a person to sign off. The wording shown is an example from the test runs; device names and numbers change with the batch. The policy values come from a fictional customer.

    
1Automatic response needs a newer agent version than the target runs (blocks): action item-02 enables automatic response on host-104a, which runs agent version 10.2; in the customer policy automatic response needs agent version 11.1 or later. An upgrade in the same batch does not count: the feature can be enabled only once the agent is on that version.
2Both peers of a pair in one batch (blocks): action item-02 on host-101b and its paired peer host-101a (a break-glass or HA partner) are both in this batch. Policy: peers are changed in separate batches so that access or failover is never lost on both at once.
3Host isolated while the primary is degraded and the standby is down (blocks): action item-01 would isolate host-101a, whose primary is degraded, while its standby is already down. Isolating it would take the service offline; restore the standby first.
4Peers would run versions too far apart (blocks): action item-01 upgrades host-102a to version 11.2, but its peer host-102b runs 10.2. Policy: peers may not run versions more than one step apart.
5Role level exceeds what the account class allows (blocks): action item-04 grants role Admin to mgmt-4, a management plane (restricted tier); the customer policy limits that account class to a lower privilege level.
6Target not in the tenant (blocks): action item-01 names host-999z, which is not an asset or identity in tenant meridian-prod.
7Tenant-wide action without a rollback (blocks): action item-03 is tenant-wide and has no rollback reference. Policy: stage a rollback before a tenant-wide action.
8Action outside the change window (needs approval): change item-01 on vault-1a is outside the approved change window. Change policy: a person must approve it.
9Crown-jewel action needs higher approval (needs approval): action item-01 is on crown-jewel asset vault-1a and ticket chg-8102 carries rank 1 approval; policy requires rank 3 for crown-jewel actions.
10Too many privileged and crown-jewel actions (needs approval): this batch brings privileged and crown-jewel actions to 4 within the policy window; policy allows 3.

  

  

    
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. Versions and privilege: A two-version jump, automatic response on a 10.2 agent, a tenant-wide rule change, an Admin role on a restricted plane

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8103: an upgrade of host-102a to version 11.2 (rollback rb-9101), the enabling of automatic response on host-104a (rollback rb-9102), a tenant-wide firewall rule change through mgmt-1, and an Admin role on mgmt-4 (rollback rb-9104). All of it is in tonight's approved change window. No privileged or crown-jewel action has been made in this window yet. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Peers would run versions too far apart. Action item-01 upgrades host-102a to version 11.2, but its peer host-102b runs 10.2. Policy: peers may not run versions more than one step apart.
    • 
      
  • Automatic response needs a newer agent version than the target runs. Action item-02 enables automatic response on host-104a, which runs agent version 10.2; in the customer policy automatic response needs agent version 11.1 or later. An upgrade in the same batch does not count: the feature can be enabled only once the agent is on that version.
    • 
      
  • Tenant-wide action without a rollback. Action item-03 is tenant-wide and has no rollback reference. Policy: stage a rollback before a tenant-wide action.
    • 
      
  • Role level exceeds what the account class allows. Action item-04 grants role Admin to mgmt-4, a management plane (restricted tier); the customer policy limits that account class to a lower privilege level.
    • 
    

    
2. Versions and privilege: Upgrade lowered and rollback added; the automatic-response fix and the role still fail

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8103: an upgrade of host-102a to version 11.1 (rollback rb-9101), an upgrade of host-104a to version 11.1 (rollback rb-9105), the enabling of automatic response on host-104a (rollback rb-9102), a tenant-wide firewall rule change through mgmt-1 (rollback rb-9103), and an Admin role on mgmt-4 (rollback rb-9104). All of it is in tonight's approved change window. No privileged or crown-jewel action has been made in this window yet. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Automatic response needs a newer agent version than the target runs. Action item-03 enables automatic response on host-104a, which runs agent version 10.2; in the customer policy automatic response needs agent version 11.1 or later. An upgrade in the same batch does not count: the feature can be enabled only once the agent is on that version.
    • 
      
  • Role level exceeds what the account class allows. Action item-05 grants role Admin to mgmt-4, a management plane (restricted tier); the customer policy limits that account class to a lower privilege level.
    • 
    

    
3. Versions and privilege: Automatic response on a plane already on 11.2, and a role the tier allows

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8103: an upgrade of host-102a to version 11.1 (rollback rb-9101), the enabling of automatic response on mgmt-3 (rollback rb-9102), a tenant-wide firewall rule change through mgmt-1 (rollback rb-9103), and an Analyst role on mgmt-4 (rollback rb-9104). All of it is in tonight's approved change window. No privileged or crown-jewel action has been made in this window yet. It is ready to run.

    
Verdict: Allowed.

    
4. Peer pairs: Upgrade of both break-glass peers

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8101: an upgrade of host-101a to version 11.2 (rollback rb-9201) and an upgrade of host-101b to version 11.2 (rollback rb-9202). Both are single-target actions in tonight's approved change window. No privileged or crown-jewel action has been made in this window yet. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Both peers of a pair in one batch. Action item-01 on host-101a and its paired peer host-101b (a break-glass or HA partner) are both in this batch. Policy: peers are changed in separate batches so that access or failover is never lost on both at once.
    • 
      
  • Both peers of a pair in one batch. Action item-02 on host-101b and its paired peer host-101a (a break-glass or HA partner) are both in this batch. Policy: peers are changed in separate batches so that access or failover is never lost on both at once.
    • 
    

    
5. Peer pairs: Upgrade one peer, change another pair

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8101: an upgrade of host-101a to version 11.2 (rollback rb-9201) and a policy edit on host-103a (rollback rb-9202). Both are single-target actions in tonight's approved change window. No privileged or crown-jewel action has been made in this window yet. It is ready to run.

    
Verdict: Allowed.

    
6. Agent host isolation: Isolate a host with a degraded primary, standby down

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8102: isolate host-101a, whose primary monitoring has flagged as degraded (rollback rb-9301), and make a policy edit on host-103a (rollback rb-9302). Both are in tonight's approved change window. One privileged or crown-jewel action has already been made in this window. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Host isolated while the primary is degraded and the standby is down. Action item-01 would isolate host-101a, whose primary is degraded, while its standby is already down. Isolating it would take the service offline; restore the standby first.
    • 
    

    
7. Agent host isolation: Standby restored

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8102: isolate host-101a, whose primary monitoring has flagged as degraded (rollback rb-9301), now that its standby has been restored, and make a policy edit on host-103a (rollback rb-9302). Both are in tonight's approved change window. One privileged or crown-jewel action has already been made in this window. It is ready to run.

    
Verdict: Allowed.

    
    
      
  • Standby is up. Action item-01 isolates host-101a while the standby is up; traffic moves to the standby.
    • 
    

    
8. Approvals: Crown-jewel vault change outside the window on a lower-rank ticket

    
The agent's request. Please run this batch on the Meridian Health production tenant under ticket chg-8102: a policy edit on vault-1a (rollback rb-9401), scheduled outside tonight's approved change window, and a policy edit on host-103a (rollback rb-9402), inside it. Both are single-target actions. No privileged or crown-jewel action has been made in this window yet. It is ready to run.

    
Verdict: Needs approval.

    
    
      
  • Action outside the change window. Change item-01 on vault-1a is outside the approved change window. Change policy: a person must approve it.
    • 
      
  • Crown-jewel action needs higher approval. Action item-01 is on crown-jewel asset vault-1a and ticket chg-8102 carries rank 1 approval; policy requires rank 3 for crown-jewel actions.
    • 
    

  

  

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

    
    
      
  1. Welcome to a demo of Predictika's Validator. An AI security agent, such as a remediation agent working an alert or an identity agent, proposes a batch of actions against the assets and identities of a tenant: policy edits, agent upgrades, firewall rule changes, and more. Before anything runs, the batch goes to the Predictika validator, which checks it against the asset and identity graph (standard hosts and their peer pairs, management planes, crown-jewel vaults, the agent version each runs and the privilege level each account class may hold), the agent version automatic response needs, and the customer's own action policy, and returns every finding in one answer. The validator runs on the graph an asset inventory exports, with the customer's own policy. The tenant, the tickets, the policy, the role levels and the version rule on this page belong to a fictional customer, Meridian Health; they are not Palo Alto Networks product behavior. Palo Alto Networks is not involved with it and has not endorsed it.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Please run this batch on the Meridian Health production tenant under ticket chg-8103: an upgrade of host-102a to version 11.2 (rollback rb-9101). All of it is in tonight's approved change window. The rest of the request is on screen.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with four findings, all in one answer. Action item-01 upgrades host-102a to version 11.2, but its peer host-102b runs 10.2. Policy: peers may not run versions more than one step apart. Action item-02 enables automatic response on host-104a, which runs agent version 10.2; in the customer policy automatic response needs agent version 11.1 or later. An upgrade in the same batch does not count: the feature can be enabled only once the agent is on that version. Action item-03 is tenant-wide and has no rollback reference. Policy: stage a rollback before a tenant-wide action. 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 batch are checked against each other.
    7. 
      
  7. What this shows: for a feature that needs a newer agent version than the target runs, a rules-based change approval can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the item Agent or software upgrade on host-102a, one target, rollback rb-9101, inside the change window; target version 11.2 to Agent or software upgrade on host-102a, one target, rollback rb-9101, inside the change window; target version 11.1 and the item Firewall rule change on mgmt-1, tenant-wide, rollback none, inside the change window to Firewall rule change on mgmt-1, tenant-wide, rollback rb-9103, inside the change window. It adds the item Agent or software upgrade on host-104a, one target, rollback rb-9105, inside the change window; target version 11.1.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Still blocked, with two findings, all in one answer. Action item-03 enables automatic response on host-104a, which runs agent version 10.2; in the customer policy automatic response needs agent version 11.1 or later. An upgrade in the same batch does not count: the feature can be enabled only once the agent is on that version. Action item-05 grants role Admin to mgmt-4, a management plane (restricted tier); the customer policy limits that account class to a lower privilege level.
    12. 
      
  12. Two findings cleared. Still blocking: automatic response needs a newer agent version than the target runs and role level exceeds what the account class allows.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the item Enable automatic response on host-104a, one target, rollback rb-9102, inside the change window to Enable automatic response on mgmt-3, one target, rollback rb-9102, inside the change window and the item Grant a role on mgmt-4, one target, rollback rb-9104, inside the change window; role Admin to Grant a role on mgmt-4, one target, rollback rb-9104, inside the change window; role Analyst. It removes the item Agent or software upgrade on host-104a, one target, rollback rb-9105, inside the change window; target version 11.1.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. The validator also returns the line-item quote. It starts with Agent or software upgrade on host-102a and Enable automatic response on mgmt-3; the other two lines are on screen.
    18. 
      
  18. Both earlier findings are cleared.
    19. 
      
  19. Four problems caught in one call, fixed in two passes, and a clean batch. That is the value of Predictika's validator: catching mistakes before the change is made. Now you can try the other scenarios yourself.
    20.