Data-Layer Guards

A database call meets two checkpoints

The kernel checks the submitted query on the way in and the returned rows on the way out. Each guard reads a ToolAction::DatabaseQuery that the tool host builds from the call.

A refusal at the first checkpoint leaves the database untouched. The receipt names the guard, and the guard's reason code goes to its log. The second checkpoint shapes what the agent reads after the database has answered. An UPDATE that passed admission has already changed the table by then, so test a query's effect as well as the data delivered to the agent.

SqlQueryGuard parses the statement before it runs

The guard parses the SQL with sqlparser in the configured dialect and walks the syntax tree. It refuses at the first check that fails, in this order:

1. Parse. A statement that does not parse is refused.
2. Operation. The operation must appear in operation_allowlist.
3. Tables. Every referenced table must appear in table_allowlist.
4. Columns. When a per-table column allowlist is configured, every projected column must be on it, and SELECT * is refused for that table.
5. Predicates. The canonicalized WHERE clause must match no regex in denylisted_predicates.
6. Mutations. With require_where_for_mutations set, an UPDATE or DELETE without a WHERE clause is refused.

Each refusal carries a stable SqlGuardDenyReason code, such as table_not_allowed or missing_where_clause. The kernel returns Verdict::Deny and writes the code to the receipt and the structured log line.

With the configuration below, an agent may read orders and skus through the orders server's sql tool and never reaches customers. SELECT * FROM customers stops at step 3 with table_not_allowed, before the database sees it, and DELETE FROM orders stops at step 2, because only SELECT is allowed.

Computed projections fail closed. With a column allowlist in force, the ? the parser substitutes for an opaque expression, as in SELECT lower(email) FROM customers, is refused, because the guard would have to evaluate the expression to show it stays inside the allowed columns.

Read more in Govern database queries.

Vector queries stay inside named collections and a row ceiling

VectorDbGuard inspects database queries whose database identifier or tool name matches a vendor marker (Pinecone, Weaviate, Qdrant, Chroma, Milvus, or the generic vector), plus memory-shaped calls. It holds them on four axes:

• Collection. The collection, index, class, or store must be named and on the allowlist.
• Namespace. When a namespace allowlist is set, the call must declare a namespace on it. An empty allowlist on a namespaced grant refuses every request.
• Operation class. The guard reuses SqlOperationClass, so one constraint covers SQL and vector grants. ReadOnly refuses every verb in mutating_operations.
• Row ceiling. When the grant sets Constraint::MaxRowsReturned, the call must declare top_k, topK, k, or limit.

A call that omits its verb fails closed. Under SqlOperationClass::ReadOnly or ReadWrite, a MemoryWrite-shaped call with no operation field is refused; every class stricter than Admin requires the operation key.

Read more in Memory governance.

A warehouse query stops at its dry-run cost ceiling

WarehouseCostGuard caps what a query on BigQuery, Snowflake, Redshift, Athena, Databricks, Presto, or Trino may scan and cost. It reads a dry-run estimate that the tool server, or an upstream dry-run gate, attaches to the arguments:

{
  "query": "SELECT sku, sum(total) FROM orders GROUP BY sku",
  "dry_run": {
    "bytes_scanned": 53687091200,
    "estimated_cost_usd": "0.25"
  }
}

The guard compares bytes_scanned and estimated_cost_usd against the configured ceilings and refuses a query over either one, a query with no estimate at the configured path, or an estimate that does not parse. The ceiling bounds the warehouse charge only as well as the estimate does, so the host obtains it from a trusted provider or dry-run service and binds it to the submitted query.

Guards evaluate without writing to the receipt. On an admitted call, the integration calls record_cost, which builds a CostDimension::WarehouseQuery record with the reported bytes and cost, so the mapping lives in one place.

The request gates and the result hook register separately

The four guards are built in Rust from their own config structs. The three request gates join a GuardPipeline, which is itself a Guard and registers on the kernel as one unit. QueryResultGuard registers as a post-invocation hook.

use chio_guards::GuardPipeline;
use chio_data_guards::{
    SqlDialect, SqlOperation, SqlGuardConfig, SqlQueryGuard,
    VectorGuardConfig, VectorDbGuard,
    WarehouseCostGuardConfig, WarehouseCostGuard,
    QueryResultGuardConfig, QueryResultGuard,
};

// Pre-invocation gates compose onto a GuardPipeline.
let mut pipeline = GuardPipeline::default_pipeline();

pipeline.add(Box::new(SqlQueryGuard::new(SqlGuardConfig {
    dialect: SqlDialect::Postgres,
    operation_allowlist: vec![SqlOperation::Select],
    table_allowlist: vec!["orders".into(), "skus".into()],
    denylisted_predicates: vec![r"(?i)\bor\s+1\s*=\s*1\b".into()],
    require_where_for_mutations: true,
    ..Default::default()
})));

pipeline.add(Box::new(VectorDbGuard::new(VectorGuardConfig {
    collection_allowlist: vec!["skus".into()],
    namespace_allowlist: Some(vec!["harbor-goods".into()]),
    denied_operations: vec!["drop_index".into(), "delete_collection".into()],
    ..Default::default()
})));

pipeline.add(Box::new(WarehouseCostGuard::new(WarehouseCostGuardConfig {
    max_bytes_scanned: Some(53_687_091_200), // 50 GiB
    max_cost_per_query_usd: Some("1.00".into()),
    ..Default::default()
})));

// QueryResultGuard runs after the tool response. new() returns Result
// because an invalid PII regex rejects construction.
let result_guard = QueryResultGuard::new(QueryResultGuardConfig {
    redact_pii_patterns: vec![
        r"[\w.+-]+@[\w-]+\.[\w.-]+".into(),
        r"\b\d{3}-\d{2}-\d{4}\b".into(),
    ],
    ..Default::default()
})?;

// Register on an existing mutable kernel. Request context supplies the
// scope; the owned hook retains this scope as its fallback.
kernel.add_guard(Box::new(pipeline));
kernel.add_post_invocation_hook(Box::new(
    result_guard.into_owned_hook(scope.clone()),
));

After the tool returns, the hook truncates row arrays to the scope's Constraint::MaxRowsReturned, replaces the values of columns named in Constraint::ColumnDenylist with the redaction marker, and applies any redact_pii_patterns to every string value. A bare column name matches any table; table.column matches only that table.

The hook reads the scope and matched grant from the post-invocation request context and falls back to the scope it was built with, so a shared host supplies that context for calls with different result constraints. Appending the hook keeps every sanitization hook already registered. QueryResultGuard also implements Guard, and its pre-invocation evaluate always allows, so a result guard added only to the request pipeline redacts nothing.

Configuration stays in Rust: the HushSpec rules map has no data_layer, sql, or vector key, and the guards: section of chio.yaml carries only allow_advisory_promotion and required.

Read more in Guard pipelines.

Next: run a governed database query