Permissions and Provenance for AI Systems

A joint-venture contractor can have legitimate access to one project's drawings and no right to see another project's material. An AI assistant connected through a broad service account may nevertheless be able to retrieve both. A correct answer about the second project would still be an access failure. Before testing answer quality, the organisation needs to establish whose permission is being exercised and how that decision survives the complete retrieval path.

Provenance addresses a related but separate question: which source, version, transformation and responsible party support an output? Permission can allow a person to read an obsolete drawing. Provenance can identify a restricted source without authorising disclosure. AI readiness requires the two records to work together, while preserving the difference between the right to use information and the evidence explaining where it came from.

This guide develops a practical method for enterprise security leaders, data owners and delivery teams. It uses a fictional engineering handover assistant, an original permission matrix and a revision-aware evidence record. The proposed controls and tests are assessment designs to adapt to the organisation's requirements, not a claim that a named vendor implements them automatically.

Identify the principal behind each operation

List the operations separately: source discovery, ingestion, indexing, retrieval, generation, export and administrative inspection. Record the identity used at each boundary and how it relates to the requesting person or approved workload. A service principal may need a broad ingestion role while individual users must still receive only authorised results. Its technical access must not silently become the business permission of every user.

Identify tenant, organisation, project and document boundaries explicitly. A username or email address is not always a sufficient cross-system identity key. The same display name can belong to different accounts, and an external collaborator can have different roles in separate projects. Record the identifiers and authoritative membership source that the access decision actually uses.

NIST's attribute-based access-control guidance describes evaluating subject, object, requested operation and, where relevant, environmental attributes against policy. That is a useful vocabulary for a readiness review. It does not prescribe one product or mean that collecting attributes is enough: the project must show where the policy is evaluated and whether missing or stale attributes are handled appropriately.

Write the intended decision in business terms before mapping it to technology. For example, an approved subcontractor may read released handover drawings for the assigned project, while draft documents remain limited to designated reviewers. Define who approves membership and document release. The engineering team can then examine whether the current repositories, index and application can enforce that rule.

Separate discovery restrictions from access enforcement

Hiding a document from a search result is different from denying access to its contents. A user might still reach it through a direct link, a shared summary, an alternate search route or an application export. Conversely, a document that can be discovered may have a separate enforcement step before its contents are returned. Evaluate the actual architecture rather than treating a visibility setting as a universal security boundary.

Where Microsoft services are involved, the SharePoint and Teams readiness guide examines the relevant product controls and their current limitations. The general requirement remains the same across platforms: identify what each control changes, what it leaves possible and which identity the operation uses. A configuration name cannot replace an allowed-and-denied access test.

Inspect ingestion and retrieval independently. A protected repository does not prove that its access information reaches a separate index. Record whether document-level restrictions, project membership and version information are preserved, transformed or lost. If the index stores an access snapshot, establish how it learns about changes and how the application treats an outdated snapshot.

Do not ask the language model to decide the user's rights from document text or a persuasive request. Policy enforcement belongs in an appropriate trusted control path. Retrieved content can inform an answer but should not grant a new identity or permission. Assess prompt-based instructions as part of behaviour testing, while keeping the authorisation decision outside untrusted content.

Worked permission matrix for an engineering handover assistant

Assume a fictional joint venture prepares a checklist of released drawings for project handover. The assistant proposes references for review; it does not approve engineering designs or issue construction instructions. The organisation defines the following eight cases to examine its proposed access policy. They are purposeful control tests, not a probability sample of all user activity.

Illustrative allowed-and-denied cases for handover retrieval

Case	Identity and requested material	Expected result under the proposed policy
1	Authorised project reviewer requests a current released drawing for the assigned project	Allow the approved material and record the source version
2	Assigned subcontractor requests a released drawing within its agreed handover scope	Allow within that scope
3	The subcontractor requests a working draft reserved for reviewers	Deny disclosure through the ordinary assistant
4	The subcontractor requests a released drawing from another project	Deny despite the service account's wider ingestion access
5	A former project member requests material after the membership removal takes effect	Apply the current removal decision
6	A support administrator without the relevant business role makes an ordinary user query	Deny through that business path; any exceptional access is separately governed
7	A service identity attempts an end-user answer without a valid authorised workload or user context	Do not infer permission from ingestion credentials
8	A request uses a cached membership result after the relevant access has been revoked	Enforce the defined current-access condition rather than silently reuse an obsolete grant

