Predictika · NetApp ONTAP MCP server · AI storage agents

An AI storage agent's NetApp ONTAP MCP tool calls, checked before they run

An AI agent connected to NetApp's ONTAP MCP server can create and delete volumes, change snapshot policies, write NFS export rules and manage SnapMirror relationships. Before each write call runs, the agent sends it to Predictika, which checks it against the customer's own storage policies and the state of the target, and returns a verdict (allow, needs approval or block), every reason, and the same answer on every call.

Source and independence. The tool names and parameters come from NetApp's public ONTAP MCP documentation (tools and examples; source on GitHub). The rules are example policies of a fictional customer, not NetApp rules, and the volumes and SVMs are that customer's inventory, supplied by the customer's own system. NetApp's blog Trust, but verify: Why AI agents need Zero Trust infrastructure argues that agents should run with least privilege and that sensitive actions need independent approval; this page shows one way to enforce that kind of policy. NetApp is not involved in this demonstration and has not endorsed it.

Scope: write calls through the NetApp ONTAP MCP server: volumes, snapshots, snapshot policies, NFS export rules and SnapMirror. See everything this validator covers

This validator handles any call to these ONTAP MCP tools against this inventory — not just the scenarios shown below.

  • Tools modeled — ontap_get, create_volume, update_volume, delete_volume, delete_snapshot, restore_snapshot, update_schedule_in_snapshot_policy, create_nfs_export_policies_rules, update_nfs_export_policies_rules, break_snapmirror and delete_snapmirror, with the parameters NetApp documents for them: SVM or volume, size, snapshots to keep, client match, read-only and read-write rules. In NetApp's server, break_snapmirror and delete_snapmirror are available only in its legacy or both tool modes. NetApp's snapshot policy tools act on a policy, not on a volume; this demonstration simplifies that by tying the policy to the volume it protects. The ONTAP MCP server has many more tools (CIFS, LUN, iSCSI, FCP, NVMe, QoS, qtrees, network interfaces, SVMs) that are not modeled here.
  • Example customer policies — Block deleting a SnapMirror source or a regulated volume; hold deleting a production volume for approval; block an export rule open to 0.0.0.0/0 and read-write any except for a single host; block a new or grown volume larger than the SVM quota left; hold shrinking a production volume; block snapshot retention under 7 on a protected volume and hold any shortening there; hold snapshot deletion on protected volumes, restores onto production volumes and breaking a SnapMirror source; never let the agent delete a SnapMirror relationship; check that each tool is aimed at the right kind of target and has the parameters it needs. These are illustrative examples, not published NetApp rules, to show how a customer's own policy is enforced; every number in them is the customer's to change.
  • Customer-supplied inventory (fictional) — svm_fin (4,096 GiB of quota left), svm_dev (500), svm_corp (2,000); volumes vol_orders (production, regulated, SnapMirror source, keeps 30 snapshots), vol_ledger (production, regulated, keeps 30), vol_etl_tmp (scratch, keeps 2), vol_homes (production, SnapMirror source, keeps 14) and vol_media (production, keeps 14). Whether a change approval is on file is also recorded by the customer and cannot be checked by the validator.

Not covered: NetApp's own access controls (ONTAP roles and the server's read-only mode, described on NetApp's prepare ONTAP page, still apply and are complementary), real inventory feeds, and tools not listed above.

The AI storage agentDecides which ONTAP MCP tool to call and says the call is ready to run.
Predictika validatorChecks every policy at once and returns the verdict and each finding before anything reaches the cluster.

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

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

Proposing agent: AI storage agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where role-based access alone gets it wrong
Click to expand
    
Our assessment of what ONTAP roles and the MCP server's read-only mode, which grant or withhold whole commands, do with the same cases. It is a judgment about fit, not a claim about every setup, and those controls remain worth using alongside the validator.

    
What the validator caughtRole-based access alonePredictika
Delete refused only when the volume is a SnapMirror source or holds regulated dataOnly with workarounds
A role grants delete_volume or withholds it; whether this volume is a replication source is state of the target, not part of the role.		The target's state is looked up on every call and the reason is returned.
Export rule open to 0.0.0.0/0, or read-write any for anything but one hostOnly with workarounds
A role controls which commands a user may run, not which parameter values a call may carry.		The parameters of each call are checked, and both problems come back together.
New or grown volume larger than the SVM quota leftOnly with workarounds
The quota left is the customer's own figure, outside the role.		Compared with the call on every request.
Hold a call for a person: shorten retention on a protected volume, delete a production volumeOnly with workarounds
A role allows or denies. Holding a call for a person, with the reason, is a third outcome it does not give.		Allow, needs approval and block are three verdicts of the same check.
Every reason in one answerOnly with care
A denial from a role typically stops at the first refusal.		All findings come back together, whatever order the choices arrived in.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
These are the example customer policies at work, recorded from the test cases. Every policy is checked on every call, in any order the choices arrive; one problem never hides another. A block stops the call; an approval holds it for a person.

    
1Block: the create_volume tool needs an SVM to create the volume in; vol_media is an existing volume.
2Block: the delete_volume tool acts on an existing volume; svm_dev is an SVM.
3Block: the update_volume tool call is missing a parameter it needs: a new size.
4Block: a new volume of 800 GiB is more than the 500 GiB of provisioning quota left on svm_dev.
5Block: growing vol_media to 3,000 GiB needs more than the 2,000 GiB of provisioning quota left on svm_corp.
6Block: vol_orders is the source of an active SnapMirror relationship; the agent role may not delete it.
7Block: vol_orders holds regulated data; the agent role may not delete it.
8Block: vol_ledger holds regulated data; the agent role may not delete it.
9Block: the agent role may not delete a SnapMirror relationship; that action is for people only.
10Block: the client match 0.0.0.0/0 opens the export to every host; export rules must name a subnet or a single host.
11Block: read-write access with the rule any is allowed only for a single named host.
12Block: vol_homes is protected; snapshot retention cannot go below 7 snapshots, and 5 was requested.
13Approval: shortening snapshot retention on protected volume vol_homes from 14 to 10 snapshots needs a change approval.
14Approval: deleting production volume vol_media needs a change approval.
15Approval: shrinking production volume vol_media from 600 GiB to 300 GiB needs a change approval.
16Approval: deleting a snapshot on protected volume vol_orders needs a change approval.
17Approval: restoring production volume vol_media from a snapshot overwrites live data and needs a change approval.
18Approval: breaking the SnapMirror relationship of vol_homes needs a change approval.

  

  

    
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. NFS export access: Export rule open to every host with read-write any

    
The agent's request. Please add an NFS export rule to vol_media in svm_corp for the analytics team: client match 0.0.0.0/0, read-only rule any, read-write rule any. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Export open to every host. The client match 0.0.0.0/0 opens the export to every host; export rules must name a subnet or a single host.
    • 
      
  • Read-write any not allowed. Read-write access with the rule any is allowed only for a single named host.
    • 
    

    
