Use Cases/Data Agents

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

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

GDPR / CCPAPII redactionQuery filtering

The cost of uncontrolled data access

The average cost of a data breach dropped to $4.44M globally in 2025, but the U.S. average hit $10.22M. Organizations with extensive shadow AI — where workers use unapproved AI tools with data access — paid an extra $670,000 on average. GDPR enforcement has reached a cumulative $5.88 billion in fines, with regulators increasingly targeting AI systems. LinkedIn was fined $310M for misusing user data for behavioral analysis. Clearview AI was fined $30.5M for facial recognition violations. A single data agent with unconstrained database access creates the same exposure.

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 impossible to secure with static access controls alone. The CPPA's 2025 AI regulations now require businesses to notify consumers when automated decision-making is used for significant decisions — meaning your data agent's queries may create direct regulatory obligations.

Unauthorized queries

Agents query tables they should not access, exposing salary data, credentials, or medical records. Dynamic SQL generation means any table is one prompt away.

PII exposure

Bulk exports and unrestricted SELECT queries leak thousands of customer records in seconds. GDPR fines for such exposures start at 2% of global revenue.

Data exfiltration

Agents export data to unauthorized destinations, bypassing DLP controls and compliance 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 map directly to GDPR Article 25 (data protection by design) and CCPA Section 1798.100 (right to know what data is collected).

veto/policies/data.yamlyaml
policies:
  # Block dangerous 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: [slack]
      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"

Compliance mapping

Data agent guardrails map directly to regulatory requirements across jurisdictions.

GDPR

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

CCPA / 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
  • Audit trail per PHI access
  • Role-based data isolation

The numbers

$4.44M

Global average data breach cost in 2025. U.S. average is $10.22M.

$670K

Extra breach cost from shadow AI — unapproved AI tools with data access

241 days

Mean time to identify and contain a breach. Veto logs every query in real-time.

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
  • Compliance reporting per regulation
  • Real-time alerting on policy violations

Related use cases

Frequently asked questions

How do guardrails prevent SQL injection from data agents?
Veto intercepts 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 guardrails operate independently of the agent's query generation logic — the agent cannot reason its way around a policy denial.
Can guardrails detect PII in query results?
Yes. Veto can analyze query patterns for PII table access (users, credentials, payments, ssn, medical) and block or require approval before execution. You can configure automatic column masking for sensitive fields, record count limits for tables containing PII, 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 logs 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.