Predictika · Agent Action Validator

Before an AI agent runs a tool call, its meaning is checked

An enterprise lets AI agents run research, data, DevOps and finance tasks inside a sandboxed runtime that already controls which files, hosts, methods and models each agent can reach. Before any call runs, it is sent to Predictika’s Agent Action Validator, which judges what the actions mean for the business: data class against destination and region, roles, GPU pools and limits, spend, production changes, and patterns across calls.

Illustrative only. The roles, hosts, models, GPU pools and prices are an illustrative enterprise setup. This is not an NVIDIA product, and nothing here implies NVIDIA review or endorsement.

Scope: semantic checks on agent tool calls behind a sandboxed runtime (HTTP, inference, shell, GPU jobs, purchases, deploys, exports) See everything this validator covers

This model covers seven kinds of agent action, not agents in general:

  • Network and models — Http and Inference calls, gated by host, method, data class, role clearance and privacy routing.
  • Shell — reads, writes, deletes and installs, gated by path scope, role and recursion.
  • Compute and spend — GpuJob and Purchase, gated by pool, per-job and per-session limits, session budget and vendor list.
  • Change and data movement — Deploy and Export, gated by tests, change window, role and data residency.

Within these seven actions it handles any combination, not just the nine scenarios here. It does not replace the runtime’s own policy, inspect file contents or judge model output.

The AI agentProposes one or more tool calls, says what it intends, then calls the validator before running them.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

9 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 a per-call check gets it wrong
Click to expand
    
Our assessment of what a runtime that allows or denies each call by host, path, method and role does with the same cases. It is a judgment from public descriptions of how such runtimes work, not a claim that nothing can be built.

    
What the validator caughtTypical per-call sandbox or allowlistPredictika
Patterns across calls, and data leaving its regionOnly with workarounds
A sandbox that allows or denies each call by host, path and method cannot see a pattern that exists only across calls, or a data class against a region. We rest this on public descriptions of how such runtimes work.		The validator looks at the whole session and blocks it.
Recursive deletes, and role limits on spend and GPUsOnly with care
Pool and role limits live in separate records, and approvals attach to the whole action, not the path.		A single-file delete in the workspace is routine. A recursive one is not, so the validator asks for a human before it runs. The item is listed as an approval, not a block.

  

  

    
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 request; approval findings need a person to sign off; everything else is computed.

    
1Action a1: Confidential data sent to the cloud frontier model API (Cloud); route it to a local model.
2Action a1: carries Restricted data; a Research agent is cleared for Confidential data at most.
3The session touches Restricted data in 1 action(s) and writes to a public host in 1; together they form an exfiltration path even though each call passes on its own.
4Action a1: NGC catalog takes GET requests only; this request is POST.
5Action a1: Confidential data may not go to the public paste site; it is cleared for Public data at most.
6Action a1: Read on the credentials store; agents never touch secrets directly.
7Action a1: Write on system paths is outside the agent workspace.
8Action a1: a Research agent may not delete files.
9Action a1: 32 GPUs requested; the H100 dev pool allows 16 per job.
10Action a1: 32 GPUs requested; a DevOps agent may use 16 per job.
11Action a1: the Vera Rubin production pool is reserved for production; a Research agent has no production access.
12The session asks for 2560 GPU-hours on top of 0 already used; a Research agent may use 2000 per session.
13Estimated spend 4608.0 on top of 6000.0 already spent exceeds the session budget of 10,000.00.
14Action p1: the vendor is not on the approved vendor list.
15Action d1: production deploy with failing tests.
16Action d1: a Research agent may not deploy to production.
17Action e1: exports Restricted data from US to the EU data lake in EU; data of this class stays in its home region.
18Action h1: the Http call needs Host.
19Session input Session_Budget is not given.
20Action a1: recursive delete in the workspace needs a human approval.
21Action p1: purchase of 60,000.00 is above the FinOps agent limit of 50,000.00; it needs a human approval.
22Action d1: production deploy outside the change window needs a human approval.
23Action h1: sends 5000 records to the partner CRM API; more than 1000 records to a partner needs a human approval.
24Action x5: installs a package; OpenShell still checks the binary against its allowlist.
254 delete commands in one session; review the plan before it runs.

  

  

    
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. Several calls together: A plan with three problems at once

    
The agent's request. Running the full plan: a cloud model call on the Confidential notes, a 16-GPU job for 20 hours, a package download, and posting the results to the paste site.

    
Verdict: Blocked.

    
    
      
  • Confidential data sent to a cloud model. Action s1: Confidential data sent to the cloud frontier model API (Cloud); route it to a local model.
    • 
      
  • Data too sensitive for the destination host. Action s4: Internal data may not go to the public paste site; it is cleared for Public data at most.
    • 
      
  • Session GPU-hours over the role limit. The session asks for 320 GPU-hours on top of 1800 already used; a Research agent may use 2000 per session.
    • 
    

    