Two cases expect access and six examine restrictions or invalid contexts. A denial-only test set would not show whether legitimate users can perform the job. An allow-only set would not examine the boundaries. The matrix also distinguishes a missing business role from a separately approved administrative procedure, avoiding the false assumption that every technical administrator must receive unrestricted business answers.

Define the evidence for each expected result. An answer saying “I cannot help” is insufficient if restricted text already entered the model context or appeared in a diagnostic trace. Inspect the relevant retrieval decision and downstream path with authorised synthetic material. Record what the team can observe and any component for which access prevents a complete conclusion.

Also test useful partial results. If a user is allowed to see two released drawings but not an attached draft, the permitted response must retain enough context to be accurate without revealing the restricted attachment. Where the remaining evidence cannot support the requested conclusion, the assistant should make the limitation clear rather than fabricate a complete handover status.

Trace the version and business authority behind a claim

The W3C PROV data model distinguishes entities, activities and responsible agents and describes relationships such as derivation and revision. A readiness review can use that conceptual structure without adopting a particular implementation. Its practical question is whether the team can reconstruct the information and transformations supporting a material output.

For the handover assistant, a drawing identifier alone is insufficient. Capture revision, release state, applicable project, source owner and the effective point of the approval. “Accepted for document submission” may not mean “approved for handover”. The business owner must establish the meaning of the state the assistant is allowed to report; a database field name cannot settle that interpretation.

Original provenance specimen for one proposed checklist reference

Record element	Illustrative content	What it helps establish
Output claim	Drawing D42 is listed as released for the specified handover package	The exact proposition requiring support
Source identity	Project-specific document reference D42, revision D	Which item and version were used
Authority	Named role owns the handover release record; approval event is linked	Why this status is treated as authoritative
Transformation	Approved extraction configuration and index build reference	Which derived representation supplied the passage
Access decision	Requesting identity, applicable project membership and decision time	Who was allowed to receive this material under the tested policy
Review outcome	Human reviewer confirms, corrects or holds the checklist reference	How the proposal becomes an accountable business record

A provenance record supports examination; it does not prove that the source statement is true. An incorrect approval field can be traced perfectly. A cryptographic hash can help identify a particular artefact without establishing its business authority. Keep content correctness, source authority and chain integrity as separate questions in the evaluation.

Do not require one system to carry every detail in a user-visible response. A useful answer can show a concise permitted reference, while a protected evidence record preserves the deeper chain for authorised review. Ensure that the evidence record itself does not become an alternate disclosure route for restricted titles, passages or identities.

Examine the time gap between permission and disclosure

In an illustrative sequence, a contractor is authorised at 09:00, loses project access at 09:02, and is denied by the source repository at 09:03. At 09:04, the assistant still holds the earlier membership result. The readiness question is whether the intended policy permits that state and, if it does not, whether the architecture prevents disclosure through the stale route.

Agree the effective event and the expected propagation behaviour. Different systems can learn about a change at different times, and timestamps may reflect different clocks or event meanings. Record which event establishes revocation, how downstream services receive it and how the application behaves when it cannot establish a valid current decision. Do not invent a universal statutory synchronisation interval.

Inspect every reusable object that can carry a previous grant: cached search results, conversation context, downloaded references, generated summaries and exported checklists. Some previously distributed material may require a distinct handling process rather than a technical promise of recall. The proposed operating model must distinguish preventing new disclosure from managing information that was already legitimately delivered.

A separate permission check followed later by an action can leave a race between the two operations. For action-taking systems, examine how the target enforces the relevant current conditions at execution, using the integration and action readiness guide. A read-only retrieval test cannot establish that a later write or approval transition is authorised and correctly committed.

Run a bounded revocation and provenance rehearsal

Use authorised synthetic documents and test identities in an appropriate environment. The following sequence is a proposed assessment procedure. Its aim is to identify observable prerequisites and missing evidence before a pilot, without probing real projects or exposing confidential drawings.

