Architecture Overview

Architecture Overview

A high-level view of how Guardrail Layer sits between LLMs and databases to enforce policy, prevent data leakage, and produce auditable outcomes.

System Goals

Guardrail Layer is designed to safely enable LLM-driven querying without granting the model direct database access.

  • Prevent unauthorized access and inference leakage
  • Enforce organization isolation and role-aware policies
  • Constrain query behavior (joins, aggregates, limits, cost)
  • Produce complete audit trails for every decision

Guardrail Layer treats execution as a controlled operation, not a feature.

High-Level Data Flow

Client App / Agent / Service
  ↓
LLM (generates intent and/or SQL)
  ↓
Guardrail Layer (enforcement gateway)
  • Identity & context resolution
  • Metadata evaluation
  • Policy enforcement
  • Redaction / rewrite / deny
  • Audit logging & telemetry
  ↓
Database
  ↓
Results (scoped + redacted)

Core Components

Gateway / API Layer

Accepts requests, attaches identity context, and routes queries through enforcement.

Identity & Role Resolver

Determines the organization, user, role(s), and execution context for each request.

Metadata Engine

Understands schema structure, relationships, sensitivity labels, and safe join paths.

Policy Engine

Evaluates policies to allow, transform, or deny queries based on role and context.

Query Analyzer

Parses SQL to identify tables, columns, joins, aggregates, and potentially unsafe patterns.

Audit & Telemetry

Records the decision trail, policy matches, rewrites, timing, and execution metadata.

Enforcement Stages

Guardrail Layer enforcement is deterministic and stage-based. Each stage produces explicit decisions and structured outputs.

1) Identity & Context Binding

The system attaches a stable identity to every request (organization, user, role, and request source). Policies cannot be bypassed by changing prompts or SQL formatting.

2) Metadata-Aware Analysis

SQL is analyzed against known schema metadata to determine what the query will touch (tables, columns, join paths) and what it implies.

3) Policy Evaluation

Policies determine what is allowed for the caller's role and context, including column visibility, join restrictions, aggregation constraints, and execution limits.

4) Allow / Transform / Deny

Guardrail Layer produces an explicit outcome:

  • Allow: execute as-is
  • Transform: inject filters, apply limits, remove projections, or rewrite safely
  • Deny: block with a clear reason

5) Execution + Auditing

Only allowed queries reach the database. Every decision (including denies) is logged with full context and structured reasons.

Multi-Tenant Isolation

Guardrail Layer enforces organization boundaries independently of database accounts. Even if the underlying database is shared, queries are scoped to prevent cross-tenant access.

Tenant isolation is enforced at the policy layer, not assumed at the SQL layer.

Deployment Models Flexible

Guardrail Layer can run as:

  • Hosted — managed service
  • Self-Hosted — runs inside your infrastructure

Both deployments share identical enforcement behavior. See Hosted vs Self-Hosted.

Where to Go Next

Guardrail Layer sits between models and data to enforce policy deterministically.

Scroll to Top