Predictika · Agent action gate for GPU clusters

An AI agent's plan for a GPU cluster, checked before it runs

An AI operations agent working in a GPU-cluster environment proposes a plan of actions: purchases, data exports, partner syncs, GPU jobs, deploys and shell commands. Before anything runs, the agent sends the whole plan to Predictika, which checks it against a declarative model of typical agent-governance practice and returns a verdict, every reason and the figures it computed.

Scope: Plans of actions by AI agents on a GPU cluster: data class against destination, GPU pools and quotas, spend authority, residency, production changes and cross-action patterns. See everything this validator covers

This validator checks the whole plan of one agent session, whatever the actions — not just the scenarios shown below.

  • Data and destinations — data above a role's clearance, data sent to a host not cleared for its class, sensitive data sent to a cloud model, and writes to a host that takes reads only are blocked.
  • GPU pools and budget — requests above the pool or role limit, production pools for roles without access, GPU-hours per session and the session budget (earlier use included).
  • Spend and vendors — a purchase above the role's limit needs a person to sign off, and a purchase from a vendor not on the approved list is blocked.
  • Residency and bulk records — Restricted data stays in its home region, and more than 1,000 records to a partner needs a person to sign off.
  • Cross-action patterns — touching Restricted data and writing to a public host in one plan is blocked as an exfiltration path, even when each call passes on its own.

Any single agent session of these kinds is in scope, not only the scenarios pictured here. Not covered: what the commands do inside the sandbox, network-level enforcement, model quality and the real prices of any cloud. The roles, hosts, pools and prices are an illustrative enterprise setup; this is not any company's policy.

The AI operations agentReads a team's request and proposes a plan of actions: purchases, exports, syncs, GPU jobs and commands.
Predictika validatorChecks the whole plan against every rule at once and returns the verdict, each finding and the computed figures.

7 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 operations agent says

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

Proposing agent: AI operations agent (scripted)

Before running the actions, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where typical rules-based tools get it wrong
Click to expand
    
Our assessment of what a typical rules-based tool (an access-control list, a sandbox allowlist or a spend-approval workflow) does with the same cases. It is our assessment, a judgment about effort and reliability, not a claim that nothing can be built.

    
What the validator caughtTypical rules-based toolPredictika
Each action passes alone, but together they leak Restricted dataOnly with workarounds
Every call is checked on its own, so the pattern across calls is invisible unless a separate process keeps a running list of what the session has touched.		The whole plan is one request; the validator counts Restricted touches and public writes together and blocks the combination.
A purchase from a vendor not on the list, or above the role's limitOnly with care
Vendor lists and spend limits sit in different systems, so one is often checked after the order is placed.		Both checks run on every purchase: the vendor list blocks, the role limit asks for a person.
Restricted data exported to another regionOnly with care
Region rules are usually written per bucket, not per data class and per session region.		The data class, the destination region and the session's home region are compared in one rule.
Exact boundaries: 1,000 records to a partner passes, 1,001 needs a person; 2,000 GPU-hours passes, 2,001 does notOnly with care
Off-by-one errors in limits are common and only show up on edge cases.		Each limit has live test cases on both sides.

  

  

    
What this validator catches
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.

    
1Data above a role’s clearance cannot be handled by that role.
2Data cannot go to a host that is not cleared for its class.
3Sensitive data cannot be sent to a cloud model; route it to a local one.
4A host that takes reads only cannot be written to.
5Shell commands never touch the credentials store or write to system paths; some roles may not delete files.
6A recursive delete in the workspace needs a person to sign off.
7GPU requests stay within the pool and role limits; production pools need production access; GPU-hours and budget are checked for the whole session, earlier use included.
8A purchase above the role’s limit needs a person to sign off, and the vendor must be on the approved list.
9A production deploy needs passing tests and production access; outside the change window it needs a person to sign off.
10Restricted or Confidential data stays in its home region.
11More than 1,000 records to a partner needs a person to sign off.
12Restricted data plus a public write in one plan is blocked as an exfiltration path.
13Incomplete tool calls are blocked until the missing fields are given.

  

  

    
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. Purchase: A $1,200 purchase from a vendor not on the approved list

    
The agent's request. Please buy $1,200 of extra storage licenses for the analytics team from a vendor that is not on the approved vendor list, but has the lowest quote.

    
Verdict: Blocked.

    
    
      
  • Vendor not on the approved list. The vendor is not on the approved vendor list.
    • 
    

    
2. Purchase: The agent resubmits after fixing the errors

    
The agent's request. Please buy the same $1,200 of storage licenses, this time from a vendor that is on the approved vendor list. The amount is unchanged.

    
Verdict: Allowed.

    
    
      
  • Session summary. This session has 1 proposed action for the finops agent, in the US region.
    • 
    

    
3. Data residency: Restricted data exported from a US session to the EU data lake

    
The agent's request. Please export 20,000 customer records, classified Restricted, to the EU data lake. This session is running in the US region.

    
Verdict: Blocked.

    
    
      
  • Data must stay in its home region. Exports Restricted data from US to the EU data lake in EU; data of this class stays in its home region.
    • 
    

    
4. Data residency: The agent resubmits after fixing the errors

    
The agent's request. Please export the same 20,000 Restricted customer records to the EU data lake. This time the session runs in the EU region, so the data stays in its home region.

    
Verdict: Allowed.

    
    
      
  • Session summary. This session has 1 proposed action for the data engineering agent, in the EU region.
    • 
    

    
5. Bulk partner records: 5,000 Confidential records pushed to the partner CRM

    
The agent's request. Please sync 5,000 Confidential customer records to the partner CRM API in one POST so the partner has the full list by tonight.

    
Verdict: Needs approval.

    
    
      
  • Bulk records to a partner needs sign-off. Sends 5000 records to the partner CRM API; more than 1000 records to a partner needs a human approval.
    • 
      
  • Session summary. This session has 1 proposed action for the support agent, in the US region.
    • 
    

    
6. Bulk partner records: The agent resubmits after fixing the errors

    
The agent's request. Please sync only the 800 Confidential customer records that changed this week to the partner CRM API, instead of the full 5,000.

    
Verdict: Allowed.

    
    
      
  • Session summary. This session has 1 proposed action for the support agent, in the US region.
    • 
    

    
7. Exfiltration path: Restricted data summarized locally, then posted to a public paste site

    
The agent's request. First summarize the Restricted incident data with the local model, then POST the summary, which I have labeled Public, to the public paste site so the vendor can see it.

    
Verdict: Blocked.

    
    
      
  • Exfiltration path across actions. 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.
    • 
    

  

  

    
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 operations agent working in a GPU-cluster environment proposes a plan of actions: purchases, data exports, partner syncs, and more. Before anything runs, the agent sends the whole plan to Predictika, which checks it against a declarative model of typical agent-governance practice and returns a verdict, every reason and the figures it computed.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Please buy $1,200 of extra storage licenses for the analytics team from a vendor that is not on the approved vendor list, but has the lowest quote.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with one finding, all in one answer. The vendor is not on the approved vendor list.
    6. 
      
  6. The validator returned one blocking finding 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 action plan are checked against each other.
    7. 
      
  7. What this shows: for a purchase from a vendor not on the list, or above the role's limit, a rules-based tool is error-prone for this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the vendor on the approved list to yes.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. This time the validator clears it.
    12. 
      
  12. The earlier finding is cleared.
    13. 
      
  13. One problem caught in one call, fixed in one pass, and a clean action. That is the value of Predictika's validator: catching mistakes before the action runs. Now you can try the other scenarios yourself.
    14.