Companion to the AI Sovereignty Risk Assessment Framework · CASE assessment 02f05034-3a0f-4352-9cc3-d2f7bdddec47 # Is There a Hidden AI Supply Chain in Your Vendor? *A plain-language walkthrough for GRC and compliance auditors, no technical background required* **Organization:** ABC **Vendor / dependency assessed:** Open AI **Industry:** Financial Services *Generated by the CASE assessment pipeline on 2026-10-30. Metric values were assigned by retrieval-grounded agents and scored deterministically; they have not been reviewed by a human expert.* ## Before You Start This is not a technical document. It answers one practical question a compliance auditor is increasingly asked: “We use a lot of software. Some of it quietly grew an AI feature. What do we actually need to worry about, and how bad is it?” It walks through one vendor from start to finish using the same seven questions every time. A small italicised note under each section (“Technical cross-reference”) points back to the technical rubric for anyone who wants to trace a rating to the formal scoring model; you can ignore those notes and still get full value. ### The Rating Scale, In Plain English | Rating | Meaning | |---|---| | **RATING: LOW** | Normal and contained. If something went wrong here, you'd find out quickly and fix it without much trouble. | | **RATING: MEDIUM** | Could cause a real problem, and you might not find out right away, worth tracking, not yet an emergency. | | **RATING: HIGH** | Could cause serious damage, a data leak, a regulatory violation, or losing the ability to operate, and by the time you noticed, it might already be too late to undo. | ## The Scenario > ABC uses and houses its own resources while using Open AI to help augment sensitive business needs. ## Walking Through It, Category by Category ### 1. Whose AI brain is this, really? Every AI feature is powered by some underlying model, hosted somewhere, controlled by someone. That someone is very often not the software vendor you actually have a contract with. **Ask the vendor:** - *Whose AI model is actually answering our questions, yours, or one you're renting from someone else?* - *If we stopped paying you tomorrow, could we take this AI capability somewhere else, or does it just disappear?* - *Can the AI's behavior change overnight without you telling us?* **What we found:** ABC runs its own infrastructure and can move its data and workloads elsewhere, but the AI brain itself belongs to OpenAI and is reached as a hosted service over the internet. OpenAI decides, entirely on its own and at any time, when the underlying model changes how it behaves; under the current terms ABC is told only at the moment the change takes effect, with no advance notice, no ability to stay on a tested version, and no window to check the new behaviour first. Because ABC uses these outputs to support sensitive, regulated business decisions, a quiet change in model behaviour would flow straight through to those decisions and ABC would have no reliable way to notice. ABC's protections for its own data — its own hosting, its own encryption keys, its residency terms — do nothing to control which version of the model answers its questions. > **RATING: HIGH**, Assume the AI behind ABC's regulated decisions can change without warning and that ABC would not detect it, so this must be treated as an active control gap rather than a theoretical one. *Technical cross-reference: dimensions 1.3 (Model update / versioning control), 1.1 (Model hosting location / jurisdiction), 1.2 (Model weight custody / control), Org Action Required (UI), Trigger Conditions (AT), Primary Dependency Impact -- Integrity (VI), Silent/Automatic Trigger (AU) in the technical rubric. CASE vector `SOV:1.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:L/SI:H/SA:L/E:P/CR:M/IR:H/AR:H/S:P/AU:Y/R:U/V:C/RE:M/U:Amber`, score 7.9 (High).* ### 2. What are we feeding it? Once an AI feature exists, the next question is simple: what of ours does it actually see? Employee inputs, uploaded reference material, and anything the AI can reach and act on all count. **Ask the vendor:** - *What do our employees actually type into this thing, and does it include customer or confidential information?* - *Did we upload or connect any of our own internal documents for it to search?* - *Can this AI take real actions, look things up, change things, or does it only talk?* **What we found:** ABC deliberately sends sensitive business content to OpenAI as prompts, and that content must leave ABC's environment in readable form for the service to work. A vendor promise not to train on prompts does not stop prompts being logged for abuse detection, kept for troubleshooting, or read by human reviewers when something is flagged, and these practices run continuously as a by-product of ordinary use rather than only in special cases. Anyone already inside OpenAI's chain of suppliers — reviewers, support staff, hosting providers — is in a position to see that material. ABC's encryption keys and data-residency terms protect data sitting in ABC's own systems and offer no protection for prompt content once it is sent. > **RATING: MEDIUM**, Sensitive business content is leaving ABC's control every time the service is used, with real but bounded exposure that depends almost entirely on OpenAI's own retention and review policies. *Technical cross-reference: dimensions 2.1 (Prompts / user inputs), 2.2 (Internal documents ingested for RAG), Access Path (AV), Compulsion Complexity (AC) in the technical rubric. CASE vector `SOV:1.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:H/VA:N/SC:L/SI:L/SA:L/E:P/CR:M/IR:H/AR:H/S:P/AU:Y/R:U/V:C/RE:M/U:Amber`, score 6.1 (Medium).* ### 3. What does it create from our data: and where does THAT go? This is the part almost every vendor review misses entirely. AI systems don't just read your data, they transform it into new things: mathematical fingerprints of your documents, logs of every answer given, records of which answers got a thumbs-down. Those new things get stored somewhere, often by a company you've never heard of and never contracted with directly. **Ask the vendor:** - *Does this turn our documents into some kind of derived file (an “embedding”) so it can search them faster?* - *If so, who stores that derived file, you, or a completely different company?* - *Do you keep a copy of everything the AI said back to us, a log of how we used it, or a record of when we said the answer was wrong?* **What we found:** ABC keeps its embedding and retrieval store — the searchable representation of its own business documents — inside its own environment, protected by its own encryption keys and residency terms, which is a genuinely stronger position than most organisations have. However, ABC has confirmed that OpenAI can still reach into that environment through the managed service, telemetry and support channels, and that anyone in the supplier chain could use that access. Those protections guard against the data being read, but they do not stop a party with that reach from changing what the store returns, and ABC reports it would not detect such a change. Because nearly every AI workload at ABC draws on this one shared store, a single silent alteration would affect all of them, and the stored material is derived from sensitive and personal information, so unauthorised access would be reportable in its own right. > **RATING: MEDIUM**, ABC's own hosting materially reduces the risk of this data being read, but not the risk of it being quietly altered in a way that would spread to every AI workload. *Technical cross-reference: dimensions 3.2 (Vector database / embedding store location and control), 3.1 (Embeddings), 3.5 (Telemetry / usage logs), Position Required (PR) in the technical rubric. CASE vector `SOV:1.0/AV:L/AC:H/AT:N/PR:N/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:L/E:P/CR:M/IR:H/AR:H/S:P/AU:Y/R:U/V:C/RE:M/U:Amber`, score 5.3 (Medium).* ### 4. Who's deciding what the AI sees and does? Between “the model” and “what we see” sits a set of decisions: which document gets pulled up, whether a filter blocks an answer, where an action actually executes. Each of those decisions can be made by yet another company. **Ask the vendor:** - *Who decides which of our documents actually get shown to the AI when it answers a question?* - *Who runs the safety filter that sees every question and answer, and can we see its rules?* - *If the AI takes an action on our behalf, where does that action actually happen, in your systems, ours, or a third location?* **What we found:** ABC operates its own retrieval pipeline — the machinery that decides which internal documents are selected and handed to the model — which is a strong position and means no outside party can rewrite ABC's selection rules. The remaining exposure is at the boundary: every set of selected documents is sent to OpenAI's hosted service, and OpenAI-supplied components in that path can change behaviour without ABC's agreement or prior knowledge. Because this pipeline is the single gate through which nearly all grounded AI workloads pass, a change in what it effectively surfaces would reach every one of them, and ABC reports it would not detect altered results. Published research and incident reports confirm that corrupting what a retrieval system feeds a model is a proven technique, not a hypothetical one. > **RATING: MEDIUM**, This is the best-controlled layer in ABC's AI estate, but it is also a single chokepoint, so the residual vendor influence at its edge deserves monitoring rather than dismissal. *Technical cross-reference: dimensions 4.1 (Retrieval pipeline (RAG) ownership), 4.4 (Guardrail / safety filter layer), Trigger Conditions (AT), Downstream Blast-Radius Impact -- Integrity (SI), Integrity Criticality (org context) (IR) in the technical rubric. CASE vector `SOV:1.0/AV:L/AC:H/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N/SC:L/SI:H/SA:L/E:P/CR:M/IR:H/AR:H/S:N/AU:Y/R:A/V:C/RE:M/U:Amber`, score 4.5 (Medium).* ### 5. Which humans are actually looking at our stuff? Not every risk is a computer. Somewhere in most AI products, an actual person, often a contractor, often outsourced, reads flagged conversations or debugs a problem using our data. That's a direct human set of eyes, independent of every technical safeguard above. **Ask the vendor:** - *Does a real person at your company, or a contractor of yours, ever read our conversations or our data?* - *If a conversation gets flagged, does it go somewhere else to be reviewed or labeled?* - *When your support engineers debug a problem for us, what can they see?* **What we found:** ABC's own answers confirm a managed-service, telemetry and support channel that reaches into ABC's environment, which is the route OpenAI's support and engineering staff would use to read logs and traces when investigating an issue. This access rests on a general support clause in the vendor terms, is available at the vendor's discretion rather than only during a declared incident, and extends to support organisations and contractors in OpenAI's supplier chain, not just OpenAI's own employees. Nothing in the current arrangement requires ABC to approve a specific access request before it happens. The practical exposure is partial, because debugging material is usually fragments and samples rather than whole documents — but that assumption has not been verified, and if traces contain full prompt and response text for ABC's sensitive workloads the exposure would be far greater. > **RATING: MEDIUM**, Real people outside ABC can look at operational records from ABC's sensitive AI workloads under a standard support clause, and ABC currently has no approval gate or verified limit on what they see. *Technical cross-reference: dimensions 5.3 (Support / debugging access), 5.1 (Human review processes), Position Required (PR), Compulsion Complexity (AC) in the technical rubric. CASE vector `SOV:1.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:P/CR:M/IR:H/AR:H/S:P/AU:N/R:U/V:C/RE:M/U:Amber`, score 4.0 (Medium).* ### 6. Who's holding the steering wheel? Somewhere, someone configures this thing: turns features on and off, sets filters, manages who has access, holds the keys. That control panel is itself a dependency, and it doesn't always sit where you'd expect. **Ask the vendor:** - *Where does the screen we'd use to configure or turn off this AI feature actually live?* - *Is our employee login system, or our credentials to other systems, now tied into a system this vendor controls?* - *Can settings change on us without anyone telling us?* **What we found:** The OpenAI administration console — where project settings, API keys, access, usage and policy defaults are managed — sits entirely on the vendor side, is reached over the public internet, and may be operated from a different country than the inference service itself. Nearly all of ABC's AI workloads depend on this single administrative surface, so a change, outage or misuse there would affect everything at once, and OpenAI (or parties in its supplier chain) can change settings and defaults without ABC's agreement or prior notice. This is not a theoretical concern: there are documented, publicly reported cases of attackers getting into comparable companies' accounts for hosted AI services, altering what the service was permitted to do, bypassing safeguards, and checking whether logging was switched on so their activity would stay invisible to the customer. ABC reports it would not detect altered outputs flowing from such a change. > **RATING: HIGH**, This is ABC's single most concentrated point of administrative failure, and comparable organisations have already been hit through exactly this surface, so hardening it is urgent. *Technical cross-reference: dimensions 6.1 (Centralized control plane / admin console), 6.4 (Configuration and policy management), 6.3 (API gateway / rate limiting infrastructure), Access Path (AV), Blast-Radius Concentration (V) in the technical rubric. CASE vector `SOV:1.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/E:A/CR:M/IR:H/AR:H/S:P/AU:Y/R:U/V:C/RE:M/U:Amber`, score 8.8 (High).* ### 7. How many companies are really in this chain: and did we agree to it? Add it all up. This is the question that actually matters most, and it's the one almost no vendor security review asks directly: how many companies now sit between us and our own data, and which of those did we ever actually agree to? **Ask the vendor:** - *List every company standing between us and the raw computer running this AI. How long is that list, really?* - *Did we ever affirmatively choose to adopt AI here, or did it just arrive?* **What we found:** ABC's contractual protections — encryption keys, residency carve-outs, access restrictions — are enforceable against OpenAI, but they do not reach the other companies OpenAI relies on beneath it. ABC has confirmed it has no right to be told in advance when that chain of suppliers changes and no ability to object: subprocessor changes are disclosed only when they take effect. At the same time, ABC's answers show that any party already in that chain has enough standing to act on ABC's data, so the set of organisations that can touch ABC's material is wider than the one ABC has negotiated with. There are documented real-world incidents in which a supplier inside an AI chain quietly substituted a component that kept appearing to work normally while sending customer data elsewhere, and under data protection law ABC as the controller is required to be notified of and able to object to subprocessor changes — which the current terms prevent. > **RATING: HIGH**, ABC does not know, and cannot approve, every company handling its sensitive data through OpenAI, which is both a live operational risk and a standing regulatory defect. *Technical cross-reference: dimensions 7.1 (Downstream subprocessors), 7.3 (Infrastructure providers beneath the AI vendor), Compulsion Complexity (AC), Trigger Conditions (AT), Position Required (PR) in the technical rubric. CASE vector `SOV:1.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:H/SA:L/E:A/CR:M/IR:H/AR:H/S:P/AU:Y/R:U/V:C/RE:M/U:Amber`, score 8.2 (High).* ## The Rollup Put side by side, here is what one pass through all seven categories produced for Open AI: | Category | Rating | Carried by | |---|---|---| | 1. Whose AI brain is this, really? | **HIGH** ◆ | 1.3 Model update / versioning control | | 2. What are we feeding it? | **MEDIUM** | 2.1 Prompts / user inputs | | 3. What does it create from our data: and where does THAT go? | **MEDIUM** | 3.2 Vector database / embedding store location and control | | 4. Who's deciding what the AI sees and does? | **MEDIUM** | 4.1 Retrieval pipeline (RAG) ownership | | 5. Which humans are actually looking at our stuff? | **MEDIUM** | 5.3 Support / debugging access | | 6. Who's holding the steering wheel? | **HIGH** | 6.1 Centralized control plane / admin console | | 7. How many companies are really in this chain: and did we agree to it? | **HIGH** | 7.1 Downstream subprocessors | ◆ Headline finding: category 1, dimension 1.3 (Model update / versioning control), CASE score 7.9 High [manual exit (R:U); concentrated (V:C); regulatory consequence (S:P); silent/automatic trigger (AU:Y); concurrent vendor notice (U:Amber)]. ## What ABC Should Actually Do Next - ABC should immediately seek a contractual change with OpenAI for advance notice of behaviour-affecting model changes plus the ability to pin a tested model version, and in the interim record the exact model version used for every regulated decision so changes can be reconstructed after the fact. - ABC should harden and tightly restrict the OpenAI administration console now — enforce single sign-on and multi-factor authentication, rotate and inventory all API keys, apply least-privilege roles, remove unused projects and keys, and confirm that usage and prompt logging cannot be silently switched off — since comparable organisations have already been compromised through this exact surface. - ABC should establish its own ongoing validation of model behaviour, running a fixed set of reference prompts and expected outcomes on a regular schedule so that a silent change in OpenAI's model is detected by ABC rather than discovered through a bad business decision. - ABC should demand from OpenAI, in writing, the current list of downstream suppliers, a contractual right to prior notice of any addition or substitution, and a right to object — and should treat the absence of that right as a reportable data protection gap until it is closed. - ABC should obtain and verify OpenAI's support-access terms, specifically whether support staff can see full prompt and response text, who those staff are, where they are located, and whether per-request approval and access logging can be enabled for ABC's tenancy. - ABC should establish and maintain a complete inventory of its AI components, data sources and their provenance, including which workloads depend on the shared embedding store, so the blast radius of any single change is known in advance. - ABC should tighten write access to its own embedding and retrieval store — restricting who and what can change the index, requiring integrity checks on indexed content, and alerting on unexpected changes — so that vendor-side reach into its environment cannot silently alter what the model is fed. - ABC should introduce verification of any model, package or artefact entering its AI pipeline through signature and checksum checks, and block anything unsigned or unverified from running. - ABC should document, for its regulators and its own model risk governance, that behaviour-affecting changes to a model supporting sensitive business decisions are currently outside ABC's control, and record the compensating controls being put in place. ## Running This Yourself The seven questions above don't change from vendor to vendor, only the answers do. Any time your organization is told (or, more often, not told) that a piece of already-approved software just grew an AI feature, work through the same seven categories, in the same order, and rate what you find on the same three-colour scale. The scenario in this document exists to show you what that looks like done once, start to finish, the method itself travels.