2. Several calls together: The agent resubmits after fixing the errors

    
The agent's request. Running the plan: a local-model call on the Confidential notes, a 16-GPU job for 10 hours, and a package download.

    
Verdict: Allowed.

    
    
      
  • Session totals. The session has 3 actions, 160 GPU-hours and an estimated spend of 960.
    • 
    

    
3. Several calls together: Each call fine, together an exfiltration path

    
The agent's request. Summarizing the Restricted records with the local model and posting the summary to the paste site so the team can read it.

    
Verdict: Blocked.

    
    
      
  • Sensitive data read, then a write to a public host. The session touches Restricted data in 1 action(s) and writes to a public host in 1; together they form an exfiltration path even though each call passes on its own.
    • 
    

    
4. Where data may go: Restricted data into another region

    
The agent's request. Exporting the 20,000 Restricted customer records to the EU data lake for the analytics team.

    
Verdict: Blocked.

    
    
      
  • Restricted data leaving its home region. Action e1: exports Restricted data from US to the EU data lake in EU; data of this class stays in its home region.
    • 
    

    
5. Where data may go: The agent resubmits after fixing the errors

    
The agent's request. Exporting the 20,000 Restricted customer records to the EU data lake from the EU session.

    
Verdict: Allowed.

    
    
      
  • Session totals. The session has 1 action, 0 GPU-hours and an estimated spend of 0.
    • 
    

    
6. Destructive actions: A recursive delete with no human

    
The agent's request. Cleaning up the build directory with a recursive delete in the workspace.

    
Verdict: Needs approval.

    
    
      
  • Recursive delete needs a human. Action a1: recursive delete in the workspace needs a human approval.
    • 
      
  • Session totals. The session has 1 action, 0 GPU-hours and an estimated spend of 0.
    • 
    

    
7. Destructive actions: The agent resubmits after fixing the errors

    
The agent's request. Running the recursive delete in the build directory. A person has approved it.

    
Verdict: Allowed.

    
    
      
  • Recursive delete needs a human. Action a1: recursive delete in the workspace needs a human approval.
    • 
      
  • Session totals. The session has 1 action, 0 GPU-hours and an estimated spend of 0.
    • 
    

    
8. Resources and spend: More GPUs than two limits allow

    
The agent's request. Starting a 32-GPU job for 2 hours on the dev GPU pool.

    
Verdict: Blocked.

    
    
      
  • More GPUs than the pool allows per job. Action a1: 32 GPUs requested; the H100 dev pool allows 16 per job.
    • 
      
  • More GPUs than the role may use per job. Action a1: 32 GPUs requested; a DevOps agent may use 16 per job.
    • 
    

    
9. Resources and spend: A purchase above the role limit

    
The agent's request. Placing a purchase order for 60,000 with the approved vendor.

    
Verdict: Needs approval.

    
    
      
  • Purchase above the role spend limit. Action p1: purchase of 60,000.00 is above the FinOps agent limit of 50,000.00; it needs a human approval.
    • 
      
  • Session totals. The session has 1 action, 0 GPU-hours and an estimated spend of 60,000.
    • 
    

  

  

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

    
    
      
  1. Welcome to a demo of Predictika's Validator. An enterprise lets AI agents run research, data, DevOps and finance tasks inside a sandboxed runtime that already controls which files, hosts, methods and models each agent can reach. Before any call runs, it is sent to Predictika’s Agent Action Validator, which judges what the actions mean for the business: data class against destination and region, roles, GPU pools and limits, spend, production changes, and patterns across calls.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Running the full plan: a cloud model call on the Confidential notes, a 16-GPU job for 20 hours, a package download, and posting the results to the paste site.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with three findings, all in one answer. Action s1: Confidential data sent to the cloud frontier model API (Cloud); route it to a local model. Action s4: Internal data may not go to the public paste site; it is cleared for Public data at most. The session asks for 320 GPU-hours on top of 1800 already used; a Research agent may use 2000 per session.
    6. 
      
  6. The validator returned three 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 request are checked against each other.
    7. 
      
  7. What this shows: for patterns across calls, and data leaving its region, a per-call sandbox or allowlist can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the cloud call to local model, the paste site to none and the GPU-hours to 160 more; 1,960 of 2,000.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. This time the validator clears it.
    12. 
      
  12. All three earlier findings are cleared.
    13. 
      
  13. Three problems caught in one call, fixed in one pass, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs. Now you can try the other scenarios yourself.
    14.