Predictika · Agent Action Validator

Before an AI agent's action runs, it's checked

Meridian Controls lets AI agents work its coding, customer-support and email queues: dropping staging tables, issuing refunds, replying to suppliers. Before any of them acts, the call goes to Predictika's validator, which checks it against the agent's own permissions, the task it is working under, everything it has already done this session, and the day's usage counters.

Scope: AI-agent tool calls in Meridian Controls' coding / DevOps, customer-support refund and email / export workflows. See everything this validator covers

This model covers three specific agent tool packs at the fictional Meridian Controls, not "AI agents" in general. Within them, the validator handles any agent, task, tool, target or session-history combination those packs can produce, not just the 7 scenarios on this page, which are a sample chosen to show how the checks work.

  • Coding / DevOps tools — database reads, migrations, table drops, backup deletion and release deploys, gated by the agent's permissions, the task's production setting, whether a resource and its backup are both deleted in one session, repeated production deletes, and a daily deploy quota.
  • Customer-support refund tools — order lookup, contact-detail changes and refunds, gated by the agent's refund limit, the order balance, a second refund on the same order, a contact change earlier in the session, and a daily team refund budget.
  • Email / productivity tools — reading files and inbound mail, sending and exporting, gated by task clearance, whether sensitive data and untrusted inbound content are both in the session before a send, whether the destination is an approved partner, and a row ceiling on exports.
  • Limits of this validator — a request carries the proposed action plus up to two earlier actions of the session. The two usage counters (deploys today, refund spend today) are read by the caller from the release tracker and finance ledger and passed with the request; the validator does not reserve or decrement them. It does not cover other tool packs (for example HR, procurement or physical systems) or access-rights changes, unless those are added. All agents, tasks, resources and limits are fictional.
What this demo shows: governance, metering and monitoring in one call. Read more
  • Static permissions: governance's foundation. What this agent may do at all: read, delete, deploy, refund, send, export. Any allow-list does this part.
  • The request in context: governance's judgment call. The same action can be fine or forbidden depending on the task and the target. See scenarios 1 and 2: the same agent and the same tool, with a different target.
  • This session's own history. Some checks look at what the same agent already did earlier in the session. See scenarios 3 and 5, where an earlier action turns the next one into a block, and scenarios 4 and 6, where its absence lets it through.
  • A usage counter: metering. Governance asks whether an agent is allowed to do something; metering asks whether it, or its team, has already used up its allowance today. See scenario 7. The refund budget works the same way and is in the rule list below.

Two honest limits. First, metering here is check-then-act: the validator compares the counter it is given with the limit and does not lock it, so two calls at nearly the same instant could both see the same count; closing that race needs the counter's own system to reserve on the call. Second, monitoring today is a per-call record (who, what, which task, which checks fired, what verdict), not a dashboard; aggregating and alerting on those records happens downstream of the validator.

The AI agentDecides the action is needed and says what it wants to do, then calls the validator before acting.
Predictika validatorChecks permissions, task scope, this session's history and the day's usage counters, then returns one verdict.

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

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

Before acting, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  


  

  

    
Where a static allow-list gets it wrong
Click to expand
    
General statements about static allow-lists and role-based permission checks, not about any named product. Our assessment of how such checks work; anyone running a specific product will know it better than we do.

    
Failure modeA static allow-list or role-based checkPredictika validator
Production change not allowed for this taskOnly with workarounds
A role or allow-list grants an agent a tool such as dropping tables; refusing one target under one task takes a finer entry for every agent, tool, task and resource, kept current by hand.		Checks the agent, the task and the target together at the moment of the call.
Primary and backup deleted in one sessionCannot do it
Each call is judged alone: the table drop is approved, then the backup delete is approved, and nothing remembers the first when the second arrives.		Reads every earlier action of the session and blocks the second delete.
Refund right after a contact-detail changeCannot do it
Updating an email is allowed, and a refund under the limit is allowed; the account-takeover pattern exists only in the sequence, which a per-call permission cannot see.		Blocks the refund because the same session changed the contact details first.
Production delete needs a personOnly with workarounds
An allow-list answers yes or no; holding one irreversible action for a recorded human approval means adding a separate approval workflow for each tool.		Returns needs approval with the reason, so the action waits for a person and the approval is on record.
Daily deploy quota already usedOnly with workarounds
A permission list has no notion of how much was used today; the count lives in another system and code must fetch it and compare it for every limit.		Takes the day's count with the request and holds the deploy once the quota is reached.

  


  

    
What this validator catches: the 18 rules
Click to expand
    
