Why RBAC Alone Isn't Enough for Enterprise Data Agents

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: estimated_average_salary = 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: 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 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. But: 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. Example: { "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. Expected: DENY Allowed aggregate Show total engineering operating cost. Expected: ALLOW Relationship traversal Join employee records with cost-center financials. Expected: 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: 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.