Designing Access Control for a Multi-Department Enterprise AI Platform

Access control for a multi-department AI platform cannot stop at who may sign in. Every request should pass four checks: user, data, tool and action — who is asking, what they may see, which capability they may call and how far the operation may go. If one layer fails, the request is denied, degraded or routed for approval.

This article covers runtime platform authority: access to business data, tool calls, writes and execution. Document and retrieval permissions inside a knowledge base are a separate problem; one generic "may access" rule cannot replace both controls.

Write permission as a complete business decision

An enforceable rule must say which subject, in which context, may act on what data, through which tool, and perform which action. For example: "An East China salesperson may use the CRM tool to create a follow-up draft for customers assigned to them; external sending requires their confirmation." A rule that merely says "sales may use the CRM assistant" leaves data scope, action boundary and confirmation responsibility undefined.

Least privilege does not mean granting as little as possible regardless of the task. It means granting enough to complete the current task while denying everything else by default, and bounding the duration and impact. The Access Control family in NIST SP 800-53 includes least privilege as an explicit control. On an AI platform, access to a chat entry point must not quietly include export, write, send and bulk-execution authority.

Distinguish direct permission, approval required and prohibited. AI may initiate a request, but deterministic policy and the source system make the final authorisation decision, so the platform need not choose between all-open and all-closed.

A request must pass user, data, tool and action gates

The user gate checks that identity is valid, the person's organisation, role and account state, and whether the session meets the required authentication strength. The data gate checks whether the customer, order, field and time range fall within that person's business scope. The tool gate determines whether the platform may let them call CRM, ERP, mail or file-export connectors. The action gate decides whether this particular call may only read or draft, or may modify, send or execute.

The four layers form an intersection; none can substitute for another. A finance manager's right to view a class of payment data does not mean the AI platform may call the payment tool. A platform's payment connector does not let the user approve their own payment. Recheck in the backend immediately before the target call. Hiding a button in the interface is not enforcement, and asking a model to restrain itself in a prompt is not authorisation.

NIST zero trust architecture rejects implicit trust based on network location or managed-device ownership. A corporate-network login is only context; subject, resource and action still need individual decisions, limiting forwarded links, stolen sessions and out-of-scope calls.

User permission must follow join, move and leave events

The user layer begins with a reliable identity. Where the organisation already has a central identity service, the AI platform should reuse sign-in, organisation and account status rather than maintain a second, slowly diverging list. Standards such as SCIM — System for Cross-domain Identity Management — can manage users and groups across systems, though adoption depends on the existing architecture. The essential requirement is that personnel changes reach the platform promptly.

Roles carry stable commonality such as "sales representative" or "finance reviewer"; business attributes define region, project and account scope. Two salespeople share tools but see only their customers. A temporary project member receives an expiring scope, not a permanent management role.

Moves are easier to miss than joins. A salesperson transferring into operations receives new permissions while old customer-export access may remain. When a departing employee's account is disabled, personally created automations and long-lived tokens may continue running. Lifecycle handling must cover interactive sign-in, API tokens, delegated tasks, shared-space ownership and pending approvals. Revocation has to reach the machine acting for the person, not just the page account.

Data permission constrains business objects and fields, not only pages

The data layer decomposes "business data access" into object, record and field. Object scope decides whether a person may touch customers, contracts, orders or employee records. Record scope narrows that to self, project, region or company. Field scope removes identity documents, cost, salary or other unnecessary content. Enforce these controls in the data service or source application; do not give the model everything and rely on a promise not to disclose it.

Purpose and output scope belong in the decision too. An employee may inspect the order needed to resolve one customer issue without being allowed to export every customer in the region for personal analysis. Permission to create an internal aggregate does not permit mailing raw records externally. The management framework for enterprise AI data boundaries helps set policy; platform access control turns it into query predicates, field filtering, masking and export restrictions.

When data permission changes, update caches, indexes and conversation history too. After a user leaves a project, old caches must not return summaries and historical chats must not reveal new details. Recheck permission on every retrieval and action, not once at session start.

