DEV Community

ArisynData
ArisynData

Posted on

Why RBAC Alone Isn't Enough for Enterprise Data Agents

#agents #ai #llm #sql

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?
Enter fullscreen mode Exit fullscreen mode

An AI analytics system also needs to ask:

Is this user allowed to receive what the system can infer from those objects?
Enter fullscreen mode Exit fullscreen mode

Consider a simple example.

A user cannot access:

employee.salary
Enter fullscreen mode Exit fullscreen mode

But the same user can access:

department.total_cost
department.employee_count
Enter fullscreen mode Exit fullscreen mode

A capable data agent can derive:

estimated_average_salary
=
department.total_cost
/
department.employee_count
Enter fullscreen mode Exit fullscreen mode

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:

Table access ≠ Answer access.

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

But:

{
  "resource": "department.total_cost",
  "action": "read",
  "effect": "allow"
}
Enter fullscreen mode Exit fullscreen mode

and:

{
  "resource": "department.employee_count",
  "action": "read",
  "effect": "allow"
}
Enter fullscreen mode Exit fullscreen mode

The agent creates:

f(total_cost, employee_count)
→ estimated_average_salary
Enter fullscreen mode Exit fullscreen mode

Every input is authorized.

The derived concept may not be.

Call this the inference gap:

Authorized Inputs
      ↓
Reasoning / Aggregation
      ↓
Restricted Information
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

define a semantic concept:

{
  "concept": "employee_compensation",
  "direct_access": "deny",
  "derived_access": "deny"
}
Enter fullscreen mode Exit fullscreen mode

Now a request such as:

What is the average salary of the engineering team?

can be resolved first:

Intent
→ Employee Compensation
Enter fullscreen mode Exit fullscreen mode

Then evaluated:

Employee Compensation
→ DENY
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A generic context retriever might return all concepts semantically related to the question.

That is risky.

Instead:

Candidate Context
      ↓
Identity + Policy
      ↓
Authorized Context
      ↓
LLM
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The path is structurally valid.

But a Sales user may not be allowed to traverse it.

So distinguish:

Trusted Relationship
Enter fullscreen mode Exit fullscreen mode

from:

Authorized Relationship
Enter fullscreen mode Exit fullscreen mode

A relationship object could carry policy metadata:

{
  "source": "department",
  "target": "cost_center",
  "status": "trusted",

  "policy": {
    "allowed_roles": [
      "finance",
      "hr"
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

Then query planning uses a user-specific graph:

def authorized_graph(graph, user):
    return graph.filter(
        lambda edge: policy.can_traverse(user, edge)
    )
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For a Sales user:

Customer ─ Order ─ Payment
Enter fullscreen mode Exit fullscreen mode

may be available.

But:

Employee ─ Department ─ Cost Center
Enter fullscreen mode Exit fullscreen mode

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"]
  }
}
Enter fullscreen mode Exit fullscreen mode

Why distinguish them?

Because an organization might allow:

Department Cost
Enter fullscreen mode Exit fullscreen mode

but restrict:

Individual Compensation
Enter fullscreen mode Exit fullscreen mode

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           ✕
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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."
Enter fullscreen mode Exit fullscreen mode

The system needs evidence from:

Original Intent
Resolved Semantic Concepts
Selected Metrics
Query Plan
Aggregations
Relationship Path
Output Columns
Enter fullscreen mode Exit fullscreen mode

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 ...
Enter fullscreen mode Exit fullscreen mode

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"
  ]
}
Enter fullscreen mode Exit fullscreen mode

Now authorization has something meaningful to evaluate.

This is another reason production Text-to-SQL should not be treated as:

Question → SQL
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

The system can stop before execution.

For a different user:

{
  "role": "HR Partner",
  "decision": "allow"
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Another:

relationship:
  source: employee
  target: cost_center

trusted: true

traverse:
  allow:
    - finance
    - hr
Enter fullscreen mode Exit fullscreen mode

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.

Example:

{
  "user": "sales_manager",
  "question": "What is the average salary in engineering?",

  "resolved_intent": "employee_compensation",

  "policy_decision": "deny",

  "reason": "derived_access_not_allowed"
}
Enter fullscreen mode Exit fullscreen mode

For allowed queries, record:

Semantic concepts used
Relationship path
Metrics selected
Policy decisions
Generated SQL
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Derived request

Divide engineering payroll cost by headcount.

Expected:

DENY
Enter fullscreen mode Exit fullscreen mode

Allowed aggregate

Show total engineering operating cost.

Expected:

ALLOW
Enter fullscreen mode Exit fullscreen mode

Relationship traversal

Join employee records with cost-center financials.

Expected:

ROLE DEPENDENT
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A secure system that denies every complex query is not useful.

The goal is:

Maximum useful access
within authorized semantic boundaries
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

to:

Who can use this business concept?
Enter fullscreen mode Exit fullscreen mode

and finally:

Who can receive this derived answer?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Because:

Table access ≠ Answer access.

And:

Valid relationship ≠ Authorized relationship.

A production data agent should not only know how to find an answer.

It should know whether it is allowed to reveal it.

Top comments (1)

Collapse
 
pushpendra_agrawal_f1bdfa profile image
Pushpendra Agrawal •

The distinction between direct_access and derived_access is the part most RBAC setups skip entirely. Curious how you handle the perf cost though - resolving intent and checking policy at the concept layer before SQL generation means every question now needs a semantic resolution step even for simple, fully-authorized queries. Do you cache the authorized concept graph per user/role, or is it recomputed per request?