Roles & Users
How Guardrail Layer evaluates access based on user identity, role, and execution context — not just database permissions.
Why Traditional RBAC Breaks with LLMs
Role-Based Access Control (RBAC) was designed for human operators issuing intentional, scoped queries.
LLMs do not behave like humans. They explore, infer, and combine data in ways that can bypass traditional permission boundaries without violating explicit rules.
Guardrail Layer treats every query as an untrusted actor — even if the database user is read-only.
Users
A user represents the entity responsible for initiating a request. This may be a human, an automated system, or an LLM-powered agent.
Each user is associated with:
- An organization
- One or more roles
- An execution context
Users do not directly map to database accounts. Guardrail Layer separates identity from execution to prevent privilege escalation.
Roles
Roles define what data may be accessed and how it may be used.
Roles can restrict:
- Which tables are visible
- Which columns may be selected
- Whether aggregation is allowed
- Whether raw values or only redacted values are returned
- Which query types are permitted
Example Role Types
Aggregates allowed, raw identifiers hidden
Scoped row-level access
Heavily constrained, no raw sensitive data
Execution Context
Guardrail Layer evaluates roles in the context of how a query is being executed.
Context includes:
- Request source (human vs agent)
- Purpose or task identifier
- Time-based constraints
- Query history and frequency
This allows policies such as:
- Allow aggregates during business hours only
- Deny repeated exploratory queries from agents
- Require stricter redaction for automated workflows
Role Evaluation Flow
Why This Matters
Guardrail Layer's role system is designed to answer a question traditional RBAC cannot:
"Should this query be allowed in this context, by this actor, right now?"