Enterprise search must preserve document access beyond sign-in. Assess source permissions, synchronisation delays, generated answers and administrative responsibilities as one information workflow.
An employee who can sign into an enterprise AI service should not automatically be able to retrieve every document that service has indexed. Defence suppliers often separate customer programmes, commercial records and engineering responsibilities within the same organisation. The purchasing question is whether the search product preserves those distinctions throughout the information workflow.
That question extends beyond the login screen. A connector collects records, an index stores a searchable representation, an answer service assembles passages and an employee may save or share the result. Each stage has an access decision or a handling responsibility. A credible supplier can explain those boundaries without presenting a general security label as proof of the entire chain.
NIST SP 800-207, published in August 2020, distinguishes authentication from authorisation and rejects implicit trust based only on network location or asset ownership. Its zero trust architecture discussion focuses on access to resources and enterprise workflows. It is a conceptual reference, not a certification of a particular AI application or a universal configuration prescription.
For an enterprise search buyer, the distinction is straightforward. The product may know who an employee is while still needing to determine which documents that person may use. The account that collects documents can also have broader access than the employee making a query. A successful connector login demonstrates collection capability, not appropriate access for every subsequent reader.
Map the identities used by the application, the collection service and the person asking the question. Ask which identity governs each action and who maintains its permissions. This helps expose implementation work that might otherwise appear only after a pilot has indexed material from several business units.
Microsoft's document-level access overview, updated 12 August 2026, distinguishes application-supplied security filters from native identity-based approaches. It describes several native permission and label integrations as preview features. Query decisions use permission metadata synchronised into the index, and changes in the source can lag before appearing in results. The documentation is specific to its supported sources and API capabilities; it does not establish equivalent behaviour for every enterprise connector.
A procurement comparison should therefore name the actual source systems and permission patterns in scope. Broad statements such as support for a document platform leave unanswered whether the product handles the customer's groups, inherited permissions, external collaborators and separately restricted records. Those details influence whether an advertised integration is ready for the intended corpus.
Preview status also belongs in the commercial discussion. It can affect the customer's willingness to depend on a feature, the supplier's support commitment and the amount of validation required. A buyer can make a deliberate decision to pilot a preview capability, but the proposal should preserve that status rather than silently treating every documented function as a mature production commitment.
A static example with two users and two documents proves little about the lifetime of the service. The organisation will move staff, change project memberships, revise document access and close external accounts. The evaluation needs representative changes in an authorised demonstration environment, with agreed expected outcomes and observation times.
For a hypothetical engineering archive, an employee transfers from one customer programme to another. The business needs to know when their available search results reflect that change and how administrators can tell whether the update completed. The product's ordinary synchronisation interval may differ from the time needed for a particular inherited permission change.
Ask the supplier to document the applicable update mechanism and its limitations. Establish who notices an unsuccessful refresh and who can resolve it. If different source systems behave differently, retain that distinction in the acceptance record. A single statement that permissions are synchronised is insufficient to price the operational responsibility.
The relevant result is observable consistency with the agreed access model. It includes removal as well as addition of access. A feature that quickly discovers newly available documents but requires manual work to withdraw them may still have a usable scope, provided that scope and staffing requirement are explicit.
The customer should understand which authorised passages are available to the answer service and how the resulting response is stored. A generated summary can combine facts from several records, each with its own audience. The permission of the original questioner does not by itself determine who may read the saved summary later.
Examine the ordinary product workflow for conversation history, shared workspaces, exports and downloaded reports. Establish whether these are separate governed records, transient displays or customer-managed files. The practical issue is ownership of the next access decision. A search supplier cannot credibly promise to enforce permissions inside every destination application without defining an integration that does so.
Source references introduce another boundary. A reader may be authorised to view an answer but unable to open its evidence, or able to open a record whose status has changed since the answer was generated. The guide to citation evaluation explains the evidence-quality implications. Permission and factual support should both survive the intended handover, even though they require different checks.
Record the treatment of stored answers when source access changes. The customer may need a retention decision as well as a retrieval decision. There is no single correct policy for every commercial record; the product must make its actual behaviour understandable enough for the organisation to choose an appropriate workflow.
A supplier's support team may need diagnostic information to investigate a failed connector or a missing result. Agree what information it can see, how the customer approves access and what record remains. Product support is part of the service design, not an exception that should be discovered during the first difficult incident.
The same applies to application administrators. An administrator may manage indexes and integration settings without being the intended reader of every underlying record. Ask the supplier to distinguish administrative functions from content access and to explain any unavoidable combination of the two. That distinction helps the customer assign responsibilities realistically.
Operational records should let authorised staff investigate why a document was included or excluded without requiring unrestricted inspection of unrelated content. The evaluation can use synthetic or otherwise approved material to demonstrate that visibility. The aim is evidence of accountable administration, rather than collecting more sensitive records simply to prove a point.
A first deployment can use a well-managed corpus with a clear owner and a limited set of access patterns. That creates a useful setting for confirming both business value and administrative effort. Expansion to another source should revisit its permission semantics and update process, not merely repeat the original connector installation.
The TKMS and Cohere enterprise AI agreement shows why internal knowledge workflows matter commercially to defence industry. A customer's own access structure remains a separate implementation question. An industry reference can establish relevance while the local evaluation establishes fitness.
For suppliers, a clear permission model can strengthen the sale by making integration costs and operating responsibilities predictable. For buyers, the decisive evidence is a complete account of who may retrieve, retain and share information as the organisation changes. That account connects an attractive search demonstration to a service the business can actually govern.
Microsoft capabilities and preview status reflect the documentation reviewed on 6 September 2026. Broader evaluation questions are BDI analysis, not a claim of product certification.
Suggest a correction