6.2.3. Access Controls on Grounding Data and Model Tuning
💡 First Principle: Access controls for AI systems must cover both who can configure the AI (model tuning, prompt editing, knowledge source management) and what data the AI can access (grounding data, training data, inference data). These are separate security boundaries — conflating them creates privilege escalation paths.
Dual Access Control Model:
| Boundary | Who | What They Access | Controls |
|---|---|---|---|
| Configuration access | Developers, data scientists, prompt engineers | Model weights, system prompts, fine-tuning data, RAG configuration | Role-based access, approval gates, change auditing |
| Runtime data access | The AI agent at inference time | Knowledge bases, databases, APIs, user context | Connector permissions, row-level security, data classification |
Grounding Data Security:
When an agent retrieves data from knowledge sources during RAG, it must respect the same access controls as the user it's serving. If User A can't see confidential HR documents, the agent shouldn't surface those documents in User A's conversation — even if the agent's connector technically has access. This requires designing identity-aware retrieval where the agent queries data sources using the user's identity, not a service account.
Model Tuning Security:
Fine-tuning a model with proprietary data creates a new security artifact — the fine-tuned model itself. That model may memorize training data, creating a potential data exposure vector. Access controls must cover: who can initiate fine-tuning, which data can be used, who can access the resulting model, and how fine-tuned models are retired when the underlying data changes.
Data Classification for AI:
| Classification | AI Access Rule | Example |
|---|---|---|
| Public | Available for all AI grounding and training | Marketing materials, public documentation |
| Internal | Available for internal-facing agents only | Internal policies, org charts |
| Confidential | Available only with explicit authorization; identity-aware retrieval | Customer PII, financial data, HR records |
| Restricted | Never used for AI grounding or training | Trade secrets, legal privilege, regulated data |
Troubleshooting Scenario: A company fine-tunes a language model with proprietary customer interaction data. Six months later, they discover the fine-tuned model occasionally generates text that closely mirrors specific customer conversations, including names and account numbers. The model effectively memorized sensitive training data. This creates dual risk: privacy violation (PII in outputs) and intellectual property exposure (proprietary data accessible through the model). Prevention requires: PII anonymization before fine-tuning, output filtering for sensitive patterns, and periodic testing of the fine-tuned model for memorization artifacts.
The dual access control model for AI systems means securing both the traditional boundary (who can call the AI service) and the knowledge boundary (what data informed the AI's responses). A user with legitimate API access should not be able to extract training data through clever prompting.
Reflection Question: A company fine-tunes a model on customer support transcripts. Six months later, they discover the model occasionally reproduces specific customer details in responses to unrelated queries. What access control and data handling failures led to this, and what architectural changes prevent it?