2. NFS export access: The agent resubmits after fixing the errors

    
The agent's request. Please add an NFS export rule to vol_media in svm_corp for the analytics team: client match 10.20.0.0/16, read-only rule any, read-write rule any. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Read-write any not allowed. Read-write access with the rule any is allowed only for a single named host.
    • 
    

    
3. NFS export access: The agent resubmits after fixing the errors

    
The agent's request. Please add an NFS export rule to vol_media in svm_corp for the analytics team: client match 10.20.4.7, read-only rule any, read-write rule any. It is ready to run.

    
Verdict: Allowed.

    
    
      
  • Tool call summary. The create_nfs_export_policies_rules tool, called on volume vol_media in SVM svm_corp.
    • 
    

    
4. Creating a volume: Create a volume bigger than the SVM quota

    
The agent's request. Please create a new 800 GiB volume on the svm_dev SVM for the ETL team. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Over the quota left. A new volume of 800 GiB is more than the 500 GiB of provisioning quota left on svm_dev.
    • 
    

    
5. Creating a volume: The agent resubmits after fixing the errors

    
The agent's request. Please create a new 300 GiB volume on the svm_dev SVM for the ETL team. It is ready to run.

    
Verdict: Allowed.

    
    
      
  • Tool call summary. The create_volume tool, called on SVM svm_dev.
    • 
    

    
6. Deleting a volume: Delete a replicated, regulated volume

    
The agent's request. Please delete the volume vol_orders to free up space. It is ready to run.

    
Verdict: Blocked.

    
    
      
  • Replication source cannot be deleted. vol_orders is the source of an active SnapMirror relationship; the agent role may not delete it.
    • 
      
  • Regulated volume cannot be deleted. vol_orders holds regulated data; the agent role may not delete it.
    • 
    

    
7. Deleting a volume: The agent resubmits after fixing the errors

    
The agent's request. Please delete the volume vol_etl_tmp to free up space. It is ready to run.

    
Verdict: Allowed.

    
    
      
  • Tool call summary. The delete_volume tool, called on volume vol_etl_tmp in SVM svm_dev.
    • 
    

    
8. Snapshot retention: Shorten retention on a protected volume

    
The agent's request. Please change the snapshot policy for vol_homes to keep 10 snapshots instead of 14. It is ready to run.

    
Verdict: Needs approval.

    
    
      
  • Shorter retention needs approval. Shortening snapshot retention on protected volume vol_homes from 14 to 10 snapshots needs a change approval.
    • 
      
  • Tool call summary. The update_schedule_in_snapshot_policy tool, called on volume vol_homes in SVM svm_corp.
    • 
    

    
9. Snapshot retention: The agent resubmits after fixing the errors

    
The agent's request. Please change the snapshot policy for vol_homes to keep 10 snapshots instead of 14. The change approval is on file. It is ready to run.

    
Verdict: Allowed.

    
    
      
  • Approval on file (customer record). A change approval is recorded as on file; it is a record kept by the customer, not by the validator, and the validator cannot check it.
    • 
      
  • Tool call summary. The update_schedule_in_snapshot_policy tool, called on volume vol_homes in SVM svm_corp.
    • 
    

  

  

    
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 agent connected to NetApp's ONTAP MCP server can create and delete volumes, change snapshot policies, write NFS export rules and manage SnapMirror relationships. Before each write call runs, the agent sends it to Predictika, which checks it against the customer's own storage policies and the state of the target, and returns a verdict (allow, needs approval or block), every reason, and the same answer on every call.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Please add an NFS export rule to vol_media in svm_corp for the analytics team: client match 0.0.0.0/0, read-only rule any, read-write rule any. It is ready to run.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with two findings, all in one answer. The client match 0.0.0.0/0 opens the export to every host; export rules must name a subnet or a single host. Read-write access with the rule any is allowed only for a single named host.
    6. 
      
  6. The validator returned two 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 tool call are checked against each other.
    7. 
      
  7. What this shows: for export rule open to 0.0.0.0/0, or read-write any for anything but one host, a role-based access control can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the client match to 10.20.0.0/16.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Still blocked, with one finding, all in one answer. Read-write access with the rule any is allowed only for a single named host.
    12. 
      
  12. One finding cleared; still blocked on read-write any not allowed.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the client match to 10.20.4.7.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. The earlier finding is cleared.
    18. 
      
  18. Two problems caught in one call, fixed in two passes, and a clean tool call. That is the value of Predictika's validator: catching mistakes before the tool call runs.
    19.