Enterprise AI Starts With Access Controls

Connecting an AI assistant to company records changes the consequences of an ordinary access-control mistake. A system can summarize information quickly and combine details from many sources. If it receives documents the user should not see, the resulting answer can disclose them without ever displaying the original file.

The first enterprise question is therefore which information and actions are available to the current user. A reliable answer engine cannot compensate for an unrestricted connection to payroll, customer records or confidential negotiations. Access boundaries must remain effective throughout retrieval, generation and any subsequent tool use.

Apply authorization before information reaches the model

Authentication establishes identity; authorization determines permitted access. NIST's zero-trust architecture treats resource access as a decision requiring explicit evaluation, rather than assuming trust because a request originates inside a corporate network. An AI interface does not remove that distinction.

Consider a hypothetical company with 10,000 indexed documents, of which one employee is entitled to read 2,000. A search returning the five most relevant documents from all 10,000 can expose restricted content even if the final answer includes a reminder about confidentiality. The retrieval process needs to respect the employee's permissions before passing content onward.

A shared service account creates an additional design question. Its ability to read a repository may exceed that of the person asking the question. Applying the user's authorization within the retrieval layer is different from simply confirming that the service account itself has access.

Source text can contain instructions

OWASP describes prompt injection as a risk in which content influences a model in ways that conflict with the application's intended instructions. In a connected assistant, an external page or retrieved document may contain text that looks like an instruction to the system. Treating that material as trusted authority can cross a boundary between information and control.

A hypothetical support assistant might read a customer attachment containing a request to forward internal case notes elsewhere. The attachment is material to analyze, not an authorization from the employee or company. Whether such a request can cause harm depends heavily on the tools and permissions the application has granted.

Filtering suspicious wording can help identify some inputs, but it does not establish a complete security boundary. Tool authorization and destination controls need to function even when the model produces an unexpected request. This separates a model's proposed action from the system's decision to execute it.

Read access and write access create different exposures

An assistant allowed to search a calendar has a different capability from one allowed to cancel events or invite external participants. OWASP's excessive-agency analysis focuses on the risks created when applications provide too much functionality, permission or autonomy. The business process should determine the necessary scope.

For example, a hypothetical invoice assistant might draft a payment recommendation without being allowed to change bank details or release funds. A separate authorized step can validate the amount, recipient and action. This is a workflow design choice, not a claim that a person clicking approve will detect every error.

The distinction also affects AI-agent economics. Removing a review step may shorten processing time while increasing the consequences of an error. A productivity comparison that ignores the changed authority is comparing two different operating models.

Retention and confidentiality need their own review

Access control answers who may obtain information. Retention, logging and provider handling determine where that information may persist afterward. Whether customer data is used for training is another question. A statement about one of these properties should not be treated as proof of all the others.

Suppose a hypothetical system correctly retrieves a confidential document but writes its contents into a broadly accessible troubleshooting log. The original repository's permissions remain intact, yet a second disclosure path has been created. Logs, caches, exports and support workflows belong in the data-flow assessment.

NIST's generative-AI risk profile provides broader context for privacy, information security and evaluation. It is a voluntary risk-management resource, not a certification that a particular deployment satisfies every contractual or legal obligation. Those depend on the actual data, agreements and applicable requirements.

Test boundaries as well as ordinary answers

A useful evaluation includes users with different roles, revoked access, sensitive documents and tools with different permissions. The expected behavior should be specified in advance. A system that answers routine questions accurately may still fail when document permissions change or when a user requests an action outside their role.

Audit records should make it possible to identify the requesting identity, consulted sources and executed action while limiting unnecessary sensitive content. Incident response also needs a way to suspend a connection or credential and investigate its scope. Logging everything indefinitely is not automatically the safest design.

Compare the time saved with the costs of these controls, as discussed in completed-task economics. Enterprise AI becomes useful when it operates within an enforceable authority boundary. Fluency and factual accuracy are separate properties from permission to access a record or change it.