AI Integration Access Control

Access control for an AI integration must answer a precise question: may this verified identity perform this operation on this resource, under the current conditions? A model's willingness to comply, a user's confident wording and a valid service credential are not substitutes for that decision.

This guide is for identity teams, application owners and engineers connecting assistants to protected business systems. It separates the human requester, the application workload and the approver, then shows how to enforce their boundaries at retrieval and execution. The worked example uses a project coordinator whose regional access must not expand to match a central service account.

Keep three identities distinct

The requester is the person initiating the task. The workload identity is the service that communicates with systems. The approver is the person or authorised process accepting a particular consequential action. One individual may hold more than one role, but the evidence should still distinguish the role being exercised.

Authentication establishes the identity presented by a supported mechanism. Authorisation decides what that identity may do. Approval records a decision about a particular proposed action. Logging into the application does not authorise every resource; approving a proposal does not grant the executor unlimited future access.

NIST SP 800-207A discusses access controls based on application and service identities alongside user identities in cloud-native environments. Use that separation to identify the actual actors in your integration. Do not treat the assistant's conversation persona as an authenticated identity.

Define the permission decision as a resource-action rule

A useful policy input includes the verified requester, workload, resource identifier, operation, relevant organisational scope and current context. Depending on the task, context may include resource state, delegation expiry, approval reference or required separation of duties. Use only trusted sources for these attributes.

Role-based permissions can establish a person's general responsibilities, while resource attributes can narrow them to the relevant project or subsidiary. The exact policy technology is less important than an unambiguous rule and an enforcement point. A role called “manager” is too vague if different managers can see different records or authorise different actions.

Define the effective operation as constrained by the applicable requester permissions, workload capability, destination rules and current policy. This is a design principle, not a claim that every platform computes a simple mathematical intersection automatically. Where the source system uses a service account, the application must prove how the human boundary is preserved.

Worked example: a regional coordinator meets a central service account

In an illustrative project-management integration, a coordinator may read projects in Region A and propose approved status notes for selected projects. The integration's central service identity can reach projects across several regions because it also supports other teams. The coordinator asks the assistant to add a note to project W40 in Region B.

If the executor checks only whether the service credential can write W40, the request succeeds despite the coordinator's narrower authority. Asking the model to confirm the user's region does not fix the defect. The authorisation decision must use the verified user context and authoritative project ownership before exposing data or attempting a write.

The proposed policy denies the cross-region operation. For an allowed project A12, a write additionally requires an authorised reviewer to approve the exact note and target while the project remains eligible. These are illustrative project rules; another organisation may choose different approval requirements. The implementation must encode the rules it has actually agreed.

A later transfer of A12 to another region also matters. A proposal created while the coordinator had access should not bypass a current access check at execution. Preserve the reason for denial and offer an appropriate escalation path without revealing restricted project details.

Use a twelve-case permission test pack

Illustrative access-control acceptance cases

Case	Request condition	Expected outcome
1	Read an eligible project in the requester's region.	Allow the permitted fields.
2	Read another region's restricted project.	Deny without exposing its content.
3	A read-only user attempts a note write.	Deny the operation.
4	A permitted writer has no required approval.	Keep the proposal pending.
5	Current authority and exact approved payload are present.	Allow the specified action.
6	The note text changes after approval.	Require renewed review.
7	The approved target is replaced by another record.	Reject the substituted target.
8	The approval has expired.	Do not execute under it.
9	The requester's access is revoked before execution.	Deny according to the defined revocation policy.
10	The action is outside the workload's tool scope.	Deny even if the requester has broader rights elsewhere.
11	The project enters a state that prohibits the change.	Return for reconsideration.
12	The required policy decision is unavailable.	Do not perform the protected write.

Run these cases with real test identities and deployed policy configuration. A mocked permission function cannot establish that the destination account, retrieval service and execution gateway all apply the same boundary. Include both the user-visible result and the destination's actual state in acceptance evidence.

Enforce access before retrieval and again before action

Retrieval should not expose records simply because the model might later decline to mention them. Apply the appropriate source permissions before content enters the model context. If the source cannot support the required user boundary directly, use a controlled layer with an explicit policy and tests rather than relying on a natural-language instruction.

At execution, re-evaluate the conditions that can change. The OWASP authorisation guidance recommends denying by default and validating permissions on every request. In an AI integration, ensure that alternative tools, retries and support actions also pass through the relevant enforcement point.

Permission-aware RAG architecture develops the retrieval boundary. Guardrail implementation covers checks around the proposed tool action. Keep these controls complementary: filtering a response after retrieval does not undo the exposure of unauthorised context to the model.

Bind approval to a specific action

An approval record should identify the target, allowed operation, executable values, relevant context, approver and validity conditions. Store it in a trusted service, not as editable conversation text. If a payload fingerprint is used, define exactly what it covers and how the executor verifies it. A hash alone does not authenticate an approver or establish their authority.

Prevent substitution between review and execution. A user should not approve a note for A12 and then have the client change the target to W40 while retaining the approval reference. Likewise, a tool should not add an unreviewed field to an approved payload. The executor checks that the requested action is the action actually approved.

For sensitive tasks, decide whether the requester may approve their own proposal or whether a separate role is required. That is a business and control decision, not a universal property of AI. Document it explicitly, test it and preserve enough audit evidence to show which identities performed each step.

Design revocation and cache behaviour together

Access can change after a token is issued or a result is cached. Record how quickly each relevant component recognises revocation and what evidence supports that expectation. Do not promise immediate revocation across every token, session and cache unless the actual mechanisms deliver it.

For consequential actions, use an appropriately current authority check at the execution boundary. For cached answers, bind reuse to the relevant identity and permission context and define invalidation when access changes. AI caching strategies explains why matching question text is insufficient justification for sharing a result.

Test group removal, disabled service identities, expired approvals and a project moving between scopes. Include a request already waiting in a queue. Its earlier admission does not necessarily authorise later execution after conditions change. An exception process should be explicit, time-limited and reviewable rather than a hidden bypass.

Make support and administrative access visible

Support teams may need diagnostic access without permission to perform business actions. Separate the ability to inspect an error from the ability to replay a write, change a policy or impersonate a user. A repair tool with broad privileges can undermine a tightly constrained assistant if it is not governed by comparable rules.

Review who can alter role mappings, tool scopes and source-ownership attributes. These are control-plane operations with direct effects on authority. Security architecture places them in the wider trust-boundary map. Log the changes and periodically verify that the deployed permissions still match the accepted design.

Keep denial messages useful but restrained. An authorised operator may need a policy reference and corrective route; an ordinary user should not learn sensitive record details from an error. Distinguish a missing permission from an unavailable policy service internally so that operations can act without weakening the decision.

Turn the policy into a delivery contract

The implementation handover should include the identity map, resource-action rules, approval contract, revocation behaviour, twelve-case test results and exception procedure. Assign owners to the source attributes and policy changes. These artifacts make permission reviews concrete and reduce reliance on undocumented assumptions inside a connector.

For AI integration and delivery with OpenForAI, bring a masked role matrix and two examples: an action that should succeed and one that a broadly privileged service could perform but the requester must not. Enquire about access-controlled AI integration around that boundary so that permission correctness can be demonstrated before expanding the tool set.