Connectors, Retrieval and the Permission Inheritance Problem

Every enterprise GenAI platform now connects to company data, and every vendor says the same reassuring thing about it: the assistant respects your existing permissions. That statement is usually true. It is also the beginning of the assessment rather than the end of it, because inheriting a permission model means inheriting whatever is wrong with it — at the speed of natural language, across the whole estate, for everyone at once.

Two questions, not one. Whether a person is entitled to reach content is an access question, and the platform may answer it faithfully. Whether that content may be used for this purpose, by this system, in this way is a separate authorisation with a separate owner. Entitlement is not authorisation, and only the first of the two is a permission.

Assess the platform once, then assess connectors by what they reach — and treat the identity a connector runs on as the field that decides everything else. The governance question is the same across Microsoft 365 Copilot, Gemini for Google Workspace, ChatGPT Enterprise, Claude Enterprise, Glean and anything built on Copilot Studio or MCP, because it is not really a question about the AI. It is a question about whether your identity and content-permission model was ever good enough to be read out loud. Enterprises reach one of two failure modes here. Either the platform is approved once and every subsequent connector rides in on that approval, or every connector triggers a full assessment and the programme stalls arguing about the calendar integration. Neither is proportionate. What follows is the method we use instead: a platform-level approval that covers the durable questions, a short trigger list that decides which integrations get assessed individually, the five identity models a connector can run on and what each does to your logs, the retrieval-specific risks that permission inheritance does not touch at all, custom connectors and direct API deployments as a separate case, and what to re-review when any of it changes.

None of this makes permission inheritance a bad design. It is the right design, and a platform that did not respect existing permissions would be unusable in an enterprise. The point is narrower and more useful: inheritance transfers a property you already had, so the assessment has to be of the thing being inherited. Where that model is known to be weak — and in most estates of any age it is — permission hygiene is the remediation programme that has to run alongside the deployment rather than after the first incident.

The purpose axis has its own anchors, and naming them shortens the argument with a privacy or legal reviewer. In the trust services criteria, the privacy criterion limiting use of personal information to the purposes identified in the entity’s objectives (P4.1) is the direct hook, with the confidentiality criterion on identifying and maintaining confidential information (C1.1) close behind. Both are in scope only if you selected the Privacy and Confidentiality categories — the majority of SOC 2 reports are Security-only, in which case the purpose question has no criterion to land on and has to be governed outside the report. Deciding that is part of choosing your trust services criteria. Under ISO/IEC 42001:2023 the equivalent work is the AI system impact assessment and the Annex A control objectives covering data for AI systems (A.7) and third-party and customer relationships (A.10). Whether a use is authorised is a governance decision recorded by a named owner, and it is exactly the decision an approved-use-case register exists to hold.

The triggers that move a connector from platform tier to individual assessment are worth stating explicitly in your policy, because a written trigger list is what stops both failure modes. Ours are as follows. The connector reaches special-category or regulated personal data. It reaches content held under customer confidentiality obligations. It reaches a security or privileged system such as the identity provider, the secrets store or the security ticket queue. It can write, act or spend rather than only read. It runs on an application identity rather than a delegated one. The permission model of the source is not currently described. It creates an index rather than querying live. Or it moves content across a border that your agreements constrain. One trigger is enough.

In practice a platform-tier approval is a short record — half a page and a link to the contract. An individual assessment for a document tenant or a warehouse is a day of real work, most of it spent reading permission reports rather than writing the document. The whole point of tiering is to spend that day where it changes a decision. Both records belong in the AI system inventory, with the connector list as an attribute of the system rather than a separate spreadsheet.

This is the artefact everything else on this page refers back to — the thing the change triggers test against, the thing an examiner samples, and the thing a buyer’s security team is really asking to see when they ask how you govern AI access. Fifteen fields, none of them optional, and two of them load-bearing above the rest.

The identity-model field and the enablement-date field are the two that the change-trigger list later in this page tests against. Every other field makes the record useful. Those two make it testable, and a record missing either of them cannot support the control it was written to evidence.

Permissions evaluated at index time rather than query time. If access-control identifiers were copied into the index when the chunk was written, the index enforces the permissions of that moment. Every change since is invisible until the item is re-indexed. Ask which of the two your platform does. If the honest answer is a mixture — live for some sources, snapshot for others — that mixture is what you have to document, and the sources on snapshots are the ones that need shorter refresh intervals.

Filtering after retrieval rather than before. Pre-filtering restricts the candidate set to what the user may see. Post-filtering retrieves broadly and removes what they may not, which means the restricted text entered the pipeline and the protection depends on the filter being correct on every path out of it — the answer itself, the citation list, document titles and snippets, related-content suggestions, and follow-up questions in the same conversation. Post-filtering is not automatically wrong, but it makes the filter a security control and the paths a test plan.

