为什么仅靠 RBAC 不足以支撑企业数据 Agent

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.