Every rule reports its own message and never stops the others, so one problem cannot hide another. Block rules mean the agent must not do this. Approval rules mean a person has to sign off first. Several rules read the session history or a usage counter, not just the action itself.

    

  

  

    
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. Production changes: 1. Drop a production table

    
The agent's request. Drop the invoices table in the billing production database to continue the schema cleanup.

    
Verdict: Blocked.

    
    
      
  • Production change not allowed for this task. The invoices table (prod) is a production resource and the task Drop unused staging tables in billing does not allow production changes. Check the target; you may have meant the staging copy.
    • 
      
  • Production delete needs a person. Deleting invoices table (prod) in production is irreversible. Do not execute until a human approves.
    • 
    

    
2. Production changes: 2. Drop the staging copy

    
The agent's request. Drop the staging copy of the tmp_import table to finish the schema cleanup.

    
Verdict: Allowed.

    
3. Backups: 3. Delete the backup too

    
The agent's request. The migration to the new invoices schema is complete and the old invoices table has been dropped. Delete the nightly backup snapshot of the invoices table.

    
Verdict: Blocked.

    
    
      
  • Primary and backup deleted in one session. The invoices nightly backup and its counterpart would both be deleted in the same session. Never delete a resource and its backup together.
    • 
      
  • Production delete needs a person. Deleting invoices nightly backup in production is irreversible. Do not execute until a human approves.
    • 
    

    
4. Backups: 4. Drop the old table, keep the backup

    
The agent's request. The migration to the new invoices schema is complete. Drop the old invoices table and leave its nightly backup snapshot in place.

    
Verdict: Needs approval.

    
    
      
  • Production delete needs a person. Deleting invoices table (prod) in production is irreversible. Do not execute until a human approves.
    • 
    

    
5. Refunds: 5. Refund after an email change

    
The agent's request. The customer confirmed a new email address on the Halvorsen Automation account and asked for a refund of order 50011 for a defective item. Issue a refund of $80.

    
Verdict: Blocked.

    
    
      
  • Refund right after a contact-detail change. A refund follows a contact-detail change made earlier in this session; this is the pattern of an account takeover.
    • 
    

    
6. Refunds: 6. Refund, no contact change

    
The agent's request. The customer in chat 4471 asked for a refund of order 50011 for a defective item. Issue a refund of $80.

    
Verdict: Allowed.

    
7. Usage limits: 7. Deploy when the quota is used up

    
The agent's request. Deploy this week’s release candidate to the staging environment.

    
Verdict: Needs approval.

    
    
      
  • Daily deploy quota already used. 10 deploys have already run today against a daily quota of 10; this deploy needs a human to approve it.
    • 
    

  

  

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

    
    
      
  1. Welcome to a demo of Predictika's Validator. Meridian Controls lets AI agents work its coding, customer-support and email queues: dropping staging tables, issuing refunds, replying to suppliers. Before any of them acts, the call goes to Predictika's validator, which checks it against the agent's own permissions, the task it is working under, everything it has already done this session, and the day's usage counters.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Drop the invoices table in the billing production database to continue the schema cleanup.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with one finding and one approval, all in one answer. The invoices table (prod) is a production resource and the task drop unused staging tables in billing does not allow production changes. Check the target; you may have meant the staging copy.
    6. 
      
  6. The validator returned one blocking finding and one approval 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 production change not allowed for this task, a static allow-list or role-based check can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the target to tmp_import table (staging).
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. This time the validator clears it.
    12. 
      
  12. Both earlier findings are cleared.
    13. 
      
  13. Two 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.
    14.