Predictika · AI agent actions on a Snowflake account

An AI data agent's Snowflake change, checked before it runs

Larkspur Media, a fictional company, lets AI agents work in its Snowflake account: they resize virtual warehouses, run SQL statements, share tables with partner accounts and send table rows to Cortex models. Before an agent's action runs, it goes to Predictika's validator. It checks the credits the change could use against the warehouse's monthly resource monitor, the largest size the agent may set, multi-cluster warehouses and the account's edition, and the auto-suspend time. It checks the credits the agent states against the credits it computes. It checks unfiltered updates and deletes, the rows a statement changes, and Time Travel retention before a truncate or drop. It checks that columns tagged as personal data have a masking policy before they are read, shared or sent to a model, that the consumer account is approved, and that EU-only data stays in region. Then it returns one verdict: allow, needs approval, or block.

Scope: AI agent actions on a Snowflake account (warehouse resizes, SQL statements, data shares and Cortex model calls), judged against budget, agent, data and region rules. Fictional customer; Snowflake concepts follow its public documentation. See everything this validator covers

This validator checks any resize, SQL statement, share or Cortex call that an agent proposes on the account, not just the scenarios shown below.

  • Warehouse changes — the size set, from X-Small (1 credit per hour) to 6X-Large (512), with the maximum number of clusters, the hours it will run and the auto-suspend time; the credits the change could use against the warehouse's monthly resource monitor; the largest size each agent may set; multi-cluster warehouses against the account's edition; and approval for 3X-Large and larger on a production warehouse.
  • SQL statements — select, insert, update, delete, merge, truncate and drop: unfiltered updates and deletes, the rows one statement may change, Time Travel retention before a truncate or drop on a production table, approval for those, and personal-data columns read without a masking policy.
  • Data sharing — whether the agent may share at all, whether the consumer account is on the approved list, personal-data columns without a masking policy, and approval for a share to an account in another cloud region.
  • Cortex model calls — EU-only data sent with cross-region inference set to ANY_REGION, and personal-data columns without a masking policy.
  • The agent's own figures — the credits the agent states must match the credits the validator computes.

Any action of these four kinds on the account is in scope, not only the scenarios pictured here. Not checked: the SQL text itself, query cost or performance, roles and grants, network policies, other Snowflake features, and the accuracy of the facts the caller states, such as the row count or whether a masking policy is really in place. Warehouse sizes and credits per hour follow Snowflake's published table; the quotas, limits and policies here are invented for the demonstration.

The AI data operations agentProposes one action on the Snowflake account: a warehouse change, a SQL statement, a data share or a Cortex model call.
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 data operations agent says

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

Proposing agent: AI data operations agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where roles and resource monitors alone get this wrong
Click to expand
    
