A user can be blocked from a sensitive column and still receive sensitive information derived from data they are allowed to access.
That changes the authorization problem for enterprise data agents.
Traditional access control asks:
Can this user read this database object?
An AI analytics system also needs to ask:
Is this user allowed to receive what the system can infer from those objects?
Consider a simple example.
A user cannot access:
employee.salary
But the same user can access:
department.total_cost
department.employee_count
A capable data agent can derive:
department.total_cost
/
department.employee_count
No forbidden salary column was queried.
The database permission model may have worked perfectly.
The answer may still disclose information the policy intended to protect.
This is why:
RBAC Still Matters
This is not an argument against role-based access control.
RBAC remains a critical foundation.
A typical model might define:
Role: Sales Manager
ALLOW:
customer
sales_order
product
regional_revenue
DENY:
employee.salary
payroll
compensation_detail
At the database layer, those controls should continue to be enforced.
The problem is that an AI agent introduces several stages above the database:
Natural Language
↓
Intent Resolution
↓
Semantic Resolution
↓
Context Retrieval
↓
Relationship Planning
↓
SQL Generation
↓
Execution
↓
Answer Generation
Authorization therefore has more surfaces than a traditional application issuing predefined SQL.
The Inference Gap
Let's formalize the salary example.
Suppose policy says:
{
"resource": "employee.salary",
"action": "read",
"effect": "deny"
}
But:
{
"resource": "department.total_cost",
"action": "read",
"effect": "allow"
}
and:
{
"resource": "department.employee_count",
"action": "read",
"effect": "allow"
}
The agent creates:
f(total_cost, employee_count)
→ estimated_average_salary
Every input is authorized.
The derived concept may not be.
Call this the inference gap:
Authorized Inputs
↓
Reasoning / Aggregation
↓
Restricted Information
Traditional object-level authorization may not express that boundary.
Add Semantic Authorization
Users ask questions in business concepts.
So policy should increasingly understand business concepts too.
Instead of governing only:
employee.salary
define a semantic concept:
{
"concept": "employee_compensation",
"direct_access": "deny",
"derived_access": "deny"
}
Now a request such as:
What is the average salary of the engineering team?
can be resolved first:
Intent
→ Employee Compensation
Then evaluated:
Employee Compensation
→ DENY
before SQL generation begins.
This is semantic authorization.
It lets policy operate at the same abstraction level as the user's question.
Authorization Should Start Before SQL Generation
A common architecture is:
Question
↓
Retrieve Schema
↓
Generate SQL
↓
Database Permission Check
↓
Execute
The problem is that the model may already have received context it should not use.
A stronger pipeline is:
Question
↓
Identity
↓
Intent Resolution
↓
Semantic Policy
↓
Authorized Context
↓
Authorized Relationship Graph
↓
Query Planning
↓
SQL Generation
↓
Database Enforcement
↓
Answer Policy
The important change is:
Authorization constrains reasoning context before it constrains execution.
Build an Authorized Context Resolver
Imagine the enterprise semantic layer contains:
Revenue
Gross Margin
Customer Risk
Payroll Cost
Employee Compensation
Product Profitability
A generic context retriever might return all concepts semantically related to the question.
That is risky.
Instead:
Candidate Context
↓
Identity + Policy
↓
Authorized Context
↓
LLM
Pseudocode:
def resolve_authorized_context(question, user):
intent = resolve_intent(question)
candidates = retrieve_semantic_context(intent)
allowed = [
item for item in candidates
if policy.can_use(user, item)
]
return allowed
The real implementation will need stronger policy semantics, but the architectural boundary matters.
Do not give the model unauthorized context and hope the final SQL check fixes everything.
Relationships Need Authorization Too
Suppose relationship discovery finds:
Employee
↓
Department
↓
Cost Center
↓
Financial Cost
The path is structurally valid.
But a Sales user may not be allowed to traverse it.
So distinguish:
Trusted Relationship
from:
Authorized Relationship
A relationship object could carry policy metadata:
{
"source": "department",
"target": "cost_center",
"status": "trusted",
"policy": {
"allowed_roles": [
"finance",
"hr"
]
}
}
Then query planning uses a user-specific graph:
def authorized_graph(graph, user):
return graph.filter(
lambda edge: policy.can_traverse(user, edge)
)
This gives us another useful rule:
Valid relationship ≠ Authorized relationship.
Query Planning Should Operate on the Authorized Graph
Assume the full relationship graph contains:
Customer ─ Order ─ Payment
Employee ─ Department ─ Cost Center
Supplier ─ Contract ─ Pricing
For a Sales user:
Customer ─ Order ─ Payment
may be available.
Employee ─ Department ─ Cost Center
may be removed from the planning graph.
The SQL generator never sees that path.
That is safer than generating the query first and rejecting it later.
Direct Access and Derived Access Are Different Policies
Some concepts need two policy dimensions.
Example:
{
"concept": "customer_credit_risk",
"direct_access": {
"roles": ["risk", "finance"]
},
"derived_access": {
"roles": ["risk", "finance"]
}
}
Why distinguish them?
Because an organization might allow:
Department Cost
but restrict:
Individual Compensation
or permit individual operational metrics while restricting a derived risk score.
The derived concept may have different sensitivity from its inputs.
Answer-Level Policy Is the Final Boundary
Even with pre-query authorization, a final result check is useful.
The pipeline may produce:
SQL Valid ✓
Database Access ✓
Relationship Valid ✓
Execution ✓
Answer Policy ✕
The system should not return the result.
Conceptually:
result = execute(sql)
answer_concepts = classify_result_semantics(
question=question,
plan=query_plan,
result=result
)
for concept in answer_concepts:
if not policy.can_receive(user, concept):
raise PolicyDenied(concept)
This is not simply SQL validation.
It is answer validation.
Why Result Classification Is Hard
A result rarely arrives labeled:
"This is sensitive compensation information."
The system needs evidence from:
Original Intent
Resolved Semantic Concepts
Selected Metrics
Query Plan
Aggregations
Relationship Path
Output Columns
That means answer governance should not be implemented as a disconnected moderation step.
It should preserve semantic provenance throughout query execution.
Preserve a Semantic Query Plan
Instead of storing only SQL:
SELECT ...
store a structured plan:
{
"intent": "average employee compensation",
"concepts": [
"employee_compensation"
],
"metrics": [
"department_total_cost",
"employee_count"
],
"derived_metric": {
"name": "estimated_average_salary",
"expression": "department_total_cost / employee_count"
},
"relationships": [
"employee -> department"
]
}
Now authorization has something meaningful to evaluate.
This is another reason production Text-to-SQL should not be treated as:
Question → SQL
The intermediate query plan matters.
Add Policy to the Query Plan
A policy-aware plan might look like:
{
"concept": "employee_compensation",
"authorization": {
"semantic_access": false,
"data_access": true,
"relationship_access": true,
"answer_access": false
},
"decision": "deny"
}
The system can stop before execution.
For a different user:
{
"role": "HR Partner",
"decision": "allow"
}
The same natural-language question can therefore produce different authorized query plans.
Policy-Aware Clarification
Authorization can also affect clarification.
Suppose a user asks:
Show employee cost.
The system resolves two candidates:
Department Operating Cost
Employee Compensation
The user is authorized for the first but not the second.
A naive clarification UI might reveal both options.
That itself may leak sensitive semantic structure.
Instead, candidate generation should be policy-filtered:
Candidate Concepts
↓
Policy Filter
↓
Allowed Clarification Options
Authorization therefore affects not only execution but also what the system is allowed to discuss.
Explain Denials in Business Terms
A natural-language interface should not return:
SQLSTATE 42501
permission denied
when the real issue is semantic.
A better response might be:
This question would reveal restricted employee compensation information. You can query department-level operating cost, but not derived salary information.
This improves both security and user experience.
The system can explain:
What category is restricted
What level is allowed
What alternative question is permitted
without exposing sensitive details.
Don't Try to Solve Every Possible Inference
There is an important practical limit.
If two harmless numbers can theoretically be combined into sensitive information, trying to enumerate every possible derivation can become impossible.
So focus governance on high-impact semantic concepts.
Examples:
Compensation
Protected Personal Information
Credit Risk
Confidential Pricing
Sensitive Forecasts
Health Information
Then model known derivation patterns and business policies around those concepts.
The goal is not mathematical prevention of all inference.
It is business-risk-aware governance.
A Practical Policy Model
One possible abstraction:
concept: employee_compensation
sensitivity: restricted
direct_access:
allow:
- hr
- executive
derived_access:
allow:
- hr
- executive
related_metrics:
- salary
- bonus
- estimated_average_salary
restricted_derivations:
- department_cost / employee_count
Another:
relationship:
source: employee
target: cost_center
trusted: true
traverse:
allow:
- finance
- hr
This makes policy part of semantic and relationship metadata rather than an afterthought.
Audit the Reasoning Path
When a query is allowed or denied, log why.
{
"user": "sales_manager",
"question": "What is the average salary in engineering?",
"resolved_intent": "employee_compensation",
"policy_decision": "deny",
"reason": "derived_access_not_allowed"
}
For allowed queries, record:
Semantic concepts used
Relationship path
Metrics selected
Policy decisions
Generated SQL
This creates an audit trail that is much more useful than logging SQL alone.
Test Authorization With Adversarial Questions
Enterprise data-agent security testing should include inference cases.
For example:
Direct request
Show individual employee salaries.
Expected:
DENY
Derived request
Divide engineering payroll cost by headcount.
DENY
Allowed aggregate
Show total engineering operating cost.
ALLOW
Relationship traversal
Join employee records with cost-center financials.
ROLE DEPENDENT
These tests reveal whether the system governs meaning or only columns.
What to Measure
Useful authorization metrics could include:
Direct Sensitive Query Block Rate
Derived Sensitive Query Block Rate
False Denial Rate
Unauthorized Relationship Block Rate
Policy Explanation Accuracy
A secure system that denies every complex query is not useful.
The goal is:
Maximum useful access
within authorized semantic boundaries
A Reference Architecture
Putting everything together:
Natural Language
↓
Identity
↓
Intent Resolution
↓
Semantic Policy
↓
Authorized Context
↓
Authorized Relationship Graph
↓
Query Planning
↓
Policy-Aware Plan
↓
SQL Generation
↓
Database Enforcement
↓
Execution
↓
Answer Policy Check
↓
Return / Explain / Deny
RBAC remains underneath this architecture.
The new layers do not replace database security.
They extend governance into the reasoning process.
Final Thoughts
Enterprise data agents make databases easier to use because users no longer need to know schemas or SQL.
That abstraction is powerful.
It also means users can ask for information without knowing which fields, tables, joins, or calculations the agent will use.
So authorization has to follow the same abstraction upward.
From:
Who can access this table?
to:
Who can use this business concept?
and finally:
Who can receive this derived answer?
That is why RBAC alone is not the whole solution for AI-powered analytics.
Keep RBAC.
Keep row- and column-level controls.
But add governance around:
Intent
Semantics
Relationships
Derivations
Answers
Because:
Table access ≠ Answer access.
And:
A production data agent should not only know how to find an answer.
It should know whether it is allowed to reveal it.