Tool permission decides which hands the AI may extend

Tools connect AI to external capabilities: business APIs, email, calendar, files, search, code execution and automation connectors. How Function Calling works explains how a model forms a tool request. Permission design adds the crucial boundary: the model's ability to emit a call does not oblige the executor to accept it. The platform owns the tool inventory and credentials; a model cannot discover and activate an unauthorised connection by itself.

Give each tool its own service identity, eligible user scope, permitted environment and call limits. Do not hide one administrator credential inside a connector shared by every department, and do not make several tools share an indistinguishable long-lived secret. At request time, intersect user authority with service authority. If the service can query all company orders but the user owns one region, the effective query remains inside that region.

Tools also need independent shutdown and replacement. If a mail connector malfunctions, disable external sending without breaking internal question answering. During ERP maintenance, degrade to "live status unavailable" rather than asking AI to invent an answer. The service identity, logging and rollback design for business connectors can follow the risk ladder for connecting AI to ERP and OA.

Action permission separates using a tool from reading, writing and executing

The same CRM tool can look up a customer, create a draft, change a formal record, export in bulk or send a message. A single "may use CRM" permission erases those risk differences. Define an action ladder: read a fact; generate without persistence; create a draft; change specified fields; submit for approval; send externally; trigger an irreversible or high-impact action. Configure eligible roles, data scope, impact limit and approval requirement for each step.

High-impact operations require separation of duties. The requester need not be the approver; the person configuring policy should not single-handedly approve their own exception; the auditor should not alter the logs under review. If AI creates a supplier-payment proposal, a business user may initiate it, a finance reviewer approves, and the payment system applies its own rules. The platform must not collapse those identities into one "finance administrator".

Human approval must bind to specific content and a version. "AI may send mail" is too broad; approve the recipient, subject, attachment, body version and send time. A content or attachment change invalidates the earlier approval. For outputs requiring review, the tiered method for reviewing AI output helps match impact to an appropriate gate.

Context and temporary grants handle legitimate exceptions

Roles and departments cannot express every situation. Also evaluate environment, device and session risk, on-duty state, action impact and frozen data. Context is not an invitation to accumulate rules; it prevents permission from being reused at the wrong time.

Temporary access needs a reason, approver, explicit scope, expiry and usage record. It expires automatically instead of relying on the requester to return it. Emergency access may have a break-glass path: a named operator can proceed when normal timing is impossible, but an alert is raised immediately, a reason is mandatory, and use receives after-the-fact review. Break glass is not a hidden superuser; it is a transparent, short-lived, accountable exception.

Prevent authority from spreading through sharing. When a user shares an AI application, it must not also share their data and tool credentials. Copying a workflow must not copy the creator's privileged token. The recipient runs it under their own identity and passes all four gates again; if they do not qualify, the platform requests approval or provides a restricted version.

Prove the design with a permission matrix, negative tests and audit

Before launch, map representative roles to data scope, tools, actions, approvers and exception conditions, covering common paths and high-impact boundaries. Test legitimate success and attempted overreach: cross-region queries, direct calls behind hidden buttons, expired-token reuse, modified approved content and bulk requests that evade a per-action limit.

Audit evidence should answer who acted under which identity and context, on what data, through which tool, attempting or completing which action, under which allow or deny policy, and who approved which version. Log access is itself restricted, with retention, search and anomaly alerts. Conversation text without tool and policy records cannot reconstruct business impact; an endpoint success code without an initiator cannot establish accountability.

In operation, review unused grants, transfer residue, long-lived temporary access, unusual denials, shared applications and service credentials. Permission changes with the organisation and tool estate; no design stays correct forever. The production checklist from AI pilot to launch covers the associated ownership, monitoring and rollback work.

The core of enterprise AI access control is not creating more roles; it is giving every real action a complete authorisation chain. The user layer establishes the subject, the data layer limits visible facts, the tool layer limits callable capabilities, and the action layer limits possible outcomes. Context, approval and audit bind them together, so departments share one platform rather than one master key.