Our assessment of what Snowflake's built-in controls (roles, resource monitors and masking policies) do with the same cases on their own. They are the right foundation; the validator adds the check before the agent acts. It is a judgment about effort and reliability, not a claim about any release.

    
What the validator caughtRoles and resource monitors alonePredictika
Checking a change against the credits left before it runsCannot do it
A resource monitor counts credits already used and can notify or suspend at a threshold. It does not work out what a proposed change could use, so a 3X-Large with four clusters is allowed until the credits are gone.		The credits the change could use are computed from the size, clusters and hours, and compared with the credits left before it runs.
Limiting how large a warehouse each agent may setOnly with workarounds
A privilege lets a role change a warehouse; it does not cap how large that role may make it. A ceiling per agent needs a wrapper or a custom procedure for every agent.		The largest size each agent may set is a rule checked on every call.
Limits that depend on each otherOnly with care
Lowering the size changes the credits, the agent's size limit, the idle limit and the credits the agent states at once. Separate checks give separate answers and someone has to put them together.		Size, clusters, hours and auto-suspend are in one request and re-evaluated together on every call.
Personal data protected before it is shared or sent to a modelOnly with care
A masking policy protects a column when it is queried. Checking that every tagged column has one before an agent shares a table or sends it to a model is a separate rule to write and keep current.		Tagged columns and the masking policy are checked on every read, share and model call.
Every problem returned in one answerOnly with workarounds
Checks run one at a time and stop at the first failure, so an agent fixes one error and meets the next.		All findings come back together in one verdict.

  

  

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

    
1The credits a warehouse change could use (credits per hour times clusters times hours) must fit within the credits left on the warehouse's monthly resource monitor.
2An agent may set a warehouse only up to the largest size it is allowed.
3A warehouse with more than one cluster needs an account on Enterprise edition or higher.
4A warehouse of X-Large or larger must auto-suspend within 300 seconds.
5The credits the agent states must equal the credits the validator computes.
63X-Large and larger on a production warehouse needs a FinOps owner's approval.
7An update or delete needs a WHERE clause.
8A statement may change only as many rows as the agent is allowed to change at once.
9A truncate or drop on a production table needs at least 7 days of Time Travel retention.
10A truncate or drop on a production table needs a data owner's approval.
11Columns tagged as personal data need a masking policy before they are read, shared or sent to a model.
12Only agents that are allowed to share data may share it.
13Data may be shared only with accounts on the approved list.
14A share to an account in another cloud region needs the data owner's approval.
15EU-only data may not be sent to a Cortex model with cross-region inference set to ANY_REGION.

  

  

    
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. Scaling a production warehouse for month-end close: Scaling the finance warehouse for month-end close

    
The agent's request. Please set FINANCE_WH to 3X-Large with up to 4 clusters and an auto-suspend time of 3,600 seconds for the 10-hour month-end close. I estimate the change will use 640 credits.

    
Verdict: Blocked.

    
    
      
  • Over the monthly credit budget. FINANCE_WH has 650 credits left on its monthly resource monitor. This change could use up to 2,560 credits (64 credits per hour times 4 clusters times 10 hours).
    • 
      
  • Larger than the agent may set. FinOps agent may set warehouses up to 2X-Large; 3X-Large is larger.
    • 
      
  • Auto-suspend too long. An auto-suspend time of 3,600 seconds is too long for a 3X-Large warehouse; the limit for X-Large and larger is 300 seconds.
    • 
      
  • Stated credits do not match. The agent stated 640 credits; the validator computes 2,560 (64 credits per hour times 4 clusters times 10 hours).
    • 
      
  • Large production warehouse. FINANCE_WH is a production warehouse and 3X-Large uses 64 credits per hour. A FinOps owner must approve 3X-Large and larger.
    • 
      
  • The proposed action. FinOps agent proposes to set FINANCE_WH to 3X-Large. Maximum clusters: 4. Hours to run: 10. Credits per hour: 64. Credits left on the monthly resource monitor: 650.
    • 
    

    
2. Scaling a production warehouse for month-end close: The agent resubmits after fixing the errors

    
The agent's request. Please set FINANCE_WH to 2X-Large with up to 4 clusters and an auto-suspend time of 3,600 seconds for the 10-hour month-end close. I estimate the change will use 1,280 credits.

    
Verdict: Blocked.

    
    
      
  • Over the monthly credit budget. FINANCE_WH has 650 credits left on its monthly resource monitor. This change could use up to 1,280 credits (32 credits per hour times 4 clusters times 10 hours).
    • 
      
  • Auto-suspend too long. An auto-suspend time of 3,600 seconds is too long for a 2X-Large warehouse; the limit for X-Large and larger is 300 seconds.
    • 
      
  • The proposed action. FinOps agent proposes to set FINANCE_WH to 2X-Large. Maximum clusters: 4. Hours to run: 10. Credits per hour: 32. Credits left on the monthly resource monitor: 650.
    • 
    

    
3. Scaling a production warehouse for month-end close: The agent resubmits after fixing the errors

    
The agent's request. Please set FINANCE_WH to 2X-Large with up to 2 clusters and an auto-suspend time of 300 seconds for the 10-hour month-end close. I estimate the change will use 640 credits.

    
Verdict: Allowed.

    
    
      
  • The proposed action. FinOps agent proposes to set FINANCE_WH to 2X-Large. Maximum clusters: 2. Hours to run: 10. Credits per hour: 32. Credits left on the monthly resource monitor: 650.
    • 
    

    
4. Sharing the customer table with a partner account: Sharing the customer table with a partner account

    
The agent's request. Please share the CUSTOMERS table with the partner account NORTHWIND_ANALYTICS for their churn model.

    
Verdict: Blocked.

    
    
      
  • Personal data without a masking policy. CUSTOMERS has 6 columns tagged as personal data and no masking policy is applied. Apply a masking policy before the data is read, shared or sent to a model.
    • 
      
  • The proposed action. Data engineering agent proposes to share CUSTOMERS with account NORTHWIND_ANALYTICS.
    • 
    

    
5. Sharing the customer table with a partner account: The agent resubmits after fixing the errors

    
The agent's request. Please share the CUSTOMERS table with the partner account NORTHWIND_ANALYTICS for their churn model, with the masking policy applied to its personal-data columns.

    
Verdict: Allowed.

    
    
      
  • The proposed action. Data engineering agent proposes to share CUSTOMERS with account NORTHWIND_ANALYTICS.
    • 
    

    
