Use Cases/Data Agents

Your data agent exported 50,000 customer records. To where?

Data agents autonomously query databases, transform datasets, and move information between systems. Veto intercepts each wrapped database operation before execution, validating queries against policies that enforce access controls, PII protection, and data governance rules.

GDPR and CCPAPII redactionQuery filtering

The cost of uncontrolled data access

A data agent with unconstrained database access can create breach, privacy, and regulatory exposure in one tool call. Shadow AI makes this worse: workers connect unapproved AI tools to production data, and the decision records often starts after the data has already moved. Veto puts policy before the query, not after the incident.

Risks in autonomous data agents

Unlike traditional applications with fixed queries, data agents generate dynamic SQL and data operations based on natural language requests. This makes them unpredictable and hard to secure with static access controls alone. California's ADMT regulations were adopted by the CPPA in July 2025, approved by OAL on September 22, 2025, and became effective January 1, 2026; ADMT-specific compliance begins January 1, 2027. If a data agent materially supports automated decision-making, its queries can become part of the regulatory evidence record.

Unauthorized queries

Agents can query tables they should not access, exposing salary data, credentials, or medical records. Dynamic SQL needs table-level tool policy.

PII exposure

Bulk exports and unrestricted SELECT queries leak thousands of customer records in seconds. That is the point where a helpful analyst becomes an unbounded disclosure path.

Data exfiltration

Agents export data to unauthorized destinations, bypassing DLP controls and regulated review requirements. Shadow AI adds $670K to average breach costs.

Query filtering and PII policies

Define which queries your data agent can execute, which tables it can access, and what happens when PII is detected in results. These policies can be mapped to GDPR Article 25 (data protection by design) and CCPA Section 1798.100 (right to know what data is collected).

veto/policies/data.yaml
policies:
  # Block destructive SQL operations
  - name: "Block destructive queries"
    match:
      tool: "query_database"
      arguments:
        query: "(?i)(DROP|DELETE|TRUNCATE|ALTER)\s"
    action: deny
    response:
      error: "Destructive queries are not permitted"

  # Restrict access to PII tables
  - name: "Block PII table access"
    match:
      tool: "query_database"
      arguments:
        query: "(?i)(users|credentials|payments|ssn|medical)"
    action: deny
    response:
      error: "Access to PII tables requires explicit authorization"

  # Limit data export volume
  - name: "Limit record export"
    match:
      tool: "export_data"
      arguments:
        records: { "$gt": 1000 }
    action: require_approval
    approval:
      timeout_minutes: 60
      channels: [approval_channel]
      reason: "Large data export requires approval"

  # Block exports to unauthorized destinations
  - name: "Restrict export destinations"
    match:
      tool: "export_data"
    rules:
      - condition: "destination not in ['internal://analytics', 'internal://reports']"
        action: deny
        reason: "Export to unauthorized destination blocked"

  # Block schema modifications
  - name: "Block schema changes"
    match:
      tool: "modify_schema"
    action: deny
    response:
      error: "Schema modifications require DBA approval"

  # Require WHERE clause on large tables
  - name: "Enforce query scope"
    match:
      tool: "query_database"
      arguments:
        query: "(?i)SELECT.*FROM.*(orders|transactions|events)"
    rules:
      - condition: "query not contains 'WHERE'"
        action: deny
        reason: "Queries on large tables must include a WHERE clause"

Evidence mapping

Data agent guardrails can be mapped to regulatory requirements across jurisdictions.

GDPR

  • Art. 25: Data protection by design
  • Art. 32: Security of processing
  • Art. 5(1)(f): Integrity and confidentiality
  • Decision record for DPAs

CCPA and CPRA

  • Sec. 1798.100: Data access controls
  • Automated decision-making disclosure
  • Data minimization enforcement
  • Purpose limitation per query

HIPAA

  • PHI access controls
  • Minimum necessary standard
  • Decision record per PHI access
  • Role-based data isolation

Where the risk lands

Breach cost

Unauthorized exports turn a single agent mistake into disclosure review, notification, and customer trust loss.

Shadow AI

Unapproved tools with data access avoid normal review unless the query path is policy-gated.

Investigation

Decision records show who queried what, which policy fired, and whether the action ran.

Common policies for data agents

Query filtering

  • Block DELETE, DROP, TRUNCATE operations
  • Restrict SELECT on PII tables
  • Enforce WHERE clauses on large tables
  • Validate JOIN patterns

Access control

  • Role-based table access
  • Department-level data isolation
  • Time-based access windows
  • Environment restrictions (prod vs dev)

Data protection

  • PII detection and masking
  • Export destination allowlisting
  • Record count limits per query
  • Column-level access controls

Audit and monitoring

  • Full query logging with context
  • Access pattern anomaly detection
  • Evidence reporting per regulation
  • Alerting on policy violations

Related use cases

Frequently asked questions

How do guardrails block injection-shaped queries from data agents?
Veto intercepts governed queries before they reach the database and validates them against policy rules. You can block patterns that indicate injection attempts, require parameterized queries, and enforce query structure rules. The policy operates independently of the agent's query generation logic: denied calls fail at the governed boundary.
Can guardrails control access to PII tables?
Yes. Veto evaluates governed query metadata and policy context for sensitive tables or columns (users, credentials, payments, ssn, medical) and can block or require approval before execution. If your data path exposes column metadata or a masking proxy, policies can require masked fields, record-count limits for PII tables, and export destination restrictions. This maps to GDPR's data minimization principle.
How do record limits work with paginated queries?
Guardrails track cumulative record access across a session. Even if an agent makes multiple paginated queries, the total record count is enforced. You can set per-query limits, session totals, or time-window quotas. When limits are approached, the agent receives configurable warnings or blocks.
Can I use different policies for production vs development databases?
Yes. Policies can include context-based conditions. Create restrictive policies for production databases while allowing broader access in development environments. The policy engine evaluates all applicable rules for each tool call based on the environment context you provide.
How do guardrails integrate with existing data governance?
Veto complements existing governance infrastructure. It can enforce policies defined in your data catalog, integrate with identity providers for role-based access, and export decision records to SIEM systems. The guardrails add runtime enforcement to your governance policies: closing the gap between policy definition and policy execution.

Your data agent has SELECT * access to production.

One unscoped query can expose every customer record you have.