1. Define the policy and expected states. Record the allowed project, document release states, requesting identities and effective membership changes. Have the business and security owners agree the expected outcomes before running tests. Include permitted retrieval, prohibited retrieval and an inability to establish authority.
2. Create identifiable test artefacts. Use synthetic versions with unique, non-sensitive markers and a documented source history. Preserve the input records so reviewers can tell whether a response came from the released version, an obsolete version, a draft or unrelated material. Avoid markers that depend on an actual person's data.
3. Observe an authorised baseline. Run the allowed request and capture the source, derived representation, access decision and response reference. Verify that the answer supports the defined handover question. This establishes a baseline for the selected conditions, not proof that every permitted request will work.
4. Change one relevant condition. Revoke the test membership or supersede a source version using the approved test procedure. Record the effective event and observation times. Check the intended downstream update and the application response before, during and after the change, within the agreed scope.
5. Inspect the complete observed path. Examine retrieval results, model inputs where observable, outputs, permitted logs and export behaviour. Separate a blocked display from proof that restricted content was excluded earlier. Record components that could not be inspected and the alternative evidence required.
6. Assign a precise readiness outcome. Identify the source family and configuration that can proceed, the demonstrated gap and its responsible owner. Define the corrective action and repeatable acceptance check. Preserve evidence of the original result; do not replace it with a later successful demonstration.

Make permission metadata a maintained dependency

Access attributes need owners and update processes just as business fields do. Identify who maintains project membership, release status, external-party roles and permission mappings. If a nightly export omits membership removals, refreshing the content index more frequently may not solve the underlying gap. Locate the authoritative change feed before proposing a faster schedule.

Assess schema changes and incomplete mappings. A new repository can use different role names or document states, and a connector may omit an attribute that the old source supplied. Define how the pipeline rejects or holds material whose rights cannot be mapped reliably. Missing metadata should not be silently interpreted as public access.

For RAG readiness, record how chunks retain the link to source restrictions and version identity. For broader catalogue and lineage readiness, connect those records to transformations and owners across the estate. A successful catalogue entry is not evidence that the application actually consults the relevant access rule; the runtime boundary still needs examination.

Test the effective decision across organisational boundaries

A joint venture may receive users from two identity providers while the repository records a project role separately. Inspect the complete mapping from authenticated account to organisation, current project membership and permitted document operation. Matching an email domain is insufficient when a contractor changes employer or one person serves several projects. Establish which owner approves those relationships and how their changes reach the application.

Include an identity-collision case in the assessment: two accounts have similar display names, but only one holds the relevant project assignment. The answer must be attributable to the actual requester and current authorised context. A visually familiar name in a screenshot is weak evidence when immutable identity references, membership events or the evaluated policy are missing.

Also define a route for a legitimate user who is denied access. A controlled request to the project owner can repair an incorrect assignment without allowing the model to infer permission from conversation. Capture the reason for the correction and repeat the affected test. The support process is part of readiness because unresolved false denials can encourage users to distribute uncontrolled copies.

Protect the evidence and preserve useful review access

Logs and provenance records can expose document names, user roles, source excerpts or commercially sensitive project relationships. Apply the relevant data classification and handling decisions to those artefacts. Decide which evidence requires raw content, which can use controlled references and which should be visible only to a designated review role.

Keep sufficient evidence to diagnose a denied or incorrect result. Removing every trace can leave the operating team unable to distinguish a policy decision from a stale index or a broken identity mapping. Design minimal, purposeful evidence with appropriate access and retention rather than choosing between unrestricted logging and no usable history.

Plan reviewer access before collecting material. An external assessor may need a controlled demonstration or masked records instead of broad repository credentials. Document the limitation of that access and the conclusion it can support. The readiness engagement itself must respect the source permissions that the proposed system is expected to preserve.

Turn access gaps into specific delivery conditions

Write remediation at the failing boundary. “Improve security” does not identify whether the problem is missing project attributes, an outdated membership cache, a broad export role or an untraceable source revision. A data-remediation backlog item should name the affected operation, owner, dependency and acceptance evidence, allowing the sponsor to see what change would enable the next step.

Some gaps can support a narrower interim scope. The organisation might permit retrieval from a verified released-document set for a small authorised group while withholding mixed-permission repositories. The decision must specify that boundary and its operating owner. Do not generalise the limited result into readiness for all project documents or future action-taking features.

Bring the source-permission map, identity flow, version records and available test evidence into an enterprise data and AI readiness assessment. Link unresolved conditions to the enterprise checklist and agree the pilot decision they affect. A readiness assessment discussion about permissions and provenance can then establish what to examine, which owners must participate and what evidence will make the proposed use defensible.