6. Cleaning up the customer table: Removing old customer rows

    
The agent's request. Please run DELETE FROM CUSTOMERS to remove the old customer rows from the production table. It will change 4,200,000 rows.

    
Verdict: Blocked.

    
    
      
  • No WHERE clause. This delete statement on CUSTOMERS has no WHERE clause, so it would change every row.
    • 
      
  • Too many rows in one statement. The statement changes 4,200,000 rows; Data engineering agent may change at most 100,000 rows in one statement.
    • 
      
  • The proposed action. Data engineering agent proposes a delete statement on CUSTOMERS.
    • 
    

    
7. Cleaning up the customer table: The agent resubmits after fixing the errors

    
The agent's request. Please run DELETE FROM CUSTOMERS WHERE LAST_ORDER_DATE is before January 1, 2023, to remove the old customer rows from the production table. It will change 8,000 rows.

    
Verdict: Allowed.

    
    
      
  • The proposed action. Data engineering agent proposes a delete statement on CUSTOMERS.
    • 
    

    
8. Summarizing EU support tickets with a Cortex model: Summarizing EU support tickets with a Cortex model

    
The agent's request. Please run a Cortex model over the text of EU_SUPPORT_TICKETS to summarize this week's tickets, with cross-region inference set to ANY_REGION.

    
Verdict: Blocked.

    
    
      
  • Personal data without a masking policy. EU_SUPPORT_TICKETS has 4 columns tagged as personal data and no masking policy is applied. Apply a masking policy before the data is read, shared or sent to a model.
    • 
      
  • EU data could leave the EU. EU_SUPPORT_TICKETS holds EU-only data, and cross-region inference is set to ANY_REGION, so the prompt could be processed outside the EU. Keep cross-region inference disabled for this data.
    • 
      
  • The proposed action. Analytics agent proposes to send rows of EU_SUPPORT_TICKETS to a Cortex model. Cross-region inference: ANY_REGION.
    • 
    

    
9. Summarizing EU support tickets with a Cortex model: The agent resubmits after fixing the errors

    
The agent's request. Please run a Cortex model over the text of EU_SUPPORT_TICKETS to summarize this week's tickets, with cross-region inference disabled and the masking policy applied to its personal-data columns.

    
Verdict: Allowed.

    
    
      
  • The proposed action. Analytics agent proposes to send rows of EU_SUPPORT_TICKETS to a Cortex model. Cross-region inference: DISABLED.
    • 
    

  

  

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

    
    
      
  1. Welcome to a demo of Predictika's Validator. Larkspur Media, a fictional company, lets AI agents work in its Snowflake account: they resize virtual warehouses, run SQL statements, share tables with partner accounts and send table rows to Cortex models. Before an agent's action runs, it goes to Predictika's validator. It checks the credits the change could use against the warehouse's monthly resource monitor, the largest size the agent may set, multi-cluster warehouses and the account's edition, and the auto-suspend time. It checks the credits the agent states against the credits it computes. It checks unfiltered updates and deletes, the rows a statement changes, and Time Travel retention before a truncate or drop. It checks that columns tagged as personal data have a masking policy before they are read, shared or sent to a model, that the consumer account is approved, and that EU-only data stays in region. 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. Please set FINANCE_WH to 3X-Large with up to 4 clusters and an auto-suspend time of 3,600 seconds for the 10-hour month-end close. I estimate the change will use 640 credits.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with four findings and one approval, all in one answer. FINANCE_WH has 650 credits left on its monthly resource monitor. This change could use up to 2,560 credits (64 credits per hour times 4 clusters times 10 hours). FinOps agent may set warehouses up to 2X-Large; 3X-Large is larger. An auto-suspend time of 3,600 seconds is too long for a 3X-Large warehouse; the limit for X-Large and larger is 300 seconds. The other one is on screen.
    6. 
      
  6. The validator returned four blocking findings 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 action are checked against each other.
    7. 
      
  7. What this shows: for limits that depend on each other, a setup built only on roles and resource monitors is error-prone for this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the new size to 2X-Large and the credits the agent states to 1,280.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Still blocked, with two findings, all in one answer. FINANCE_WH has 650 credits left on its monthly resource monitor. This change could use up to 1,280 credits (32 credits per hour times 4 clusters times 10 hours). An auto-suspend time of 3,600 seconds is too long for a 2X-Large warehouse; the limit for X-Large and larger is 300 seconds.
    12. 
      
  12. Three findings cleared. Still blocking: over the monthly credit budget and auto-suspend too long.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the maximum clusters to 2, the auto-suspend to 300 seconds and the credits the agent states to 640.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. Both earlier findings are cleared.
    18. 
      
  18. Five problems caught in one call, fixed in two passes, 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.
    19.