AI Assistant Access Control: Stop Answers from Unauthorized Data

An assistant can produce a factually correct answer and still fail because it used another customer’s invoice or an employee file the requester cannot access. The control is not a prompt saying “do not reveal data.” Authorization must happen before search and retrieval, only permitted sources should reach the model, and isolation must be tested like any other enterprise permission.

NIST SP 800-207 on zero trust architecture states that trust is not implied by network location or asset ownership, and that authentication and authorization occur before a session to an enterprise resource is established. The NIST AI RMF Manage playbook addresses prioritizing, responding to and managing assessed AI risks. The workflow below is a business implementation, not a certification or a substitute for security, privacy and legal review.

Separate four layers that rushed projects combine

• Authentication: who is the user or system asking the question?
• Authorization: which resources, fields and actions can that identity access now?
• Retrieval: which passages among the permitted sources match the request?
• Generation: how should the model express an answer from the approved context?

If the system searches every file and asks the model to hide restricted results, exposure has already occurred inside the processing path and can surface in an answer, log or tool. Filter by authorization before retrieval where possible and re-check before any action.

Make ownership part of every source

Label each record or document with tenant or customer identity, data class, owner, permitted roles and effective date. Do not rely on a free-form folder called “important clients.” The authenticated user’s context must reach the retrieval layer on every request, and the question itself must never be able to modify that context.

This extends a trusted knowledge base with a different question: who may see the source? It connects to the cost-of-error release gate because cross-customer exposure should be a prohibited failure, and to AI incident logging for attempts or exposures after launch.

Apply least privilege to data and tools

Do not give the assistant a service account that can read everything merely because the interface displays narrow answers. Use a short-lived token bound to the user, account and request. Reduce fields to what the use case needs. An invoice-status assistant does not need a complete bank account number or unrelated contracts.

Separate reading from execution. A role may view a balance without being allowed to issue a refund. Require a fresh authorization decision before a consequential action, and log user identity, source, decision and tool. Do not record full sensitive content just to make model debugging easier.

A hypothetical case: access control has cost and return

Assume 100,000 conversations per month, of which 20,000 require account data. An old test shows isolation failure in 0.15% of account requests, or thirty expected cases. For investment prioritization only, management assigns QAR 3,000 of estimable response, support and disruption cost to each case, or QAR 90,000. That figure excludes harms that cannot be priced and any legal consequence.

An authorization gateway and decision logs cost QAR 12,000 per month. Testing reduces the failure rate to 0.02%, or four cases with QAR 12,000 of assumed impact. The gateway also causes 1,000 additional human referrals at QAR 8 each, or QAR 8,000. Estimated total is QAR 32,000, QAR 58,000 below the baseline.

Every number is hypothetical, not data attributed to Fahad ALNaimi or any company. More importantly, a cross-customer disclosure may be an absolute release blocker even when average cost falls. The financial model prioritizes investment; it does not make a prohibited exposure acceptable.

Test isolation as if the question were hostile

1. Create two test tenants with similar data and unique markers that would not appear naturally.
2. Test direct questions, indirect summaries, comparisons and export requests.
3. Change the role mid-session and verify that old context is invalidated.
4. Break the authorization service deliberately; access should fail closed.
5. Repeat in Arabic and English, with misspellings and uploaded files.

Avoid real customer data when synthetic records can prove the control. Log the decision and source identifier rather than full content. Review false denials so security does not become an excuse to send every question to an employee.

Monitor security and service together

Track denied retrieval attempts, isolation-test pass rate, unlabelled sources, cross-account access events, authorization latency, false-denial rate and human referrals. Unauthorized-source exposure should be a stop condition. Latency and referral measures help improve customer experience without weakening the gate.

The design fails when permission is embedded only in model-visible text, conversation memory survives a role change, search indexes contain unlabelled copies, or tools bypass the data gateway. It also fails when logs collect more secrets than the original system.

The operating decision is clear: block retrieval before context reaches the model, bind every source to an owner and role, and test separation between two tenants with a fail-closed path. Do not release a customer-data use case until it passes isolation tests and neither the user prompt nor the model can expand the caller’s authority.

اقرأ المقال بالعربية