Treating the vector store as unreadable. Embeddings are derived from the source text and are not an obfuscation mechanism. Published research on embedding inversion shows meaningful text can be recovered from them. The practical rule is simple and worth stating in the design record: the index inherits the classification of the highest-classified content it contains, and it gets the same encryption, access control, logging, backup and retention treatment as the source. A vector database standing outside your data-classification scheme because it holds numbers is the gap this rule closes.

Tenancy as a filter rather than a boundary. In a multi-tenant product, whether tenant separation is a separate index, collection or namespace or a metadata field applied in the query changes the failure mode entirely. A boundary fails closed. A filter fails open, and it only has to be omitted on one code path — a batch re-ranking job, an internal support tool, a migration script — to produce cross-tenant retrieval. Decide it deliberately, write it down, and prove it with an automated negative test rather than a design statement.

One more consequence deserves its own sentence, because it is the one privacy teams discover last: retrieval also enlarges the prompt-injection surface. Content pulled from a wiki page, a ticket or an email is untrusted input that reaches the model with your instructions, and where the assistant can also act, a maliciously crafted document becomes a way to steer it. Prompt Injection is LLM01 in the 2026 edition of the OWASP Top 10 for LLM Applications — first on the list in both editions, and the item retrieval makes reachable from outside your organisation. Retrieval and tool use are usually governed by different teams. The risk sits precisely between them.

Read the 9 March row against the 2 February row. The negative test in the pilot was valid, well designed and correctly filed — and it tested a configuration that no longer existed five weeks later. The assessment was not wrong. It expired, silently, in a change that was visible in the platform audit log the whole time and that nobody had a reason to read.

Note also what made the answer possible on 25 March. The retrieval log recorded which sources were returned to which user, not merely which prompts were typed, and it was preserved before the index was rebuilt. Had containment run in the other order — rebuild first, investigate after — the company would have been left telling four thousand employees and one regulator that it could not determine who had seen the material. The blast-radius question is answerable only from a log that records retrievals, and it is the reason that log’s retention is a governance decision rather than an engineering preference.

There is a reporting consequence worth settling early. A retrieval pipeline you built is part of your system, so it sits inside your system boundary and its controls are yours to describe and to have tested. The model provider is a vendor managed under CC9.2, and depending on how you describe the system it may be a subservice organization, which brings carve-out or inclusive treatment and complementary controls into play. Decide that before the description is drafted rather than during fieldwork, and note that a SOC 2 report from the provider covers the provider’s controls — it says nothing about whether your retrieval layer filters correctly.

The same distinction governs what you can tell your own buyers. Vendor assurance about the model platform and assurance about your application are separate claims, and relying on a vendor’s report for the second is the substitution a careful reviewer will catch.

A population is only half the answer. The other half is how much of it gets tested. The figures below are market and audit practice under AICPA sampling guidance rather than a requirement of any standard — the service auditor sets the sample, and a smaller population or a history of deviations moves it. The general sample sizes used across a SOC 2 examination apply here unchanged. What is unusual about AI connector controls is how small the populations are.

The populations here are small, which makes them unforgiving. A twelve-month period at a company with nine connectors gives a population of nine approvals, twelve monthly reconciliations and perhaps three change events — small enough that the auditor tests all of them, so a single missing approval is a known deviation rather than an estimate, and there is no sampling risk to hide behind. Two adjacent populations are also frequently zero — AI incidents, and erasure requests touching AI copies — and a control with no occurrences cannot be tested for operating effectiveness at all. Prefer designs that operate anyway: the monthly reconciliation and the periodic negative test produce evidence every cycle whether or not anything went wrong, which is precisely why they are the two controls worth building first.

The vocabulary is the same as everywhere else in an examination. Anything you export is information produced by the entity, so the query, the filter, the date range and the record count have to be visible on the face of it — the rules for evidence do not soften because the subject is new. And retention is the detail that turns a tidy programme into a scramble: AI platform audit and retrieval logs frequently retain for a period set by your licence tier, which may be shorter than your observation period. List every log you cite in a control description, write its retention beside it, and export monthly to your own storage wherever it is shorter than the period plus ninety days.

On roles: Tranquility Cybersecurity designs and implements these controls, prepares the evidence and coordinates the examination. The report is issued by a licensed CPA firm and an ISO/IEC 42001 certificate by an accredited certification body — TCSA never certifies, attests, audits or signs, and a firm that designed your controls cannot then examine them.

Related reading: Copilot oversharing and permission hygiene, the AI system inventory, use-case approval versus vendor approval, MCP server governance, risk assessment versus impact assessment, integrating ISO 42001 with ISO 27001, and the ISO 42001 hub.