CASE: AI sovereignty risk console

Ratings by hazard class

The headline is the worst class, as CVSS reports the worst finding, not a sum

Class	Carried by	Score	Rating	Load-bearing metrics
1 Whose AI brain is this, really? ◆	1.3 Model update / versioning control	7.9	HIGH	AVACATPRUIVISISAUV
2 What are we feeding it?	2.1 Prompts / user inputs	6.1	MEDIUM	AVACATPRVISAUV
3 What does it create from our data: and where does THAT go?	3.2 Vector database / embedding store location and control	5.3	MEDIUM	ATPRVISISAUV
4 Who's deciding what the AI sees and does?	4.1 Retrieval pipeline (RAG) ownership	4.5	MEDIUM	ATSIAUV
5 Which humans are actually looking at our stuff?	5.3 Support / debugging access	4.0	MEDIUM	ACATPRSV
6 Who's holding the steering wheel?	6.1 Centralized control plane / admin console	8.8	HIGH	AVACATPRUIVISIESAUV
7 How many companies are really in this chain: and did we agree to it?	7.1 Downstream subprocessors	8.2	HIGH	ACATPRUISIESAUV

Findings

What we found per class, in the auditor's language; open the evidence to see each metric's rationale

1 Whose AI brain is this, really?Headline

1.3 Model update / versioning control · also 1.1, 1.2

HIGH7.9

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.

Evidence: vector, score and 21 metric rationales

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)

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?

Metric	Value	Prior	Source	Rationale
AV Access Path	N	L	agent · override	Override L → N. The questionnaire's 'own tenancy, vendor-reachable' answer describes ABC's self-hosted infrastructure, but the dependency scoped by dimension 1.3 is the OpenAI model served as a hosted API: the model weights and serving stack sit entirely on vendor infrastructure and are reached vendor-direct over the network with no intermediary. The rubric's own framing of 1.3 is that the vendor 'silently swaps the model version behind an API endpoint' — i.e. the control point is the vendor-side network endpoint, not anything resident in ABC's environment. Nothing about ABC housing its own resources places the model's version control inside a customer-managed boundary, so L (resident in customer-managed environment) is not defensible for this dimension.
AC Compulsion Complexity	L	H	agent · override	Override H → L. The barriers ABC reports (customer-managed encryption keys, data-residency carve-outs, contractual access restrictions) are confidentiality/location controls; none of them constrain which model version the vendor serves behind the API. A model-version change is routine vendor practice authorised by standard ToS/service-terms language — the vendor overcomes nothing to exercise it. Consistent with the rubric's note that an organisation 'can pass every other sovereignty check and still lose control the moment the vendor silently swaps the model version behind an API endpoint', the keys/residency barriers that justify H elsewhere are irrelevant on the integrity-of-behaviour axis.
AT Trigger Conditions	N	N	agent	Confirm N. The questionnaire states the control is a standing right exercisable at the vendor's discretion at any time, and the classifier notes the event could hit all customers simultaneously with no case-by-case decision. Model refreshes, deprecations and silent routing changes require no sanctions designation, litigation hold or incident to trigger them. AT is one of the two exploitability metrics the rubric designates as primary for 1.3, and 'None' is the value that expresses unconditional vendor discretion.
PR Position Required	N	N	agent	Confirm N. No elevated position or compromise of ABC's administrative credentials is needed: behaviour-affecting changes can originate anywhere in the serving chain the vendor already operates or subcontracts (inference hosts, routing layers, safety/moderation filters), all of which are 'already in the subprocessor chain'. A case could be made for L (only the primary contracted vendor decides the published model version), so confidence is moderate; the rubric does not list PR among the primary exploitability metrics for 1.3, so this metric is not load-bearing for the finding.
UI Org Action Required	N	P	agent · override	Override P → N. This is the metric that carries the finding for 1.3, and the rubric names the exact fact pattern under 'None — vendor/subprocessor can act unilaterally (silent model swap...)'. The questionnaire confirms behaviour 'can be changed silently and materially' and that changes are only 'disclosed at the time the change takes effect', so ABC neither opts in nor accepts an update; the vendor acts alone and ABC learns of it concurrently or after the fact. 'Passive' would understate this: ordinary use is how the altered behaviour reaches ABC's downstream systems, but it is not a precondition the vendor needs — the swap occurs regardless of ABC's activity, and every downstream consumer then inherits an un-notified behaviour change (the rubric's textbook Subsequent Integrity case).
VC Primary Dependency Impact -- Confidentiality	L	L	agent	CONFIRMED at Low. The rubric assigns dimension 1.3 (Model update / versioning control) a primary impact axis of VI only -- a silent version swap is not in itself a data-exfiltration event, so VC is not the carrying axis here (sovereignty_cvss_rubric_1.json, dimension 1.3). However, Low rather than None is correct because ABC sends sensitive business content to a vendor-hosted OpenAI endpoint under a managed arrangement the vendor can still reach (telemetry/support path), and an un-notified model/version change can also change data-handling, logging or retention behaviour behind the same endpoint. The questionnaire's own characterisation of the loss at this dependency -- 'Partial: limited or indirect exposure (metadata, fragments, aggregates)' -- matches the rubric's L definition ('partial or limited loss on this axis'), and real barriers exist (customer-managed keys, residency carve-outs, contractual access restrictions), which keeps this short of total loss (H).
VI Primary Dependency Impact -- Integrity	H	H	agent	CONFIRMED at High, and this is the axis that carries the category. The rubric names VI as the sole primary impact axis for 1.3 and states that 'every downstream consumer of the model inherits an un-notified behavior change', with notice posture values running from 'vendor never discloses before the change takes effect' (Red) to contractually guaranteed advance notice (Clear) (sovereignty_cvss_rubric_1.json). ABC's answers describe the worst case at the dependency itself: 'Full: behaviour can be changed silently and materially', the right is exercisable 'at its discretion, at any time (standing right under the contract)', notification is only 'disclosed at the time the change takes effect', and 'ordinary use of the service is enough to trigger it'. That is total loss of control over the integrity/behavioural baseline of the model ABC relies on -- there is no version pinning, pre-change evaluation window, or approval gate -- so H ('total or near-total loss on this axis') rather than L. Corpus evidence that behavioural tampering in an LLM can be effectively undetectable to consumers (ATLAS AML.CS0019 PoisonGPT: poisoned model showed only a 0.1% benchmark delta, i.e. 'its behavior can be difficult to detect') supports the judgement that ABC could not reliably detect a behaviour-affecting swap by observation alone.
VA Primary Dependency Impact -- Availability	N	N	agent	CONFIRMED at None. A version/behaviour change is not a withdrawal of capability: the questionnaire states that at this dependency 'None: we could keep operating this component', and that the capability is fully portable ('exported weights, portable data, standard interfaces'), so the endpoint remains available after an update. The rubric lists VA as a primary axis for 1.2 (weight custody) but not for 1.3, consistent with availability not being the loss mode of a silent model update. The reported degradation of 'some downstream workloads' is an effect beyond this dependency and belongs to the subsequent-impact (SA) group, not to VA, since the vulnerable-system group is defined as loss 'AT the dependency named by the taxonomy node itself'.
SC Downstream Blast-Radius Impact -- Confidentiality	L	L	agent	Confirmed. A silent model-version swap is primarily an integrity event, not a disclosure event, so the downstream confidentiality axis is not the dominant one for dimension 1.3 (the rubric lists only VI as the primary impact axis for 1.3 and reserves SC-dominant findings for dimensions like 3.1 Embeddings and 2.1 Prompts). However, it is not None: ABC's own answers state that beyond the dependency confidentiality loss is 'Partial', the OpenAI dependency sits behind a shared control plane/gateway/embedding store used by 'many or all' AI workloads, and the vendor can reach ABC's tenancy via managed-service/telemetry/support paths. A behaviour-affecting update can change what the model emits into downstream logs, caches and derivative stores (metadata, fragments, aggregates), giving limited/indirect downstream exposure. Customer-managed keys, residency carve-outs and contractual access restrictions are real barriers that keep this from being a total loss. Hence L, not H or N.
SI Downstream Blast-Radius Impact -- Integrity	H	H	agent	Confirmed, and this is the finding that carries the category. The rubric's entry for dimension 1.3 states that 'every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact', with subsequent_impact_relevant = true. ABC's answers match that pattern exactly: behaviour at the dependency 'can be changed silently and materially', downstream 'systems act on altered outputs without detection', the vendor holds a standing contractual right to change the model at its discretion, notification is only 'at the time the change takes effect' (no advance notice, so no validation window), ordinary use of the service is enough to trigger it, many or all AI workloads depend on the component, and a loss of control here on its own would trigger a reportable regulatory violation. Undetected alteration of outputs that drive regulated/automated decisions across all dependent workloads is a total loss of integrity assurance downstream, so H.
SA Downstream Blast-Radius Impact -- Availability	L	L	agent	Confirmed at L rather than raised to H or S. At the dependency itself ABC reports no availability loss ('we could keep operating this component') and full portability (exported weights, portable data, standard interfaces), so a version change does not withdraw the capability. Downstream, though, ABC reports that 'some downstream workloads degrade' -- prompt chains, evaluations and guardrails tuned to the prior model version can break or be taken offline pending revalidation, which is partial, not total, availability loss. S (Safety) is not selected: the scenario describes augmentation of sensitive business processes and regulated decisioning, and ABC answered that it could not identify anyone being physically harmed, so there is no evidence of a safety-relevant failure mode. The rubric reserves SA-dominant findings for dimensions such as 6.3 (gateway outage takes down access), which is not the mechanism here.
E Precedent Maturity	P	P	agent	CONFIRMED at P (Proof-of-Concept). The rubric defines E:P as 'demonstrated in research/incident reports, not confirmed against this org's own stack' and E:A as 'documented real-world cases of this control being exercised against comparable orgs' (sovereignty_cvss_rubric_1.json, threat metric group). The questionnaire answer is explicit on this point ('Demonstrated in research or incident reports, not confirmed against our stack'), and the corpus supports exactly that grade and no higher. The CASE/ATLAS mapping rule is stated directly in the corpus: 'Realized / Incident -> E:A (Attacked), Demonstrated / Exercise -> E:P (Proof-of-Concept), Feasible -> E:U' (atlas/README.md). The nearest precedents the corpus returns for an un-notified, behaviour-affecting change to the model an organization consumes are all typed 'Exercise -> CASE Precedent Maturity E:P': AML.CS0065 Model Namespace Reuse, where Unit 42 made deployed Vertex AI / Azure AI Foundry pipelines silently resolve a stale model reference to a different, adversary-controlled model (the structural analogue of a silent version swap behind a stable endpoint identifier), and AML.CS0019 PoisonGPT, where a substituted model scored within 0.1% of the original on ToxiGen, i.e. the behaviour change was demonstrably undetectable to a downstream consumer. The underlying technique AML.T0018 (Poison AI Model / Modify AI Model Architecture) is likewise rated 'Demonstrated -> E:P'. No retrieved source documents a confirmed real-world case of this control being exercised to the detriment of a comparable organization, so the evidentiary threshold for E:A is not met; FRB SR 11-7 frames undisclosed vendor model modification as a governance risk to be managed ('Banks should expect vendors to conduct ongoing performance monitoring ... with disclosure to their clients, and to make appropriate modifications and updates over time'), which establishes the exposure is recognized and real but is not an incident record. E:U is clearly wrong: the mechanism is far past theoretical, it is reproduced in published research. Note that E is a threat-maturity metric only and does not discount the severity found elsewhere in this dimension: the vendor's standing right to change the model at its discretion, with disclosure only at the time the change takes effect, remains fully exercisable regardless of precedent count.
CR Confidentiality Criticality (org context)	M	M	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
IR Integrity Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
AR Availability Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
S Regulatory Consequence	P	P	agent	Confirmed. ABC uses OpenAI to augment 'sensitive business needs' and the questionnaire states a loss of control here would, on its own, trigger a reportable regulatory violation. The rubric defines S=P as a compromise that independently triggers a reportable regulatory violation (GDPR Art. 28, EU AI Act Title III). A silent, vendor-decided behaviour change in a system processing sensitive/regulated material defeats the deployer's own obligations: the EU AI Act requires deployers to keep the information underpinning their assessments up to date when elements change and to notify market surveillance authorities, and establishes serious-incident notification duties — obligations that cannot be met for a change the deployer learns about only as it takes effect. Under GDPR Art. 28 the controller must also be able to object to processor/subprocessor changes, which concurrent-only disclosure forecloses.
AU Silent/Automatic Trigger	Y	Y	agent	Confirmed, and this is the metric the rubric itself flags as the supplemental hook for dimension 1.3 ('supplemental_hook: AU'). A hosted-API model version rollout is a vendor-side fleet operation: the endpoint is re-pointed for every tenant at once, with no per-customer decision, and ordinary use of the service is enough to inherit it. ATLAS notes that 'many systems rely on the same models provided via an inference API, which means they share the same vulnerabilities' — the same shared-endpoint property that makes a single vendor action simultaneously effective across all customers. Matches the questionnaire answers 'at its discretion, at any time' and 'could happen to all of the vendor's customers at once'.
R Portability / Exit Recovery	U	A	agent · override	Override A -> U. The 'exported weights, portable data, standard interfaces' answer is accurate for ABC's own self-hosted resources, but the dependency under assessment is OpenAI consumed as a closed-weight hosted API: ABC holds no weights to export and therefore cannot reconstitute the specific model behaviour elsewhere with no loss. The rubric places R's primary hook at 1.2 (weight custody); for 1.3 the recovery question is whether the organisation can restore the prior behaviour after a vendor-side swap or snapshot deprecation, and with no artefact in custody that requires a manual migration (re-point to another provider or an open-weight model, re-engineer prompts, re-run evaluations). This is also what ABC's own RE answer implies ('a project, but no re-architecture'), which is inconsistent with a no-effort automatic recovery. Not I, because ABC runs its own infrastructure with standard interfaces and portable data, so the capability is reconstitutable without OpenAI — just not costlessly.
V Blast-Radius Concentration	C	C	agent	Confirmed. The questionnaire reports 'many or all' AI workloads depend on this component (shared control plane / gateway / embedding store), which is the rubric's definition of V=C — the dependency sits in the critical path for many/all AI workloads. This is precisely why the rubric marks 1.3 as having relevant subsequent impact: 'every downstream consumer of the model inherits an un-notified behavior change'. ATLAS likewise observes that many systems sharing one inference API share its failure modes, concentrating blast radius on a single vendor-controlled endpoint.
RE Exit / Mitigation Effort	M	M	agent	Confirmed. Mitigation here is a bounded project rather than trivial or re-architectural: ABC already owns its infrastructure, data and standard interfaces, so the fix is version pinning/behaviour-regression monitoring plus re-contracting for advance notice, or swapping the model behind an existing gateway — with prompt and evaluation re-work. Not L, because no unilateral contractual fix exists (the vendor holds a standing discretionary right and discloses only concurrently); not H, because no physical infrastructure replacement or re-architecture is required. Consistent with the org's own 'moderate: a project, but no re-architecture' answer.
U Vendor Notice Posture	Amber	Amber	agent	Confirmed. The questionnaire states sovereignty-relevant changes are 'disclosed at the time the change takes effect', which maps verbatim to the rubric's Amber value ('vendor discloses concurrently with the change taking effect'). Not Red, because disclosure does occur; not Green/Clear, because there is no advance window and no contractual notice guarantee — the vendor's right is exercisable at its discretion at any time, leaving ABC no pre-change window to re-validate outputs feeding regulated or automated decisions.

2 What are we feeding it?

2.1 Prompts / user inputs · also 2.2

MEDIUM6.1

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.

Evidence: vector, score and 21 metric rationales

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)

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?

Metric	Value	Prior	Source	Rationale
AV Access Path	N	L	agent · override	OVERRIDE of prior L. The prior ("our own cloud tenancy, vendor can still reach it") correctly describes ABC's self-housed resources, but dimension 2.1 concerns the prompt channel, which runs in the opposite direction: ABC sends 'sensitive business needs' content out to OpenAI's hosted API. That is vendor-direct network access with no intermediary — the rubric's definition of N. The prompt content does not stay resident in a customer-managed environment, so L understates the access path for this category. Where ABC's own stores are the asset in question, that exposure belongs to 2.2 (RAG ingestion), not here.
AC Compulsion Complexity	L	H	agent · override	OVERRIDE of prior H. Customer-managed keys and data-residency carve-outs — the barriers cited in the questionnaire — are real for data at rest in ABC's tenancy but do not apply to prompt content, which must be delivered to OpenAI in cleartext to be served. Prompt logging for abuse detection, retention for debugging and exposure during human review all rest on standard ToS clauses; the rubric records the only existing standard for 2.1 as 'Vendor ToS language (partial)'. The DOJ CLOUD Act paper reinforces this: legal process is encryption-neutral, so customer-side encryption does not raise the bar where the provider holds plaintext. No barrier has to be overcome first, hence L.
AT Trigger Conditions	N	N	agent	CONFIRM N. Prompt capture, logging and retention run continuously under the provider's standing contractual rights, matching the questionnaire answer 'at its discretion, at any time'. ATLAS mitigation AML.M0024 (AI Telemetry Logging) describes prompt-level telemetry as routine, always-on instrumentation, not an incident-gated capability. The one event-conditioned element — a safety flag routing a prompt to a human reviewer — is captured on the subsequent-impact axis per the rubric note, not as a trigger condition on the primary capture, so AT remains N.
PR Position Required	N	N	agent	CONFIRM N. Prompt content is visible to any party already inside the provider's subprocessor chain: abuse-detection reviewers, support engineers accessing retained prompts for debugging, and hosting/moderation subprocessors. The rubric keys dimensions 5.1 (human review processes) and 5.3 (support/debugging access) to PR precisely because this standing requires no elevated position and no compromise of ABC's own administrative credentials. Being the primary contracted vendor is not required, so L and H both overstate the position needed.
UI Org Action Required	P	P	agent	CONFIRM P. Submitting prompts is the ordinary, intended use of the service — ABC triggers the exposure simply by using OpenAI to augment its business needs, with no opt-in, feature acceptance or terms update required. This matches the questionnaire answer 'ordinary use of the service is enough to trigger it'. N is reserved for unilateral vendor acts such as a silent model swap (relevant to Category 3/4, not to the prompt channel), and A would require an affirmative ABC action that is absent here.
VC Primary Dependency Impact -- Confidentiality	L	L	agent	CONFIRM L. Prompts carrying 'sensitive business needs' are sent into OpenAI as the deliberate input channel, and the standard vendor claim of 'no training on prompts' does not resolve prompt logging for abuse detection, retention for debugging, or exposure during human review — so some confidentiality loss at the dependency is structural and triggered by ordinary use (questionnaire: 'ordinary use of the service is enough'). It is partial rather than total because the questionnaire records real barriers (customer-managed keys, data-residency carve-outs, contractual access restrictions) and because what reaches the vendor is a stream of individual prompt fragments and associated metadata, not ABC's underlying repositories, which it houses itself. H would require near-total loss of the confidential corpus, which the prompt channel alone does not deliver. Scenario text is thin on exactly what is sent, hence moderate confidence. Note the human-review path is scored as Subsequent Confidentiality, not here.
VI Primary Dependency Impact -- Integrity	H	H	agent	CONFIRM H. Two converging mechanisms let the input the model actually acts on be altered materially and without ABC's knowledge. (1) Vendor-side: the questionnaire records a standing, at-will contractual right exercisable by any party in the subprocessor chain, with sovereignty-relevant changes 'disclosed at the time the change takes effect' — so changes to moderation, system-level prompt handling or model version silently change how ABC's prompts are interpreted. (2) Input-channel-side: ABC houses its own stores that feed the model, which is exactly the pattern ATLAS documents for indirect and triggered prompt injection (AML.T0051) and prompt infiltration via public-facing applications later indexed by a RAG system (AML.T0093); the EchoLeak case (AML.CS0059) shows business-looking retrieved content carrying hidden instructions that defeated injection classifiers and attribution, i.e. undetected alteration. This matches the questionnaire's 'behaviour can be changed silently and materially' and 'downstream systems act on altered outputs without detection'. The assessor hint flags VC as the headline axis for 2.1, but that is a hint about what carries the dimension, not a cap on VI, and the injection evidence is specific to the input channel.
VA Primary Dependency Impact -- Availability	N	N	agent	CONFIRM N. Availability of the prompt-input channel is not meaningfully lost at this dependency: the questionnaire states ABC 'could keep operating this component', the capability is reconstitutable elsewhere with no loss (portable data, standard interfaces), and ABC uses and houses its own resources so the input path does not vanish if the vendor path is interrupted. Flagged prompts are routed to human review rather than denied outright, and the rubric treats that path as Subsequent Confidentiality, not an availability loss. The questionnaire's 'some downstream workloads degrade' is a beyond-the-dependency effect and belongs to Subsequent Availability, not VA. Residual risk of rate-limiting or moderation refusals blocking individual prompts is real but too marginal and recoverable to raise this to L on the evidence given.
SC Downstream Blast-Radius Impact -- Confidentiality	L	L	agent	Confirms prior. The rubric's 2.1 entry states outright that 'Flagged prompts routed to human review (Category 5) become Subsequent Confidentiality impact', and sets 2.1's impact axis to VC with subsequent_impact_relevant=true. ABC sends 'sensitive business needs' content into OpenAI under ordinary use, and the standard 'no training on prompts' claim does not resolve abuse-detection logging, debug retention or exposure during human review. Loss is partial, not total: only a flagged subset / fragments reach reviewers and subprocessors, matching the questionnaire's 'Partial' answers both at and beyond the dependency, and ABC's own stores remain behind CMEK and residency carve-outs. Hence L rather than H.
SI Downstream Blast-Radius Impact -- Integrity	L	H	agent · override	Overrides the prior H. The questionnaire's 'downstream systems act on altered outputs without detection' describes the primary model dependency; the rubric locates that pattern in dimension 1.3 (Model update / versioning control), noting 'Every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact'. For 2.1 the rubric assigns only VC as the primary impact axis, and the prompt-channel exposures it names (logging, retention, human review) do not themselves silently rewrite downstream outputs. A partial downstream integrity path nonetheless exists and is evidenced: retained or poisoned prompt context propagates to other users and tools (ATLAS AML.T0093 prompt infiltration 'could affect multiple users and various AI tools'; AML.CS0040 ChatGPT memory poisoning persisting across sessions; AML.T0031 eroding model integrity to produce 'plausible but incorrect' output), amplified by ABC's shared control plane across many or all workloads. That makes N too low and H unsupported for this dimension, so L.
SA Downstream Blast-Radius Impact -- Availability	L	L	agent	Confirms prior, consistent with the questionnaire answer 'Some downstream workloads degrade'. If the prompt channel is filtered, throttled or blocked by guardrails/abuse controls, the downstream workloads consuming completions degrade partially, and ABC's shared gateway/embedding store means many or all workloads feel it. Not H: the dependency itself was rated 'None: we could keep operating this component' and the capability is reconstitutable with portable data and standard interfaces. Not S: the scenario is augmentation of business needs with no physical-harm or safety-relevant failure mode described, and the rubric attaches the safety/regulatory supplemental hook to other dimensions (e.g. 4.4, 1.4) rather than to 2.1.
E Precedent Maturity	P	P	agent	Confirming the questionnaire prior of Proof-of-Concept for the prompt channel (2.1). The corpus precedent that matches this dimension — unintended disclosure of prompt/conversation content out of a hosted LLM — is consistently classified as 'Demonstrated'/'Exercise', which the ATLAS-to-CASE mapping converts to E:P: ATLAS technique AML.T0057 'LLM Data Leakage' is explicitly tagged 'Maturity: Demonstrated → CASE Precedent Maturity E:P', and the ChatGPT/Bard conversation-exfiltration case studies (AML.CS0021, AML.CS0029) and the ZombieAgent ChatGPT connector/memory work (AML.CS0066) are all typed 'Exercise → CASE Precedent Maturity E:P' against OpenAI's own stack class, but as researcher demonstrations rather than confirmed exploitation of ABC. The corpus does contain incident-grade (E:A) material around hosted OpenAI-family services — LLM Jacking (AML.CS0030) and Storm-2139 Azure OpenAI guardrail bypass — but those concern credential theft and guardrail circumvention, not the sovereignty concern specific to 2.1 (vendor-side prompt logging for abuse detection, prompt retention for debugging, and prompt exposure during human review). The corpus returned no documented real-world case of that vendor-side prompt-review/retention channel being exercised against a comparable organisation, and the scenario text is thin on what exactly ABC sends, so E:A is not supportable and E:U is too weak given the documented demonstrations. Note this is an assessment of Category 2.1's own exposure, not the primary dependency; the questionnaire's own answer to the precedent question ('demonstrated in research or incident reports, not confirmed against our stack') independently corroborates P.
CR Confidentiality Criticality (org context)	M	M	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
IR Integrity Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
AR Availability Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
S Regulatory Consequence	P	P	agent	CONFIRM. ABC deliberately sends 'sensitive business needs' content into OpenAI through the prompt channel. The 2.1 concern is that 'no training on prompts' does not foreclose prompt logging for abuse detection, retention for debugging, or prompt exposure during human review. If confidential or personal data in prompts is retained or read by vendor/subprocessor reviewers outside ABC's documented instruction, that is independently a GDPR Art. 28 processor/subprocessor failure (processing beyond instruction, unauthorised onward disclosure) and, where the assisted workload is in scope, an EU AI Act deployer obligation failure regarding input data governance (eu-ai-act-2024-1689.md Art. 26 deployer duties on input data and record-keeping). The rubric lists exactly these as the S=Present exemplars. The questionnaire independently answers 'Yes' to the reportable-violation question, and this category's own facts support it rather than merely inheriting it.
AU Silent/Automatic Trigger	Y	Y	agent	CONFIRM, and 2.1 is the strongest case for it in this scenario. Prompt handling is governed by platform-wide policy: retention windows, abuse-detection sampling, trust-and-safety review thresholds and the subprocessor list are set once by the vendor and apply to every tenant's prompt traffic at the same moment, with no per-customer decision. The questionnaire's own answers align ('ordinary use of the service is enough to trigger it'; control exercisable 'at its discretion, at any time'; 'any party already in the subprocessor chain'). There is no discrete, case-by-case act required for ABC's prompts to enter a logging or review pipeline — it happens as a by-product of normal inference calls.
R Portability / Exit Recovery	U	A	agent · override	OVERRIDE A -> U. The prior ('exported weights, portable data, standard interfaces') describes the primary model dependency, but the prompt-input channel is not reconstituted with zero loss. Two frictions apply: (a) prompt scaffolding is model-specific — system prompts, few-shot exemplars, guardrail and refusal tuning, and output-format contracts must be re-authored and re-validated against a replacement model before the input channel behaves equivalently; (b) prompts already transmitted and retained in vendor logs or seen by human reviewers cannot be recalled, so the pre-exit exposure is not undone by migration. This is manual migration effort, not automatic reconstitution. It is not Irrecoverable: ABC houses its own resources and data stores, prompt construction logic is ABC's own code, and the chat-completions style interface is a de facto standard, so the capability can be stood up elsewhere without the original vendor. Lower confidence because the scenario is thin on how deeply prompt engineering is coupled to the specific model.
V Blast-Radius Concentration	C	C	agent	CONFIRM. Prompts are the single deliberate input channel through which ABC's augmentation workloads reach the model, so the channel sits in the critical path of many/all AI workloads rather than one narrow workload — the questionnaire's 'many or all: shared control plane, gateway, identity or embedding store' answer holds for this category on its own terms. Concentration is compounded because ABC also feeds its own internal document stores into the model for retrieval (2.2), so a single retention or human-review policy touching the prompt path aggregates sensitive content from across the business into one vendor-side location. The rubric's 2.1 entry marks this dimension as carrying Subsequent Confidentiality precisely because exposure does not stop at the prompt.
RE Exit / Mitigation Effort	M	M	agent	CONFIRM. Mitigating prompt-channel exposure is a scoped project rather than a re-architecture: negotiate a zero/limited-retention and no-human-review enterprise term, move to a zero-data-retention endpoint, and insert a prompt-side DLP/redaction or tokenisation gateway so sensitive fields never leave ABC's tenancy. ABC already has the structural prerequisites — it hosts its own resources and already holds 'real barriers: customer-managed encryption keys, data-residency carve-outs, contractual access restrictions' — so no physical infrastructure replacement is needed. It is above Low because it requires re-contracting plus a redaction control in the call path and re-validation that redacted prompts still produce usable results, not a trivial config swap.
U Vendor Notice Posture	Amber	Amber	agent	CONFIRM, with low-moderate confidence. The questionnaire states sovereignty-relevant changes are 'disclosed at the time the change takes effect', which is the Amber definition verbatim, and nothing in this category's facts distinguishes the prompt channel from that general posture — retention-window, abuse-monitoring-scope and subprocessor-list updates are typically published concurrently with effect rather than under a contractually guaranteed notice period. Not Clear or Green, because no contractual advance-notice commitment is evidenced; not Red, because disclosure does occur. The corpus returned no vendor terms-of-service or DPA notice-period language (retrieval surfaced only regulatory notice regimes such as nydfs-23-nycrr-500 and EU AI Act notified-body provisions, which govern different parties), so this rests on the questionnaire and scenario alone.

3 What does it create from our data: and where does THAT go?

3.2 Vector database / embedding store location and control · also 3.1, 3.5

MEDIUM5.3

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.

Evidence: vector, score and 21 metric rationales

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)

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?

Metric	Value	Prior	Source	Rationale
AV Access Path	L	L	agent	Confirmed. The embedding store sits inside ABC's own cloud tenancy/premises ('ABC uses and houses its own resources'), so it is not a vendor-direct API endpoint (N) and not a store operated by a separate embedding vendor (which would push toward A). But it is explicitly still vendor-reachable: the questionnaire reports managed-service, telemetry and support-tunnel reach, so it is not air-gapped/fully customer-controlled (P). The rubric's L value — 'resident in customer-managed environment but still vendor-reachable' — is an exact description of this posture, and the rubric names AV as one of the two exploitability metrics that carry 3.2.
AC Compulsion Complexity	H	H	agent	Confirmed. ABC reports customer-managed encryption keys, data-residency carve-outs and contractual access restrictions on the store — which is verbatim the rubric's definition of AC:H ('technical or contractual barriers (customer-managed keys, data-residency carve-outs) must be overcome first'). A standard ToS clause alone would not reach the vectors. Caveat for the reviewer: CMEK is only a partial barrier for a vector store, since embeddings must be decrypted in memory to be indexed and searched, and ATLAS AML.T0024 shows derived representations can be inverted/attacked without needing the raw corpus — this is why the resulting confidentiality loss is scored partial rather than none, but the barriers themselves still exist and must be overcome, so H stands.
AT Trigger Conditions	N	N	agent	Confirmed. ABC reports a standing contractual right exercisable at the vendor's discretion at any time, and the reach vectors for the store (managed-service control plane, telemetry, support tunnel) are continuously available rather than gated on a designation, litigation hold or incident. No specific triggering event is required, so AT:N rather than P.
PR Position Required	N	N	agent	Confirmed. ABC states that any party already in the subprocessor chain is positioned to exercise this control. For 3.2 the rubric notes the store carries 'its own jurisdiction, subprocessor chain, and retention policy', and lists PR as a carrying metric — the point being that no privileged position beyond ordinary subprocessor-chain membership is needed, and certainly no compromise of ABC's own admin credentials (H). Because the managed-service/telemetry/support path is available to the chain generally and not only to the primary contracted vendor, N is correct rather than L.
UI Org Action Required	P	P	agent	Confirmed. ABC reports that ordinary use of the service is enough to trigger the exposure. That is structurally true of an embedding store: every routine ingestion and retrieval of sensitive business content writes and queries derived vectors in the store, so the exposure accumulates through normal operation with no affirmative opt-in (A) required. I considered N, since ABC also reports that behaviour can be changed silently and materially and that notice arrives only concurrently with the change; however, the specific exposure at 3.2 — sensitive-content derivatives accruing in a vendor-reachable store — is driven by ABC's own routine traffic rather than by a unilateral vendor act, so P is the better fit. Reviewers should note the N/P boundary is the softest judgment in this group.
VC Primary Dependency Impact -- Confidentiality	L	L	agent	Embedding store runs in ABC's own tenancy under customer-managed encryption keys with data-residency carve-outs. The sovereign-controls evidence confirms that externally/customer-held keys force any decryption through a customer-controlled call and that support access is constrained and logged, which blunts bulk plaintext extraction. Residual confidentiality exposure is the managed-service/telemetry/support-tunnel path, exercisable at vendor discretion by any subprocessor-chain party under ordinary use, yielding metadata, query patterns and index fragments. Embeddings are a reversible derived object, but inversion/reconstruction is only 'Feasible' (AML.T0024.001, E:U) and demonstrated in research rather than against this stack. Partial, not near-total, loss at the store itself: prior L confirmed.
VI Primary Dependency Impact -- Integrity	H	H	agent	Customer-managed keys protect confidentiality at rest but not the integrity of a vendor-reachable managed control plane. The organization reports behaviour at this dependency 'can be changed silently and materially', with downstream systems acting on altered outputs without detection. ATLAS corroborates this as a Demonstrated (CASE E:P) capability class: RAG Poisoning (AML.T0070) contaminates indexed content so it surfaces for targeted queries, and False RAG Entry Injection (AML.T0071) explicitly bypasses data-monitoring tools and resists direct deletion. Because this store is the shared retrieval substrate for many or all AI workloads, undetectable alteration of embeddings or index contents is a near-total loss of trust in what the store returns. Prior H confirmed.
VA Primary Dependency Impact -- Availability	N	N	agent	The embedding store is resident in ABC's own cloud tenancy or premises, the data is portable, and the capability is reconstitutable 'with no loss' through re-embedding from source documents over standard interfaces, with exit assessed as a moderate project rather than a re-architecture. The exercising party therefore has reach to read from or alter the store but no ability to withdraw or shut it down; ABC could keep operating this component. The reported 'some downstream workloads degrade' belongs on the subsequent availability axis, not at the dependency itself. Prior N confirmed, with somewhat lower confidence because loss of the managed-service layer would introduce operational friction even if the store keeps serving queries.
SC Downstream Blast-Radius Impact -- Confidentiality	L	L	agent	Confirms the questionnaire prior. The rubric defines 3.2 as itself the subsequent system ('This dimension IS the subsequent system by definition'), so downstream confidentiality is scored on what propagates from the embedding store to other systems and parties. Two facts bound this to partial rather than total loss: (a) the store runs in ABC's own tenancy under customer-managed encryption keys with data-residency carve-outs and contractual access restrictions ('Real barriers'), which blunts the classic third-party-vector-DB total-exposure finding the rubric flags for 3.1; and (b) the organization itself reports downstream confidentiality loss as 'Partial'. What remains is real, not nil: the vendor retains standing reach via managed service, telemetry and support tunnel, and 'any party already in the subprocessor chain' can exercise it under ordinary use. Embeddings are a reversible derived object — ATLAS AML.T0024.001 (Invert AI Model) establishes that derived representations and model internals can be worked backwards to recover private training content — so vendor-side reach over the index plus telemetry/log derivatives yields metadata, fragments and aggregates about sensitive business content rather than near-total disclosure of the underlying corpus. Partial/limited loss on this axis = L.
SI Downstream Blast-Radius Impact -- Integrity	H	H	agent	Confirms the questionnaire prior at High. The organization reports that behaviour at this dependency 'can be changed silently and materially' and that beyond it 'downstream systems act on altered outputs without detection' — the defining condition for near-total integrity loss, because an undetectable alteration removes the organization's ability to trust any downstream result. The corpus supports this as demonstrated, not theoretical: ATLAS AML.T0070 (RAG Poisoning, maturity Demonstrated) describes injecting malicious content into the data a retrieval system indexes so it contaminates future threads, and AML.T0071 (False RAG Entry Injection, Demonstrated) shows false entries can be planted so they bypass data-monitoring tools and resist direct deletion — i.e. silent and persistent. The rubric makes the same point structurally for the adjacent retrieval node (4.1): a party that can alter what gets fed to the model produces 'Subsequent Integrity impact on a later pipeline stage'. Here the blast radius is maximal in scope because 'many or all' AI workloads share this embedding store, so one silent index alteration propagates to every dependent workload's outputs and the decisions taken on them. Note the asymmetry that justifies H here while SC stays L: customer-managed keys and residency carve-outs protect confidentiality of data at rest but do nothing to prevent a reachable managed-service operator from changing what the index returns.
SA Downstream Blast-Radius Impact -- Availability	L	L	agent	Confirms the questionnaire prior. The organization reports that at the dependency itself availability loss is 'None: we could keep operating this component' — consistent with the store residing in ABC's own tenancy rather than vendor-hosted infrastructure — and that beyond it only 'some downstream workloads degrade'. That is partial, not total, loss of availability downstream, so L rather than H. Recoverability reinforces the ceiling: exit is rated portable ('exported weights, portable data, standard interfaces') with moderate mitigation effort, and embeddings can be re-derived from ABC's retained source corpus, so withdrawal degrades rather than destroys downstream capability. S (Safety) is not selected: the scenario describes augmenting sensitive business needs via OpenAI with no physical process, actuation, clinical or life-safety function in the path, and the questionnaire's answer to whether anyone could be harmed identifies only workload degradation. The 'Yes' answer on reportable regulatory violation is a regulatory consequence captured by the supplemental S metric (Regulatory Consequence), which the rubric keeps distinct from availability-driven physical harm — so it must not be imported into SA here.
E Precedent Maturity	P	P	agent	CONFIRMS the questionnaire prior (P), and the corpus independently supports it. The ATLAS README maps 'RAG Databases' to CASE dimension 3.2, and every ATLAS object anchored to embedding/vector-store compromise is graded Demonstrated/Exercise, which the README itself maps to E:P: AML.T0085.000 RAG Databases (Demonstrated -> E:P), AML.T0070 RAG Poisoning (Demonstrated -> E:P), AML.T0071 False RAG Entry Injection (Demonstrated -> E:P), AML.T0066 Retrieval Content Crafting, which explicitly names 'a vector database used in a retrieval augmented generation (RAG) system' (Demonstrated -> E:P), and AML.T0064 Gather RAG-Indexed Targets (Demonstrated -> E:P). The case studies that actually touch a vector store are researcher-run Exercises, not incidents against comparable organisations: AML.CS0062 (Semantic Kernel In-Memory Vector Store filter escape to RCE) and AML.CS0026 (M365 Copilot RAG-indexed targeting). No E:A grounds exist for the control at issue in this scenario. The exposure here is not a third-party vector-DB breach but a vendor/subprocessor exercising managed-service, telemetry or support-tunnel reach into an embedding store that sits in ABC's own tenancy behind customer-managed keys and data-residency carve-outs. The Google Cloud sovereign-controls material confirms that provider administrative and technical-support access to customer workloads is a real, standing mechanism (hence access transparency and access approval controls), but documents it as logged, justified and conditionally permitted rather than as a documented adverse exercise against a customer. The nearest true Incident, AML.CS0068 (OpenAI/Hugging Face, where agents reached five customers' datasets and internal repositories), occurred inside a vendor's own production estate via infrastructure compromise, not through exercise of a contractual access right against a customer-controlled store, so it establishes plausibility rather than precedent for this dimension. The only E:A-graded neighbour, AML.T0036 Data from Information Repositories (Realized -> E:A), is generic enterprise repository mining and is not the sovereignty control being assessed. Net: the mechanism is well demonstrated in research and incident reporting, but is not confirmed against ABC's own CMK-protected, residency-carved-out stack, which is precisely the rubric's definition of P. Rated with moderate-high rather than full confidence because the scenario description is very thin ('ABC uses and houses its own resources while using Open AI'), so the assessment leans on the questionnaire's account of the store's placement and the vendor's residual reach.
CR Confidentiality Criticality (org context)	M	M	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
IR Integrity Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
AR Availability Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
S Regulatory Consequence	P	P	agent	CONFIRM. The embedding store holds derivatives of ABC's sensitive business content, and the rubric defines S=P as a compromise that independently triggers a reportable regulatory violation, naming GDPR Art. 28 explicitly. Vendor/subprocessor reach into a store that ABC itself controls is precisely an Art. 28 processor/subprocessor-chain problem, and unauthorised access to embeddings of personal data is a reportable personal-data breach in its own right — ABC does not need any other dependency to fail for the violation to crystallise. The reversibility of derived objects (ATLAS AML.T0024, incl. Invert AI Model, maturity Feasible) means embeddings cannot be treated as non-personal hashes that would escape the trigger, and 3.1's framing that 'no training on your data' never covers derived objects reinforces that the contractual comfort does not remove the regulatory exposure. Questionnaire also answers 'Yes' to the independent-regulatory-trigger question.
AU Silent/Automatic Trigger	Y	Y	agent	CONFIRM. The exposure vector here is a managed-service/telemetry/support-tunnel path and the subprocessor chain, not a per-customer decision. Changes of that kind — a subprocessor addition, a telemetry or managed-agent change, a terms change to the standing access right — are pushed fleet-wide and take effect for every tenant simultaneously with no case-by-case action, which is the rubric's Y definition. This is corroborated by the questionnaire's own answers that the control is exercisable 'at its discretion, at any time (standing right under the contract)' and that 'ordinary use of the service is enough to trigger it' (rubric UI=P, AT=N), both of which describe an automatic rather than discrete trigger. ABC's CMK and residency carve-outs raise the complexity of actually reading the data but do not make the triggering event case-by-case.
R Portability / Exit Recovery	U	A	agent · override	OVERRIDE (A -> U). The questionnaire's 'no loss: portable data, standard interfaces' is right about the container but not about the capability. The store sits in ABC's own tenancy, so the vectors and source documents survive vendor exit — but the vectors were produced by the vendor's embedding model, and embedding spaces are not interoperable across providers: a different embedding model yields a different vector space, so the existing index cannot be queried by a replacement embedder. Reconstituting the capability therefore requires re-embedding the whole corpus and rebuilding/re-tuning the index — a manual migration project, which is exactly the rubric's U ('manual migration effort required'), not A ('with no loss'). A=Automatic would also be internally inconsistent with ABC's own RE answer of 'Moderate: a project, but no re-architecture'; a capability that can be reconstituted with literally no loss would not require a project. It is not I, because no vendor-held artefact is indispensable: standard interfaces and portable, exportable data mean ABC is not locked to the original vendor. Confidence moderated because the corpus returned no passage specifically on vector-store/re-embedding exit mechanics.
V Blast-Radius Concentration	C	C	agent	CONFIRM. ABC reports that 'many or all' AI workloads depend on this shared embedding store, and the rubric's C definition cites a shared embedding store as its canonical example of a dependency sitting in the critical path for many/all AI workloads. This is also the classifier's stated reason 3.2 carries this category. Concentration is reinforced by the downstream answers: integrity loss propagates fully ('downstream systems act on altered outputs without detection') and 'some downstream workloads degrade', i.e. a single compromise at this one node radiates across the retrieval-dependent estate rather than being contained to one narrow use case.
RE Exit / Mitigation Effort	M	M	agent	CONFIRM. Mitigation does not require re-architecture or physical infrastructure replacement: the store already runs in ABC's own tenancy behind customer-managed keys and data-residency carve-outs, so the realistic fixes are incremental — tighten or revoke the managed-service/support-tunnel path, constrain telemetry egress, re-contract the subprocessor-notification and standing-access clauses, or re-embed onto an alternative embedder. Each is a project but none rebuilds the architecture, which is the rubric's M band. It is not L, because the exposure derives from a standing contractual right plus a vendor-reachable managed path — neither is a trivial swap-out or a trivial contractual fix. Consistent with R=U above (a migration project, not a costless switch).
U Vendor Notice Posture	Amber	Amber	agent	CONFIRM. ABC reports sovereignty-relevant changes (model versions, subprocessors, hosting, terms) are 'disclosed at the time the change takes effect', which maps exactly onto the rubric's Amber ('vendor discloses concurrently with the change taking effect'). It is not Green or Clear: there is no reported advance-notice window, let alone a contractually guaranteed one, which matters here because a subprocessor addition is the very event that would widen who can reach the embedding store (PR=N, 'any party already in the subprocessor chain'). It is not Red either, since disclosure does occur rather than never. Concurrent-only notice means ABC learns of a change too late to object or to pause processing before exposure begins — relevant to its Art. 28 controller duties. No corpus passage evidenced the vendor's actual notice terms, so this rests on the questionnaire answer.

4 Who's deciding what the AI sees and does?

4.1 Retrieval pipeline (RAG) ownership · also 4.4

MEDIUM4.5

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.

Evidence: vector, score and 21 metric rationales

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)

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?

Metric	Value	Prior	Source	Rationale
AV Access Path	L	L	agent	Confirms the prior. ABC 'uses and houses its own resources', so the retrieval/ranking machinery (index, retriever, any reranking stage) sits inside ABC's own tenancy or premises rather than behind a vendor-direct API. It is nevertheless vendor-reachable at its boundary: every retrieved context set is handed to OpenAI's hosted endpoint for generation, and vendor-supplied embedding/ranking model versions reachable over that same API shape what the pipeline returns. That is exactly the rubric's L definition -- 'resident in customer-managed environment but still vendor-reachable' -- not N (no intermediary vendor-direct hosting of the retrieval layer itself) and not P (the pipeline is not air-gapped; it makes outbound calls to OpenAI by design).
AC Compulsion Complexity	H	H	agent	Confirms the prior, and it is if anything better supported for this category than for the primary dependency. Because ABC operates the retrieval layer itself, no standard ToS clause or routine legal process lets a vendor reach in and change ranking behaviour or read the index: an exercising party would first have to overcome ABC's own technical and contractual barriers (the customer-managed encryption keys, data-residency carve-outs and contractual access restrictions reported in the questionnaire) or work indirectly through the vendor-side model endpoints. This matches the rubric's H definition ('technical or contractual barriers ... must be overcome first').
AT Trigger Conditions	N	N	agent	Confirms the prior. The residual vendor-side influence on this pipeline -- the version of the hosted embedding/ranking/generation model that ABC's retriever feeds and depends on -- can be changed at the vendor's discretion under a standing contractual right, with no sanctions designation, litigation hold or incident needed. The questionnaire's own answers reinforce this: control is exercisable 'at its discretion, at any time', changes are only 'disclosed at the time the change takes effect', and the loss event could hit all of the vendor's customers at once with no case-by-case decision. No triggering event is required, so N rather than P.
PR Position Required	L	N	agent · override	OVERRIDE of the prior N. The prior reflects the primary dependency, where any party already in the subprocessor chain has standing. That does not hold for this category: the ranking/reranking layer is ABC-operated infrastructure inside ABC's tenancy, so an arbitrary downstream subprocessor has no position from which to change what gets retrieved and fed to the model. The only party with the standing to alter this pipeline's inputs or behaviour is the primary contracted vendor (OpenAI) acting through the embedding/ranking/generation endpoints the pipeline calls -- the rubric's L definition, 'requires being the primary contracted vendor'. H is wrong because nothing requires compromising ABC's own administrative credentials; the vendor can act within its legitimate contracted role. This is the deliberate, modest-exposure reading the 4.1 classifier describes ('exposure is modest because ABC owns this layer'), while still keeping PR as one of the two metrics the rubric names as carrying this dimension.
UI Org Action Required	P	P	agent	Confirms the prior. Because ABC owns the retrieval configuration, a vendor cannot unilaterally rewrite ABC's ranking logic (which would argue N); but no affirmative act by ABC is needed either (which rules out A). The exposure is realised by ordinary operation: every ordinary query routes retrieved context through the pipeline to the vendor endpoint, and a silently updated vendor-side embedding or ranking model then alters what is fed to the generator -- the rubric's noted Subsequent Integrity path -- without ABC opting in or accepting anything. The questionnaire's 'ordinary use of the service is enough to trigger it', combined with change disclosure only at the moment of effect, matches P ('routine, ordinary use of the service triggers the exposure'). Lower confidence because the boundary with N depends on how much of the ranking stack is vendor-supplied, which the scenario does not state.
VC Primary Dependency Impact -- Confidentiality	L	L	agent	Confirm L. ABC 'uses and houses its own resources', so the index, queries and ranking signals sit in ABC's own tenancy; but the questionnaire states the environment is still vendor-reachable (managed service, telemetry, support tunnel) and that any party already in the subprocessor chain has standing, which matches the rubric's AV:L 'resident in customer-managed environment but still vendor-reachable' notion. What such a party would see at this layer is limited and indirect -- query strings, retrieval logs, index/embedding metadata and retrieved fragments -- not the whole corpus, which is governed under Category 2. Customer-managed keys and residency carve-outs further cap the loss. That is 'partial or limited loss', i.e. L, consistent with the questionnaire's own 'metadata, fragments, aggregates' answer. Note the rubric assigns node 4.1 no primary impact axis at all, so a case for N exists; L is the conservative reading.
VI Primary Dependency Impact -- Integrity	L	H	agent · override	Override H -> L. The prior 'behaviour can be changed silently and materially' describes the primary dependency (the OpenAI model), and the rubric places exactly that pattern at node 1.3 Model update / versioning control -- primary_impact_axis ['VI'], note 'Every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact.' For node 4.1 the rubric records primary_impact_axis [] and locates the harm downstream: 'A reranking vendor can alter what gets fed to the model -- Subsequent Integrity impact on a later pipeline stage.' Since ABC self-operates the retrieval and ranking machinery, no external party can rewrite the ranking logic wholesale; vendor influence is indirect, via embedding/reranking API behaviour inherited from the model vendor (changes disclosed only when they take effect), which can shift what the ranker surfaces without altering ABC's pipeline code. That is partial, not total, loss of integrity at this dependency -> L. The full un-detected alteration the questionnaire reports is carried as Subsequent Integrity on the stages this pipeline feeds, not at the vulnerable system.
VA Primary Dependency Impact -- Availability	N	N	agent	Confirm N. ABC hosts the retrieval pipeline itself, and the questionnaire states the capability could not be withdrawn ('we could keep operating this component') and is reconstitutable with no loss via portable data and standard interfaces. No party outside ABC can switch off ABC's own index or ranker; the 'some downstream workloads degrade' answer is an effect beyond this dependency and belongs to Subsequent Availability, not to VA. Rubric lists no primary impact axis for 4.1, which is consistent with no availability loss at the vulnerable system.
SC Downstream Blast-Radius Impact -- Confidentiality	L	L	agent	Confirming the prior. Dimension 4.1 is self-operated by ABC ('uses and houses its own resources'), so the retrieval/ranking layer itself is not a vendor-held confidentiality channel. However, what the retrieval layer selects is forwarded out of ABC's boundary to OpenAI as context, so confidentiality loss beyond this component is real but partial — retrieved fragments/chunks and retrieval metadata rather than wholesale disclosure of the corpus. This matches the questionnaire's 'Beyond this dependency ... Partial' answer and the rubric's framing that retrieval-stage confidentiality normally lands on the embedding/vector-store dimensions (3.1/3.2) rather than on the ranking layer itself.
SI Downstream Blast-Radius Impact -- Integrity	H	H	agent	Confirming the prior, and this is the metric that carries the category. The rubric explicitly annotates 4.1: 'A reranking vendor can alter what gets fed to the model -- Subsequent Integrity impact on a later pipeline stage', and marks subsequent_impact_relevant=true for 4.1. Any change in what the ranking/reranking stage surfaces propagates to the model and to every consumer of its output, and the questionnaire reports that behaviour 'can be changed silently and materially' and that 'downstream systems act on altered outputs without detection', with 'many or all' AI workloads sharing this layer and a reportable regulatory violation if control is lost. MITRE ATLAS corroborates that manipulation of retrieved content (AML.T0070 RAG Poisoning, AML.T0071 False RAG Entry Injection, maturity 'Demonstrated' → E:P) reliably causes the LLM to emit false content that downstream consumers treat as authoritative — consistent with 'demonstrated in research/incident reports, not confirmed against our stack'. Undetectable, pipeline-wide alteration of model inputs is a near-total loss on the downstream integrity axis.
SA Downstream Blast-Radius Impact -- Availability	L	L	agent	Confirming the prior. ABC owns and houses the retrieval machinery, the questionnaire states the component itself could keep operating ('None' at the primary level) and the capability is reconstitutable with no loss via portable data and standard interfaces; downstream effect is limited to 'some downstream workloads degrade' (RAG-augmented answers lose quality or fall back to non-augmented operation). That is partial, not total, downstream availability loss. S is not warranted: the scenario is augmentation of sensitive business needs with no evidence of a physical process, safety-critical control loop, or agentic tool execution (4.3 not in scope here), so no safety-relevant failure mode is established.
E Precedent Maturity	P	P	agent	Confirms the questionnaire prior. For dimension 4.1 the relevant precedent is manipulation of what the retrieval/ranking layer feeds the model. MITRE ATLAS records this capability at 'Demonstrated' maturity, which the CASE corpus maps explicitly to E:P: AML.T0070 RAG Poisoning ('Maturity: Demonstrated -> CASE Precedent Maturity E:P'), AML.T0071 False RAG Entry Injection (Demonstrated -> E:P) and AML.T0064 Gather RAG-Indexed Targets (Demonstrated -> E:P). The supporting case studies are all classified as Exercise, not Incident (AML.CS0026 Financial Transaction Hijacking with M365 Copilot, 2024-08-08; AML.CS0035 Data Exfiltration from Slack AI via Indirect Prompt Injection, 2024-08-20; AML.CS0059 EchoLeak zero-click prompt injection against M365 Copilot, 2025-05-25), and the ATLAS README states Exercise/Demonstrated -> E:P while only an Incident case study gives documentary grounds for E:A. So there is solid research/exercise-grade demonstration that the retrieval and reranking stage can be made to alter model inputs, but nothing confirmed against ABC's own self-operated stack — the exact definition of P. Incident-grade (E:A) precedents that exist nearby — AML.T0080 AI Agent Context Poisoning (Realized) and AML.CS0072 AI Recommendation Poisoning (Incident, 2026-02-10) — concern agent memory/context and recommendation layers, which the corpus anchors to other dimensions (2.x, 6.4) rather than to ownership of the retrieval/ranking pipeline, so they do not justify escalating 4.1 to A. The scenario also gives no indication ABC has observed such an event: it states only that ABC 'uses and houses its own resources' with OpenAI augmenting sensitive work, and the questionnaire answer for precedent is 'Demonstrated in research or incident reports, not confirmed against our stack'. E:U is excluded because the technique is far beyond theoretical; E:X is excluded because evidence exists. Confidence is moderate rather than high because the retrieved precedents sit on the data/content side (2.2) rather than on a vendor-operated reranking service, which the classifier itself flagged as only inferred for this category.
CR Confidentiality Criticality (org context)	M	M	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
IR Integrity Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
AR Availability Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
S Regulatory Consequence	N	P	agent · override	OVERRIDE of prior P. The questionnaire's 'Yes' to a reportable violation reflects the primary dependency (sending sensitive business content to OpenAI — a transfer/processor question belonging to Categories 1-2), not ABC's own retrieval layer. For 4.1 the rubric assigns exploitability PR/AV and no supplemental hook at all; it reserves the S (Safety -> Regulatory Consequence) hook for 4.4 (guardrail/safety filter) and 1.4 (evaluation ownership). A compromise confined to ABC's self-operated ranking/reranking machinery changes which of ABC's own documents get surfaced; it does not by itself constitute a GDPR Art. 28 processor breach (ABC is the operator) and the retrieved EU AI Act text ties notification duties to high-risk classification and serious-incident/market-surveillance pathways that this scenario does not establish. The questionnaire also records 'real barriers: customer-managed keys, residency carve-outs, contractual access restrictions', further weakening an independent trigger at this layer. Moderate confidence only, because sensitive-data over-retrieval could in principle cascade into a reportable disclosure — but that consequence is scored where the transfer occurs.
AU Silent/Automatic Trigger	Y	Y	agent	CONFIRM Y. Although ABC operates the pipeline, the questionnaire states the vendor can still reach it (managed service, telemetry, support tunnel), that the right is exercisable 'at its discretion, at any time', that 'ordinary use of the service is enough to trigger it', and that behaviour 'can be changed silently and materially'. Any vendor-supplied component inside the retrieval path (e.g. hosted embedding or reranking endpoints used to decide what is fed to the model) updates fleet-wide: the rubric's note on 1.3, from which AU is hooked, describes exactly this — 'every downstream consumer of the model inherits an un-notified behavior change' with no case-by-case decision. SR 11-7 reinforces that vendor components embedded in an in-house pipeline change outside the user's control. Confidence held at moderate because the self-operated portions of the pipeline would require discrete action.
R Portability / Exit Recovery	A	A	agent	CONFIRM A (Automatic). ABC 'uses and houses its own resources', so the source corpus, index and ranking configuration are in ABC's custody; the questionnaire confirms portable data and standard interfaces and that capability withdrawal impact at this dependency is 'None: we could keep operating this component'. Retrieval and reranking components are commodity, interchangeable layers, so the capability can be reconstituted without the original vendor — no residual dependency that would make this U or I.
V Blast-Radius Concentration	C	C	agent	CONFIRM C (Concentrated). The rubric's own V definition names a shared control plane / embedding store as the concentrated case, and the questionnaire reports 'many or all' AI workloads depend on this component. The retrieval/ranking layer is by construction the single chokepoint that 'decides what gets retrieved and fed to the model', so any integrity change there propagates to every grounded workload — consistent with the reported full downstream integrity impact ('downstream systems act on altered outputs without detection').
RE Exit / Mitigation Effort	M	M	agent	CONFIRM M (Moderate). Replacing a retrieval/reranking component in a self-owned pipeline is a project — re-embedding or re-indexing the corpus, re-tuning relevance, and re-validating output quality — but it requires no re-architecture of the wider platform and no physical infrastructure replacement, since ABC already houses the data and uses standard interfaces. That matches the rubric's M band rather than L (trivial swap, not credible given relevance revalidation) or H (re-architecture/re-contracting).
U Vendor Notice Posture	Amber	Amber	agent	CONFIRM Amber. Notice posture here is governed by the vendor-supplied elements reachable inside the pipeline; the questionnaire states changes are 'disclosed at the time the change takes effect', which is the rubric's Amber definition exactly (disclosure concurrent with the change). There is no contractually guaranteed advance notice (which would be Clear) and no evidence of silent non-disclosure (Red). SR 11-7's expectation that vendors conduct ongoing monitoring 'with disclosure to their clients' is an expectation, not a guarantee, and the rubric notes the only standard touching versioning notice (OMB M-25-22) is US federal procurement only.

5 Which humans are actually looking at our stuff?

5.3 Support / debugging access · also 5.1

MEDIUM4.0

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.

Evidence: vector, score and 21 metric rationales

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)

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?

Metric	Value	Prior	Source	Rationale
AV Access Path	L	L	agent	Confirmed. The deployment answer states the workload sits 'in our own cloud tenancy or premises, but the vendor can still reach it (managed service, telemetry, support tunnel)' — this is the textbook definition of the rubric's L value: 'resident in customer-managed environment but still vendor-reachable' (sovereignty_cvss_rubric_1.json). For dimension 5.3 specifically, the relevant access path is the support tunnel / telemetry channel into ABC's own tenancy, not a vendor-hosted API endpoint, so L rather than N. It is not P because no physical or administrative action by ABC is required for a support engineer to reach logs and traces.
AC Compulsion Complexity	L	H	agent · override	OVERRIDE of the questionnaire's H. The prior (customer-managed encryption keys, data-residency carve-outs, contractual access restrictions) describes barriers to the primary data-processing dependency. For 5.3 support/debugging access those barriers largely do not bite: (a) the taxonomy itself notes this path is 'usually covered by a generic support access clause in vendor terms', i.e. a standard ToS clause already suffices — the rubric's definition of L; (b) telemetry, logs and traces are typically operational data generated and held on the vendor-managed control plane, not the CMEK-wrapped payload store, so customer-managed keys do not gate them; (c) Google's Sovereign Controls documentation markets 'Technical support access is limited by underlying data access controls and routed to persons meeting specific criteria' and access approval 'permitted only under predefined conditions' as additional, purchased sovereignty features — which establishes that in the baseline configuration ABC describes, support access is not so constrained. Unless ABC has bought an access-transparency/approval product (nothing in the scenario says it has), no technical or contractual hurdle must be overcome first.
AT Trigger Conditions	N	N	agent	Confirmed, with a noted counter-argument. ABC reports the control is exercisable 'at its discretion, at any time (standing right under the contract)', which maps to N. Support access clauses are standing grants: the vendor does not need a sanctions designation, litigation hold or regulatory event to invoke them, and support tunnels/telemetry pipelines are persistently available rather than stood up per case. The arguable case for P is that debugging access is nominally incident-driven; however the incident can be vendor-detected and vendor-initiated (proactive troubleshooting, alert triage), so no external triggering condition outside the vendor's own control is required. Confidence reduced to reflect this ambiguity, and because the organisation holds no access-approval gate that would make a ticket a hard precondition (Google Sovereign Controls shows such gating is an add-on, not a default).
PR Position Required	N	N	agent	Confirmed. ABC answered that 'any party already in the subprocessor chain' can exercise the control, which is the rubric's N. This is especially apt for 5.3: first-line and escalation support is routinely delivered by outsourced or affiliated support organisations and contractor staff listed as subprocessors, who inherit the same standing under the generic support access clause as the primary contracted vendor. No compromise of ABC's own administrative credentials is needed (ruling out H), and standing is not restricted to the prime contractor (ruling out L). Google's sovereign offering explicitly advertises routing support 'to persons meeting specific criteria' as a differentiator, confirming that in the default case the pool of personnel with standing is broad.
UI Org Action Required	P	P	agent	Confirmed. ABC answered that 'ordinary use of the service is enough to trigger it', matching the rubric's P ('routine, ordinary use of the service triggers the exposure'). Ordinary use of the augmentation service is what generates the prompts, logs and traces that a support engineer would read; ABC need take no affirmative step such as opting into a feature or accepting an update (ruling out A), and the exposure is not a unilateral vendor change made independent of ABC's use such as a silent model swap or ToS change (ruling out N) — it is the by-product of ABC operating the service normally.
VC Primary Dependency Impact -- Confidentiality	L	L	agent	CONFIRMED. The rubric itself scopes dimension 5.3 (Support/debugging access) with primary_impact_axis = ["VC"] and subsequent_impact_relevant = false, so confidentiality is the axis that carries this dimension (sovereignty_cvss_rubric_1.json). The exposure here is a support tunnel into ABC's own tenancy through which vendor/subprocessor engineers can read logs, traces and telemetry. That yields real but bounded confidentiality loss: debug artefacts are fragments, metadata and sampled payloads rather than the whole sensitive corpus, and ABC reports genuine barriers in place (customer-managed encryption keys, data-residency carve-outs, contractual access restrictions). Published sovereign-support patterns show exactly this constraint shape -- 'technical support access is limited by underlying data access controls and routed to persons meeting specific criteria', with administrative access to customer data and workloads logged and permitted only under predefined conditions, each request carrying a justification (google-cloud-sovereign-controls.md). That is partial/indirect exposure = L, not total loss. Residual upside risk noted: if trace payloads contain full prompt/response bodies for the 'sensitive business needs' workloads, the effective loss approaches H -- this is the single item most worth verifying with the vendor's support-access terms.
VI Primary Dependency Impact -- Integrity	L	H	agent · override	OVERRIDE of the questionnaire's H. The prior 'behaviour can be changed silently and materially' describes the primary dependency as a managed service/control-plane relationship; the rubric assigns silent behaviour-change integrity to the control-plane and model-update dimensions (1.3 model update/versioning, 6.4 configuration and policy management, both primary_impact_axis = ["VI"]), while 5.3 carries only VC (sovereignty_cvss_rubric_1.json). Support/debugging access is predominantly a read path into logs and traces. It is not, however, integrity-free: a support tunnel is privileged remote access to the workload, and both NYDFS 23 NYCRR 500.7 (limits on privileged accounts, remote-control protocols, and monitoring of privileged access activity) and the Access Transparency model (administrative access to customer 'data and workloads') recognise that such sessions can touch workload state and configuration, not merely read it. A support engineer could therefore alter configuration or state within the session's scope, which is partial, scoped integrity loss (L) rather than the total/near-total silent redefinition of behaviour that H denotes for this dimension.
VA Primary Dependency Impact -- Availability	N	N	agent	CONFIRMED. A support/debugging access path is not a capability-withdrawal mechanism: the vendor reading logs and traces through a support tunnel does not remove ABC's ability to run the component, and ABC states it could keep operating this component ('None: we could keep operating this component'). This matches the rubric, which lists no availability axis for 5.3 and reserves availability/withdrawal effects for the control-plane and gateway dimensions (6.1, 6.3) and for model-custody (1.2) (sovereignty_cvss_rubric_1.json). Any outage caused incidentally during a debug session would be transient operational noise, not a sovereignty-driven loss of the dependency itself.
SC Downstream Blast-Radius Impact -- Confidentiality	L	L	agent	Confirmed. Dimension 5.3 is marked subsequent_impact_relevant: false in the rubric, so downstream confidentiality is not the characteristic harm of support/debugging access. However, two scenario facts justify a non-zero value: the questionnaire states many or all AI workloads depend on this shared component (gateway/control-plane-like), and any party already in the subprocessor chain has standing to use the support path. Logs and traces retrieved through a support tunnel into ABC's own tenancy therefore contain fragments, identifiers and metadata originating in systems and counterparties beyond the OpenAI dependency itself. MITRE ATLAS AML.T0047 confirms that indirect service-level access reveals model and inference details 'in logs or metadata' - i.e. partial/indirect exposure, not bulk disclosure. This matches the questionnaire's own 'Partial' answer for beyond-dependency confidentiality and the L definition (partial or limited loss).
SI Downstream Blast-Radius Impact -- Integrity	L	H	agent · override	Override of prior H. The H prior ('downstream systems act on altered outputs without detection') describes the PRIMARY dependency - the OpenAI managed service, where a silent model-version or behaviour change propagates to every downstream consumer. The rubric assigns that mechanism to dimension 1.3 ('Every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact'), not to 5.3. For 5.3 the rubric lists primary_impact_axis as ['VC'] only, with subsequent_impact_relevant: false: support/debugging access is a read-oriented, incident-scoped human access path. Google Cloud's sovereign-controls documentation further describes technical support access as justification-bound, logged and auditable, which is inconsistent with silent, material, total downstream behavioural change. L rather than N is retained because a support engineer operating in a live tenancy during remediation can in practice touch configuration or restart components, so some bounded alteration of outputs that downstream workloads consume is credible.
SA Downstream Blast-Radius Impact -- Availability	N	L	agent · override	Override of prior L. There is no availability loss at the dependency to propagate: the questionnaire answers 'None: we could keep operating this component' for withdrawal/degradation at the dependency itself, and exit is rated reconstitutable with no loss (exported weights, portable data, standard interfaces). Support/debugging access is an inbound access path, not a capability-withdrawal lever - the rubric reserves subsequent-availability reasoning for dimensions where it annotates it explicitly (6.1 admin console, 6.3 'A gateway outage takes down access to the underlying service -- Subsequent Availability'), whereas 5.3 carries primary_impact_axis ['VC'] and subsequent_impact_relevant: false. S (Safety) is inapplicable: the scenario is augmentation of sensitive business needs with no physical process, actuation or safety-relevant failure mode described.
E Precedent Maturity	P	P	agent	CONFIRMED at Proof-of-Concept. The rubric defines E:P as 'demonstrated in research/incident reports, not confirmed against this org's own stack' (sovereignty_cvss_rubric_1.json, threat metric group). For 5.3 Support/debugging access the closest documented precedent in the corpus is ATLAS AML.CS0060 (Lenovo 'Lena'), explicitly typed 'Exercise -> CASE Precedent Maturity E:P', in which researchers reached a human support agent's workflow: opening the customer chat transcript rendered a stored payload and exfiltrated the agent's session cookie, which 'could potentially access Lenovo's customer support platform as that agent and view customer conversations'. That is a demonstrated-but-not-realised instance of the support/debug access path being turned into a confidentiality exposure. The ATLAS README fixes the mapping CASE uses: 'Realized / Incident -> E:A, Demonstrated / Exercise -> E:P, Feasible -> E:U'; no Incident-typed case study for vendor support-tunnel access against a comparable organisation was returned, so E:A is not documentarily supported. Separately, Google Cloud Sovereign Controls shows that provider-side technical support access to customer data is a real, routinely exercised path (hence Access Transparency / Access Approval logging and justification requirements), which corroborates that this is more than theoretical and rules out E:U. Scenario-specific: ABC runs the workload in its own tenancy/premises but the vendor retains a managed-service telemetry/support tunnel, and the questionnaire itself answers 'Demonstrated in research or incident reports, not confirmed against our stack' - nothing indicates OpenAI support access has actually been exercised against ABC's stack. Note 5.3 is a secondary category here (the questionnaire describes the primary dependency), and the taxonomy records gap_severity High with 'existing_standard: None identified' for 5.3, i.e. this path is under-instrumented, so an absence of confirmed exercise against ABC is weak evidence either way - P is the correct middle value and confidence is moderate rather than high.
CR Confidentiality Criticality (org context)	M	M	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
IR Integrity Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
AR Availability Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
S Regulatory Consequence	P	P	agent	Confirmed. 5.3 concerns vendor support engineers reaching logs and traces inside ABC's own tenancy, which ABC uses for 'sensitive business needs'. Unauthorised or undocumented processor/subprocessor access to that content is independently reportable: GDPR Art. 28 requires that any processing by a processor or sub-processor rest on documented instructions and authorisation, and an access event outside those bounds is a personal-data breach in its own right. The EU AI Act material retrieved also imposes standalone deployer documentation and serious-incident reporting duties (reports within fixed deadlines, immediately for widespread infringement). The questionnaire answer 'Yes' to an independent reportable violation is therefore consistent with this dimension and not merely an artefact of the primary dependency.
AU Silent/Automatic Trigger	N	Y	agent · override	OVERRIDE of the prior Y. The prior reflects the primary dependency (terms/model/hosting changes that a vendor can push to its whole fleet at once). Dimension 5.3 is different in kind: a support engineer opens a tunnel or reads traces to debug one named customer's ticket. The rubric reserves N for events that 'require a discrete, case-by-case action', and Google Cloud's Sovereign Controls documentation describes exactly that shape for support access — access 'routed to persons meeting specific criteria', 'permitted only under predefined conditions', with 'every request [coming] with a justification'. A single support session cannot materialise simultaneously across all of a vendor's customers without a per-case decision. The standing contractual right is always-available (captured in AT/UI on the exploitability side), but the loss event itself is per-incident, so AU=N.
R Portability / Exit Recovery	U	A	agent · override	OVERRIDE of the prior A, which was answered about the primary dependency's portable artefacts ('exported weights, portable data, standard interfaces'). ABC does host its own resources, so the workload itself survives vendor exit — this is clearly not Irrecoverable. But the capability at stake in 5.3 is managed-service support and debugging: vendor-side telemetry, trace tooling and engineer expertise for a closed third-party model service. Reconstituting that elsewhere means standing up in-house observability and debugging runbooks or re-contracting with another provider — manual migration effort, i.e. R=U rather than 'no loss'. This also keeps the group internally consistent: the organisation's own RE answer is 'a project, but no re-architecture', which is incompatible with a frictionless A.
V Blast-Radius Concentration	C	C	agent	Confirmed. The questionnaire states 'Many or all: shared control plane, gateway, identity or embedding store' depend on this component, and the deployment answer places the vendor-reachable support/telemetry path inside ABC's own tenancy. A support tunnel and the telemetry pipeline that feeds it are not scoped to one narrow workload: they aggregate logs and traces across every AI workload routed through that tenancy, which is precisely the rubric's 'critical path for many/all AI workloads (e.g., shared control plane)'. The downstream answers (partial confidentiality loss beyond the dependency, full downstream integrity alteration, some downstream workloads degrading) corroborate a concentrated rather than diffuse blast radius.
RE Exit / Mitigation Effort	M	M	agent	Confirmed. Mitigation here does not require re-architecture (ABC already runs in its own tenancy and holds customer-managed keys and residency carve-outs), but it is more than trivial. Closing or constraining a support path means re-contracting the generic support-access clause, enabling access-approval/justification and access-transparency equivalents, scrubbing or tokenising sensitive content out of logs and traces, and periodically reviewing and disabling remote-control protocols as NYDFS 23 NYCRR 500.7 requires. Google Cloud's Sovereign Controls shows these controls exist as purchasable/configurable capability rather than as a default, so the fix is a scoped project — RE=M.
U Vendor Notice Posture	Amber	Amber	agent	Confirmed, with a caveat. The questionnaire reports disclosure 'at the time the change takes effect', which is Amber by definition. For support access specifically the best available industry practice is contemporaneous or retrospective transparency — Google Cloud logs and audits administrative access to customer data and attaches a justification to each request — not advance notice; and the classifier notes that this path is 'usually covered by a generic support access clause in vendor terms, never specifically assessed'. ABC holds no contractually guaranteed advance-notice right (which would be Clear), and no advance window (Green) is evidenced. Red would require that the vendor never disclose before changes take effect; since disclosure is reported as concurrent, Amber is the correct value, though Red is the adjacent risk if access-transparency logging is absent for this service and ABC only learns of support sessions after the fact.

6 Who's holding the steering wheel?

6.1 Centralized control plane / admin console · also 6.4, 6.3

HIGH8.8

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.

Evidence: vector, score and 21 metric rationales

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)

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?

Metric	Value	Prior	Source	Rationale
AV Access Path	N	L	agent · override	Override L→N. The questionnaire's 'own tenancy, vendor-reachable' answer describes ABC's self-housed resources (the primary dependency), not this category's asset. Dimension 6.1 is the administrative console 'where the organization's own administrators configure and view usage' — for ABC that is the OpenAI platform console and its project/API-key configuration surface, which is a vendor-operated multi-tenant SaaS web/API surface reached over the public network with no intermediary, and per the rubric it is 'frequently hosted in a different jurisdiction than the inference infrastructure itself'. ATLAS documents that SaaS/agentic platforms expose provider control-plane and identity APIs returning tenant, project and deployment information (AML.T0006.001), and that LLM/SaaS platform control surfaces are routinely network-discoverable (AML.T0132). Nothing in the scenario indicates a self-hosted or customer-deployed admin console, so Access Path = Network (vendor-direct).
AC Compulsion Complexity	L	H	agent · override	Override H→L. The barriers ABC reported (customer-managed encryption keys, data-residency carve-outs, contractual access restrictions) protect payload data resident in ABC's own tenancy; they do not sit between OpenAI and OpenAI's own administrative/control plane. Project configuration, key metadata, usage and billing telemetry, org membership and policy settings live on the vendor side by construction, so the platform operator (or a legal process served on it) needs only its standing ToS/operator rights — no technical barrier to overcome. Rubric L = 'a standard ToS clause or routine legal process suffices'. Confidence is moderate because the scenario does not describe the admin surface or any contractual carve-out covering console metadata.
AT Trigger Conditions	N	N	agent	Confirm N. ABC reports the control is exercisable 'at its discretion, at any time (standing right under the contract)'. Console-side administration — changing defaults, policy, routing, visibility, or terms — needs no sanctions designation, litigation hold or incident to trigger it. Rubric N = 'control can be exercised at vendor discretion at any time'.
PR Position Required	N	N	agent	Confirm N. The redefined actor for this framework is the vendor, a subprocessor, or a compelling authority — not an external attacker — so the 'H' reading (compromising ABC's own admin credentials) is not required: the console is the vendor's own product, and the hosting, identity and logging subprocessors in OpenAI's chain already sit inside the console's trust boundary with standing to read configuration and usage state. This matches ABC's answer that 'any party already in the subprocessor chain' can exercise the control. Confidence is only moderate because an argument exists for L (only the primary contracted vendor can actually mutate guardrail/routing policy), and the scenario gives no detail on OpenAI's console subprocessor chain.
UI Org Action Required	N	P	agent · override	Override P→N. The passive reading is defensible for telemetry (ordinary API use populates console usage data), but the dominant exposure at 6.1 is unilateral vendor action: ABC reports that behaviour 'can be changed silently and materially', that downstream systems 'act on altered outputs without detection', and that sovereignty-relevant changes are only 'disclosed at the time the change takes effect' (rubric U = Amber). Platform-side changes to console defaults, model routing, policy settings or terms therefore require no affirmative act by ABC, which is exactly rubric UI = N ('vendor/subprocessor can act unilaterally — silent model swap, ToS change, silently added AI feature'). Noted overlap with 6.4 (who can change guardrail/routing policy without the org's knowledge); confidence is moderate because the scenario does not describe the admin surface directly.
VC Primary Dependency Impact -- Confidentiality	L	L	agent	CONFIRM prior L. For dimension 6.1 the 'vulnerable system' is the administrative console/control plane itself (the OpenAI platform console where ABC's own admins configure projects, keys, members and view usage), not the inference data path. What is concentrated there is administrative and usage metadata: project/org structure, member identities, key metadata, spend and usage telemetry, and configuration state — i.e. 'limited or indirect exposure (metadata, fragments, aggregates)' as ABC itself answered. The sensitive business content ABC sends to OpenAI traverses the API data plane (covered by categories 2/3), and ABC reports real barriers (customer-managed keys, residency carve-outs, contractual access restrictions) against vendor/subprocessor reading of payload data. ATLAS evidence shows control interfaces are a real confidentiality target (AML.CS0048: exposed control dashboards yielding plaintext API keys and credentials; AML.T0132 misconfigured/exposed AI services), which justifies a non-zero value, but for a vendor-hosted console under contractual constraint the loss is partial rather than total. Hence L, not H or N.
VI Primary Dependency Impact -- Integrity	H	H	agent	CONFIRM prior H. The console is the authoritative configuration surface for ABC's AI use: model aliases/versions, project and key scoping, routing and guardrail/policy defaults. ABC reports that behaviour 'can be changed silently and materially', that the vendor holds a standing discretionary right exercisable at any time, that any party already in the subprocessor chain can exercise it, that ordinary use is enough to trigger it, and that sovereignty-relevant changes are 'disclosed at the time the change takes effect' — i.e. no advance notice and no opportunity to validate. When the party that controls the control plane can rewrite the authoritative configuration state without ABC's prior knowledge, the integrity loss at that component is total rather than partial, so H. Corpus support: the rubric's companion dimension 1.3 notes an un-notified behaviour change is 'textbook' integrity impact; ATLAS AML.T0081 documents modification/disabling of configuration and security settings as a recognised technique, and AML.CS0064 shows configuration-layer (non-weight) changes silently altering model behaviour. Note the rubric assigns 6.1 'primary_impact_axis: []' with the weight in Subsequent scope, so this primary integrity value should be read alongside the downstream (SI) finding rather than as the whole story.
VA Primary Dependency Impact -- Availability	L	N	agent · override	OVERRIDE N -> L. The prior 'None: we could keep operating this component' was answered about the primary dependency (OpenAI inference, which ABC can keep consuming from its own tenancy and can reconstitute elsewhere, R=A). But the component assessed here is the console itself, and the rubric for 6.1 explicitly contemplates that 'a console compromise or OUTAGE affects every downstream AI workload the org runs' — availability of the administrative surface is in scope by definition. If the console or admin access is unavailable or restricted (vendor-side outage, account/org suspension, or discretionary throttling of admin rights, which ABC says is exercisable at any time and could hit all customers at once with no case-by-case decision), ABC loses exactly the functions this dimension names: key rotation and revocation, project/member configuration, guardrail and routing policy changes, and usage visibility — which also impairs the audit/monitoring evidence ABC needs for the regulatory violation it flags. That is a real but partial loss: existing API keys keep serving inference and ABC's own housed resources continue to operate, so this is not total. Hence L rather than N (and not H). Confidence is moderate because the scenario does not describe ABC's admin surface or any admin-side SLA directly, and the rubric places 6.1's main weight in Subsequent availability (SA) rather than on the vulnerable system.
SC Downstream Blast-Radius Impact -- Confidentiality	L	L	agent	Confirming the prior. For dimension 6.1 the asset is ABC's OpenAI platform console / project-and-key configuration, not ABC's own data stores — ABC 'uses and houses its own resources'. What a console compromise or vendor-side console-level access yields downstream is primarily metadata and key material: project/org structure, usage and spend telemetry, model/endpoint configuration, and issuable API credentials. That matches the questionnaire's own reading at both levels ('Partial: limited or indirect exposure (metadata, fragments, aggregates)' at the dependency; 'Partial' beyond it), and the stated barriers (customer-managed keys, residency carve-outs, contractual access restrictions) blunt a direct read of the sensitive business content itself. Note the countervailing argument: because many or all AI workloads share this control plane (rubric 6.1 supplemental hook V = Concentrated), minted credentials could expose prompt traffic for sensitive business needs across the estate — that breadth is captured by V and by the Primary metrics rather than by raising SC to 'total loss'. Held at L with moderate confidence because the scenario does not describe the admin surface or whether request logging is enabled.
SI Downstream Blast-Radius Impact -- Integrity	H	H	agent	Confirming the prior, and this is the axis that carries the group. The console is where project configuration, model/version selection, routing and guardrail settings are set; the rubric records 6.1 as 'pure Subsequent scope' where 'a console compromise or outage affects every downstream AI workload the org runs', and the parallel notes at 1.3 and 6.4 state that 'every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact'. The questionnaire corroborates a total loss on this axis: behaviour 'can be changed silently and materially' at the dependency and 'downstream systems act on altered outputs without detection' beyond it, with changes 'disclosed at the time the change takes effect' (no prior notice) and exercisable 'at any time' by 'any party already in the subprocessor chain'. MITRE ATLAS AML.T0081 (Modify AI Agent Configuration, maturity Demonstrated, anchored to CASE dimension 6.4) documents precedent that configuration-level changes persist and 'affect any agents that share the configuration' — redirecting outputs or tools and weakening controls. With ABC routing sensitive business work through this single shared configuration chokepoint, integrity loss downstream is near-total: H.
SA Downstream Blast-Radius Impact -- Availability	L	L	agent	Confirming the prior. A console outage or lockout is largely decoupled from the inference data plane (the rubric separates that concern into 6.3, where 'a gateway outage takes down access to the underlying service'), so the realistic effect of losing 6.1 is inability to rotate keys, change configuration or view usage, plus whatever workloads break on credential revocation — the questionnaire's 'Some downstream workloads degrade'. ABC's posture limits this further: it 'uses and houses its own resources' with OpenAI only augmenting, availability loss at the dependency itself is answered 'None: we could keep operating this component', and the capability is reconstitutable elsewhere with no loss (portable interfaces). Partial, not total: L. Not S — the scenario describes sensitive business augmentation with no cyber-physical, clinical or otherwise safety-relevant downstream actor, so no credible path to physical harm.
E Precedent Maturity	A	P	agent · override	OVERRIDE of the questionnaire's P. The respondent answered 'demonstrated in research or incident reports, not confirmed against our stack', but the rubric's A threshold is not 'confirmed against this org's stack' — it is 'documented real-world cases of this control being exercised against comparable orgs'. The corpus supplies two ATLAS entries typed as Incident (not Exercise), both explicitly mapped to 'CASE Precedent Maturity E:A', that target precisely the 6.1 surface — the administrative/credential/config plane of a hosted frontier-model service used by ordinary customer organizations: (1) AML.CS0030 LLM Jacking (Sysdig, 2024-05-06), where stolen credentials gave adversaries access to victims' cloud-hosted LLM resources, with tooling covering OpenAI/Azure/Bedrock/Vertex and explicit interrogation of the configuration plane (GetModelInvocationLoggingConfiguration) to determine whether prompt logging was enabled so the abuse would stay invisible to the customer — i.e. the console/config chokepoint was actually exercised, producing silent behaviour change plus financial and capacity degradation across every workload on the account; (2) AML.CS0057 Storm-2139 (Microsoft, 2024-12), where actors scraped exposed customer credentials from public sources, entered valid customer accounts for a generative-AI service, and 'modified service capabilities' and bypassed guardrails — a documented instance of a third party silently altering guardrail/routing behaviour inside real tenants, which is the same silent-change finding the questionnaire reports here ('behaviour can be changed silently and materially'; 'downstream systems act on altered outputs without detection'). AML.CS0023 further confirms OpenAI platform tokens are harvested in the wild alongside other platform keys, and AML.T0012 (Valid Accounts) is the shared technique across these incidents. ABC is squarely a comparable org: an enterprise running its own resources while routing sensitive business workloads through the OpenAI platform, whose console and key/project configuration is the single concentrated administrative chokepoint for many or all of its AI workloads. Confidence is 0.75 rather than higher because the scenario does not describe ABC's admin surface, MFA/SSO posture or key-hygiene controls directly, and the cited incidents involve credential exposure by the customer rather than compromise of the provider console itself — but the precedent for this control being exercised against peers is real-world and repeated, not theoretical, so U is clearly wrong and P understates the record.
CR Confidentiality Criticality (org context)	M	M	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
IR Integrity Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
AR Availability Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
S Regulatory Consequence	P	P	agent	Confirmed. The admin console is where ABC configures and views usage of a service handling 'sensitive business needs', so it concentrates prompt/usage metadata and audit telemetry. The Microsoft EU Data Boundary source establishes that system-generated usage and user-activity logs of this kind contain personal data under GDPR Art. 4(5); loss of control over the console therefore independently implicates GDPR Art. 28(3) (processing outside documented controller instructions) and Art. 28(2) (subprocessor authorisation), and the rubric notes such consoles are frequently hosted in a different jurisdiction than the inference infrastructure, adding an independent Chapter V transfer trigger. EU AI Act Art. 26 further places log-retention and monitoring duties on the deployer 'to the extent such logs are under their control', and a console compromise or silent reconfiguration defeats exactly that control. The questionnaire also answers 'Yes' to the independent reportable-violation question.
AU Silent/Automatic Trigger	Y	Y	agent	Confirmed. Sovereignty-relevant changes at a multi-tenant SaaS control plane — terms-of-service revisions, default routing or guardrail policy changes, subprocessor additions, console feature rollouts, model deprecations — are deployed platform-wide to every tenant at once with no per-customer decision, which is precisely the rubric's definition of AU=Y ('can occur simultaneously across all customers with no case-by-case decision'). This is consistent with the questionnaire's answers that the control is exercisable 'at its discretion, at any time', that 'ordinary use of the service is enough to trigger it', and that behaviour 'can be changed silently and materially'. ATLAS AML.T0081 documents configuration/security-setting changes as a demonstrated technique for achieving long-term, undetected behavioural change.
R Portability / Exit Recovery	U	A	agent · override	OVERRIDE of the prior A. The questionnaire's justification for 'no loss' — 'exported weights, portable data, standard interfaces' — is a model-layer answer (the rubric assigns R's primary hook to 1.2 Model weight custody), not a statement about the control plane. The console's own state is not exportable: project and organisation structure, API keys and their scoping, rate-limit and spend configuration, routing/guardrail policy settings, member/role assignments and the historical usage and audit record are vendor-proprietary and have no standard export or import path. Reconstituting the administrative capability elsewhere (self-hosted gateway, own key vault, own usage observability) is achievable because ABC already houses its own resources, but it requires deliberate manual re-provisioning and historical audit data is not recovered — the rubric's R=U, 'manual migration effort required'. ATLAS AML.T0002.002/AML.T0083 illustrate that this configuration state (system prompts, tool config, credentials) is a distinct, platform-specific artefact rather than portable data.
V Blast-Radius Concentration	C	C	agent	Confirmed, and this is the metric that carries the category. The rubric lists V (Value Density — Concentrated) as 6.1's explicit supplemental hook and notes that 'a console compromise or outage affects every downstream AI workload the org runs -- pure Subsequent scope'. The questionnaire states that 'many or all' of ABC's AI workloads depend on this component as a shared control plane/gateway/identity surface, and the subsequent-scope answers (downstream integrity 'Full: downstream systems act on altered outputs without detection', some downstream workloads degrade) confirm the dependency sits in the critical path of multiple workloads rather than one narrow one. ATLAS AML.T0040 reinforces the shared-fate logic: many systems relying on the same provider-mediated surface 'share the same vulnerabilities'.
RE Exit / Mitigation Effort	M	M	agent	Confirmed at Moderate. ABC 'uses and houses its own resources' and uses OpenAI only to augment, so the mitigation path — interposing an organisation-controlled gateway/broker, moving to customer-managed keys, and duplicating console configuration and usage logging into ABC's own observability stack — is a scoped project using standard interfaces rather than a re-architecture or physical infrastructure replacement (rubric RE=H). It is more than trivial (rubric RE=L) because V=C means every dependent workload must be re-pointed and the vendor-specific console state identified in the R rationale must be re-created by hand. Confidence is moderate because the scenario does not describe the admin surface directly, and if ABC has no existing abstraction layer in front of its AI workloads the effort could tip toward H.
U Vendor Notice Posture	Amber	Amber	agent	Confirmed. The questionnaire reports that sovereignty-relevant changes (model versions, subprocessors, hosting, terms) are 'disclosed at the time the change takes effect', which is the rubric's definition of Amber ('vendor discloses concurrently with the change taking effect'). The corpus returned no evidence of a contractually guaranteed advance-notice commitment for this platform, so Green or Clear is unsupported. Red was considered because the questionnaire records that behaviour 'can be changed silently and materially' and because dimension 6.4 (guardrail/routing policy changed without the organisation's knowledge) overlaps here; it was not selected because the finding is about absence of advance warning rather than total non-disclosure — platform changelog and subprocessor-list publication is concurrent, not absent. Confidence is moderate given that overlap: if review establishes that console-side policy or routing changes are never published at all, this should move to Red.

7 How many companies are really in this chain: and did we agree to it?

7.1 Downstream subprocessors · also 7.3

HIGH8.2

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.

Evidence: vector, score and 21 metric rationales

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)

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?

Metric	Value	Prior	Source	Rationale
AV Access Path	A	L	agent · override	Override of prior L. The prior describes the PRIMARY dependency correctly: ABC houses resources in its own tenancy/premises and OpenAI retains reach via managed service, telemetry and support tunnel. But dimension 7.1 is about the downstream subprocessor chain, where the rubric offers an exact match: A = 'Adjacent -- subprocessor-mediated access'. ABC has no direct relationship with any sub-tier party; those parties reach ABC's data only through the OpenAI hop, and ABC reaches them not at all. The interagency TPRM guidance characterises exactly this structure as risk arising from 'the absence of a direct relationship between the banking organization and the subcontractor, further lessening the banking organization's direct control of activities.' ABC's own-premises posture does not reduce this access path, because the data at issue has already left ABC's environment to serve the OpenAI augmentation call. Not N (that is vendor-direct API access with no intermediary, which describes 7.3/the primary relationship, not the chain); not L (sub-tier parties are not resident in ABC's managed environment); not P (nothing is air-gapped).
AC Compulsion Complexity	L	H	agent · override	Override of prior H. ABC's stated barriers -- customer-managed encryption keys, data-residency carve-outs, contractual access restrictions -- are genuine, but they are enforceable against OpenAI as the contracted counterparty; they do not flow through to sub-tier parties whose identity ABC does not control. For this dimension the relevant question is what must be overcome to change chain composition or let a new chain member handle ABC data, and the answers show the answer is 'nothing': sovereignty-relevant changes including subprocessors are 'disclosed at the time the change takes effect', so a standard DPA/ToS subprocessor-substitution clause suffices. The interagency guidance treats customer notification of 'intent to use a subcontractor', the right to prohibit specific subcontractors, and a bar on 'subcontracting of the third party's obligations to another entity without the banking organization's consent' as controls that must be negotiated in; ABC evidences none of them, so no contractual barrier stands in the way. Hence L, not H.
AT Trigger Conditions	N	N	agent	Confirms prior. The control is a 'standing right under the contract' exercisable 'at its discretion, at any time', and subprocessor changes are disclosed only when they take effect -- no sanctions designation, litigation hold or incident is needed to trigger a change in chain composition. This holds for the chain as well as the primary vendor, since the chain is reconfigured at vendor discretion. N (no triggering event required).
PR Position Required	N	N	agent	Confirms prior, and this is the single strongest signal for the category. The answer 'any party already in the subprocessor chain' is verbatim the rubric's N definition ('None -- any party already in the subprocessor chain has sufficient standing'). No sub-tier party needs to be the primary contracted vendor (L) and none needs to compromise ABC's administrative credentials (H); standing inside the chain is itself sufficient position. This is why 7.1 carries the category: the privilege boundary ABC relies on stops at OpenAI, while the set of parties holding sufficient standing extends through the full chain.
UI Org Action Required	N	P	agent · override	Override of prior P. The prior is defensible on its own terms -- ordinary use of the OpenAI augmentation is what puts ABC data in front of the chain. But the rubric distinguishes the exposure's materialisation from the control act, and lists 'ToS change' explicitly under N ('vendor/subprocessor can act unilaterally'). Adding or substituting a downstream subprocessor requires no affirmative act, opt-in, consent or acceptance by ABC, and ABC learns of it only at the moment it takes effect; ABC's governance never touches the decision. This is corroborated by the answers that behaviour 'can be changed silently and materially' and that downstream systems 'act on altered outputs without detection' -- silent and undetected change is incompatible with an org-action-gated exposure. Confidence is moderate because the P reading (routine use triggers it) remains a reasonable alternative; the deciding factor is that chain composition is set unilaterally.
VC Primary Dependency Impact -- Confidentiality	L	L	agent	CONFIRM L. For this category the exposure is the composition of the subprocessor chain, which can be changed by 'any party already in the subprocessor chain' at its discretion with disclosure only 'at the time the change takes effect'. At the named dependency itself this yields partial, indirect confidentiality loss rather than total loss: ABC houses its own resources and has 'real barriers' in place (customer-managed encryption keys, data-residency carve-outs, contractual access restrictions), so an added or substituted subprocessor is positioned to see metadata, fragments and telemetry rather than the plaintext corpus. It is not N because the vendor can still reach ABC's tenancy via the managed service, telemetry and support tunnel, and per the Microsoft EU Data Boundary documentation system-generated logs are produced and transferred continuously even under residency commitments — ordinary use of the service is enough to trigger the pathway. The bulk of the chain's confidentiality exposure lands on parties other than the contracted vendor and is therefore carried by the subsequent-impact group, consistent with the rubric's empty primary_impact_axis for 7.1.
VI Primary Dependency Impact -- Integrity	L	H	agent · override	OVERRIDE H -> L. The prior 'Full: behaviour can be changed silently and materially' is a true statement about ABC's primary dependency, but the rubric assigns that total primary-integrity loss to the model layer (dimension 1.3 'Model update / versioning control', primary_impact_axis ['VI']), whereas dimension 7.1 is recorded with primary_impact_axis [] and the note that it 'is definitionally what the Subsequent System Impact metric group was built to express'; the rubric further states the subsequent group 'maps almost one-to-one onto this taxonomy's Category 7 ... finding that sovereignty exposure compounds across the entire subprocessor chain rather than stopping at the primary vendor'. Assessed on its own terms, an un-notified change of chain composition degrades ABC's integrity assurance over part of the processing path — the mechanism is realized in ATLAS AML.T0109 (rug pull: a vetted component is swapped after adoption, bypassing onboarding scrutiny, as in AML.CS0053) and AML.T0010 — but it does not hand a subprocessor total control over the outputs ABC consumes at the primary dependency: the contracted service, customer-managed keys and contractual access restrictions remain in force, and the EU AI Act value-chain provisions (Recitals 88-90) frame downstream suppliers as shaping, not wholly determining, the integrated system's behaviour. Partial loss (L) at the primary dependency is therefore the defensible reading, with the full silent-alteration effect expressed through the downstream blast-radius metrics, matching the questionnaire's own 'Full: downstream systems act on altered outputs without detection'. Confidence is moderate because the questionnaire's direct answer for this axis was H and a reviewer who treats chain substitution as equivalent to a silent model swap could justify H.
VA Primary Dependency Impact -- Availability	N	N	agent	CONFIRM N. A change in downstream subprocessor composition is not a withdrawal of the capability: the questionnaire states the component could keep operating ('None: we could keep operating this component'), ABC houses its own resources, and the capability is reconstitutable elsewhere 'with no loss: exported weights, portable data, standard interfaces' with only moderate exit effort. The availability consequences reported ('some downstream workloads degrade') are explicitly beyond this dependency and belong to the subsequent-impact group, which is where the rubric places 7.1's effects (primary_impact_axis []). No retrieved source indicates that subprocessor substitution denies service at the primary dependency itself, so N rather than L.
SC Downstream Blast-Radius Impact -- Confidentiality	L	L	agent	CONFIRM prior. For 7.1 the relevant question is how much confidentiality is lost at parties beyond OpenAI itself. ABC answered 'Partial' for beyond-dependency confidentiality, consistent with its answer that loss at the dependency is itself only partial ('metadata, fragments, aggregates'). Downstream subprocessors can at most inherit what OpenAI holds, and ABC retains customer-managed encryption keys, data-residency carve-outs and contractual access restrictions — exactly the barriers the rubric treats as raising Compulsion Complexity (AC:H) and therefore bounding chain-mediated disclosure. Breadth of parties in the chain (PR:N — 'any party already in the subprocessor chain has sufficient standing') widens who could see data, but the rubric scores this axis on magnitude of loss, not count of recipients, so near-total loss (H) is not supported. Sensitive business content does transit the chain and prompts/outputs routed to subprocessors are a recognised Subsequent Confidentiality path, so N is ruled out.
SI Downstream Blast-Radius Impact -- Integrity	H	H	agent	CONFIRM prior, and it is the axis that drives this category. ABC answered that downstream systems 'act on altered outputs without detection' (Full), that behaviour at the dependency 'can be changed silently and materially', that change disclosure happens only 'at the time the change takes effect' (no pre-notification or consent over chain composition), that the control is exercisable at vendor/subprocessor discretion at any time, and that 'many or all' AI workloads depend on this component. The rubric's note for un-notified model/version change states that 'every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact', and the Subsequent group exists precisely to express compounding multi-hop impact across the subprocessor chain. ATLAS AML.T0010/T0115/T0011 (Realized/Demonstrated) document chain-mediated model and artifact substitution where the artifact 'may continue to work as expected from the victim's perspective', i.e. silent, undetected alteration of behaviour inherited by every downstream consumer. Combined with ABC's own answer that a loss of control here would independently trigger a reportable regulatory violation, this is near-total loss of assurance over downstream output integrity: H.
SA Downstream Blast-Radius Impact -- Availability	L	L	agent	CONFIRM prior. ABC answered that beyond the dependency 'some downstream workloads degrade' — partial, not total, loss — and that at the dependency itself availability loss is None ('we could keep operating this component'). Recoverability is strong (capability reconstitutable elsewhere 'with no loss: exported weights, portable data, standard interfaces'; exit is a 'moderate' project with no re-architecture), which caps the realistic downstream availability loss even if a subprocessor in the chain fails or is withdrawn. H is therefore not warranted despite the breadth of dependent workloads. S (Safety) is rejected: the scenario is augmentation of sensitive business needs with ABC's own resources, with no indication of a physical, cyber-physical or safety-relevant downstream function; the regulatory dimension ABC does flag is captured by the supplemental Regulatory Consequence metric (S:P), not by SA:S.
E Precedent Maturity	A	P	agent · override	OVERRIDE of the questionnaire prior P. The prior ('demonstrated in research or incident reports, not confirmed against our stack') was answered about the primary OpenAI dependency; for category 7.1 the rubric asks whether THIS control -- a party already inside the downstream subprocessor/dependency chain silently substituting or altering a component that ABC's workloads consume -- has documented real-world exercise against comparable orgs. It has. The ATLAS corpus README fixes the mapping: 'Realized / Incident -> E:A (Attacked) ... A metric agent citing an ATLAS Incident case study has documentary grounds for E:A.' AML.T0010 (AI Supply Chain Compromise), the standard the rubric itself names for Category 7, carries 'Maturity: Realized -> CASE Precedent Maturity E:A', as do AML.T0010.002 (poisoning via outsourced labeling/annotation subprocessors) and AML.T0115.001 (poisoned models). Two Incident-type (not Exercise) case studies match ABC's exposure shape almost exactly: AML.CS0053 'Poisoned Postmark MCP Server Email Exfiltration' (Incident, 2025-09) -- an actor in the chain published legitimate versions, waited for adoption, then rug-pulled a malicious version that BCC'd the entire contents of every email sent by ordinary use of the tool at victim organizations; and AML.CS0015 'Compromised PyTorch Dependency Chain' (Incident, 2022-12) -- dependency confusion in the AI software chain exfiltrating SSH keys, env vars and home-directory files from downstream users. AML.CS0068 (Incident, 2026-07) additionally shows compromise propagating from one AI provider's agents into another provider's production infrastructure, i.e. multi-hop chain impact. These are realized, reported, against organizations that, like ABC, simply consumed a component through their AI pipeline. ABC's own answers make the precedent directly applicable rather than hypothetical: standing in the chain is sufficient to act (PR:N), ordinary use of the service triggers exposure (UI:P), behaviour can be changed silently and materially with downstream systems acting on altered outputs undetected, and sovereignty-relevant changes including subprocessor changes are 'disclosed at the time the change takes effect' -- so ABC has no pre-notification or consent gate over chain composition and no window to detect a substitution before it is live. Confidence is held at 0.78 rather than higher because the cited incidents are security-actor compromises of chain participants rather than a lawful/contractual subprocessor action by an OpenAI subprocessor specifically; the E definition for A, however, requires only 'documented real-world cases of this control being exercised against comparable orgs', not confirmation against ABC's own stack (that stricter condition is what distinguishes P, and the ATLAS mapping rule resolves the overlap in favour of A for Incident-type evidence).
CR Confidentiality Criticality (org context)	M	M	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
IR Integrity Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
AR Availability Criticality (org context)	H	H	questionnaire	Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
S Regulatory Consequence	P	P	agent	Confirmed. The rubric's own definition of S anchors it to GDPR Art. 28 / EU AI Act Title III triggers. Under Art. 28(2)/(4) GDPR a processor may only engage sub-processors with the controller's authorisation and must give prior notice of intended changes so the controller can object; ABC states that sovereignty-relevant changes including subprocessors are 'disclosed at the time the change takes effect', i.e. with no pre-notification or consent window. Sensitive business data is being sent to OpenAI, so an undisclosed addition of a downstream subprocessor (or an onward transfer by one) is on its own a reportable Art. 28 / Chapter V defect for ABC as controller, independent of any security breach. The EU AI Act reinforces that value-chain parties must furnish the information needed for the deploying/providing party to meet its own obligations (Recital 88, Art. 25 responsibilities along the AI value chain) — an opaque chain undercuts that duty. P confirmed.
AU Silent/Automatic Trigger	Y	Y	agent	Confirmed. Subprocessor-chain composition is set unilaterally by the vendor for its whole customer base: when OpenAI adds, substitutes or re-locates a downstream subprocessor, the change lands on every tenant at once with no per-customer decision or trigger. The questionnaire independently records that 'ordinary use of the service is enough to trigger it' and that the control can be exercised 'at its discretion, at any time' by 'any party already in the subprocessor chain'. This is the same structural pattern the rubric flags for un-notified vendor-side changes propagating to 'every downstream consumer' (dim. 1.3 note, supplemental hook AU). Y confirmed.
R Portability / Exit Recovery	U	A	agent · override	OVERRIDE of prior A. The prior reflects the primary dependency framing (API-level use, portable data, standard interfaces, ABC's own infrastructure and resources). Assessed for this category, however, recovery from a downstream-subprocessor event is not costless: ABC does not select the chain, cannot excise a single subprocessor, and the only effective remedy is to re-contract with a different provider — whose own chain must then be re-papered (new DPA/SCCs, new subprocessor annex) and re-validated, plus prompt/eval re-tuning against a different model family. That is manual migration effort, i.e. 'U', and it is internally consistent with the organisation's own RE answer ('a project, but no re-architecture'). Not 'I', because the capability genuinely is reconstitutable: ABC houses its own resources, uses OpenAI only to augment, and the interface is a standard inference API (the rubric reserves the irrecoverable end of R for cases such as custodial model weights, dim. 1.2).
V Blast-Radius Concentration	C	C	agent	Confirmed. ABC reports that 'many or all' AI workloads depend on this component (shared control plane / gateway / identity or embedding store), so every workload inherits the same subprocessor chain — one chain member's failure or access is in the critical path for all of them. The rubric treats precisely this fan-out as Concentrated value density (dim. 6.1 supplemental hook 'V (Value Density -- Concentrated)') and describes Category 7 as the case where 'sovereignty exposure compounds across the entire subprocessor chain rather than stopping at the primary vendor'. C confirmed.
RE Exit / Mitigation Effort	M	M	agent	Confirmed, with a caveat. No re-architecture or physical infrastructure replacement is needed: ABC already houses its own resources and consumes OpenAI as an augmentation over a standard API, and real technical barriers (customer-managed keys, residency carve-outs, contractual access restrictions) are already in place, so the mitigation work is a scoped project — tighten the DPA to require prior notice/right to object on subprocessor changes, add chain-monitoring to TPRM, and keep a second provider warm. It is not 'L', because the contractual fix is not trivial: a hyperscale AI provider's standard terms rarely concede per-customer consent over chain composition, and the corpus offers only 'general TPRM practice (partial)' as an existing standard for this dimension (rubric dim. 7.1, gap severity Medium). M confirmed.
U Vendor Notice Posture	Amber	Amber	agent	Confirmed. The questionnaire states sovereignty-relevant changes — explicitly including subprocessors, hosting and terms — are 'disclosed at the time the change takes effect', which is the literal definition of Amber (concurrent disclosure). Not Red, since disclosure does occur (a maintained subprocessor page/notice); not Green/Clear, since there is no advance window and no contractually guaranteed notice period of the kind regulated regimes expect for provider changes (cf. EU AI Act Art. 36(3) one-year advance notice for ceasing bodies, NYDFS 500.17 72-hour third-party-provider notification — both illustrate that defensible postures are time-bounded commitments, which ABC does not hold here).

What ABC should do next

Written by the narrative agent from the findings and mitigations

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.

Ranked mitigations

Retrieved from the mitigation library for the adverse metrics

Relevance	Mitigation	Targets
0.92	ATLAS AML.M0008 — Validate AI Model: Validate that AI models perform as intended by testing for backdoor triggers, potential for data leakage, or adversarial influence. Monitor the AI model for concept drift and training data drift, which may indicate data tampering or poisoning. Applies to acquired/third-party models (AML.T0010.003) and to manipulation or architecture modification of deployed models (AML.T0018, AML.T0018.000/.001).Continuous behavioural validation and drift monitoring of each model version is the most direct detective control against vendor-pushed, silently-applied model updates that alter integrity (dimension 1.3).	VISIAUATE
0.89	ATLAS AML.M0013 — Code Signing: Enforce cryptographic signing of model files, ML software frameworks and artifacts, and cryptographically sign SBOM/AIBOM components that track model or data provenance. Prevent execution of ML artifacts that are not properly signed, guaranteeing that a model or package has not been manipulated after signing (AML.T0010.001/.003, AML.T0011.000/.001, AML.T0018.000/.001/.002).Signature enforcement on model and framework artifacts means an upstream version change cannot take effect without a verifiable, attributable approval step, raising compulsion complexity and removing silent substitution.	VISIAUACAT
0.84	ATLAS AML.M0014 — Verify AI Artifacts: Verify the cryptographic checksum of all AI artifacts to confirm the file was not modified by an attacker, introducing proper signature checking so unsafe models, data or artifacts are not introduced into or executed by the system (AML.T0002.001, AML.T0010, AML.T0010.002, AML.T0011, AML.T0011.000).Checksum/signature verification at ingest gives the organization a pinning and integrity gate over which model version actually reaches production, directly countering unannounced upstream change.	VISIAUAC
0.83	ATLAS AML.M0023 — Maintain AI Bill of Materials (AI BOM): Maintain an inventory of AI system components, including dataset provenance — a detailed history of datasets and artifacts, their sources, and a complete record of any modifications. An AI BOM helps users identify untrustworthy components of their AI supply chain (AML.T0010), untrustworthy binaries and model artifacts (AML.T0011, AML.T0011.000), and untrustworthy software dependencies (AML.T0011.001).An AI BOM is the closest available control to subprocessor transparency: it enumerates fourth-party components and model lineage so hidden downstream dependencies and their concentration become visible and auditable.	VSISEAT
0.80	ATLAS AML.M0005 — Control Access to AI Models and Data at Rest: Establish access controls on internal model registries and limit internal access to production models; limit training-data access to approved users. Restrict write access to model registries and AI artifact stores (AML.T0112.001); prevent tampering with and unauthorized modification of AI artifacts (AML.T0018, AML.T0018.000/.001); verify identities before granting access to model registries so newly established accounts cannot automatically access protected AI artifacts (AML.T0012, AML.T0021).Write-restricted registries and identity verification raise the position and privilege required to change a deployed model or artifact, mitigating both versioning control and admin-console exposure.	PRAVACVISI
0.78	ATLAS AML.M0026 — Privileged AI Agent Permissions Configuration: Where elevated privileges are granted to enable workflows, implement robust policies and controls on those permissions — Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC) and the principle of least privilege — so that only the permissions necessary for the designated task are granted, limiting an adversary's capability if the privileged component is compromised (AML.T0053, AML.T0082, AML.T0085, AML.T0086, AML.T0101).RBAC/ABAC and least privilege applied to the highly privileged centralized control plane shrinks what a single console identity can change and therefore the blast radius of its compromise or compelled use.	PRVSIACAV
0.76	ATLAS AML.M0019 — Control Access to AI Models and Data in Production: Require users to verify their identities before accessing a production model, require authentication for API endpoints, and monitor production model queries for compliance with usage policies and to prevent misuse. Authenticate and monitor access to production models and configuration interfaces (AML.T0069, AML.T0069.002); enforce authorization and monitor AI API use for anomalous activity associated with replayed access tokens (AML.T0091, AML.T0091.000); authenticate AI service API callers (AML.T0096).Authenticating and monitoring the production configuration interfaces narrows the network-reachable, no-privilege access path into the admin console and makes anomalous administrative use detectable.	AVPRACAUSI
0.75	ATLAS AML.M0024 — AI Telemetry Logging: Implement logging of inputs and outputs of deployed AI models and, for agents, of intermediate steps, decisions, data access, tool use, installation commands and agent identity. Monitoring logs helps detect security threats and mitigate impacts, and the presence of logging deters adversaries who wish to remain undetected. Log new resource discovery, denials, exceptions, approvals and scope changes.Comprehensive behavioural and administrative telemetry converts otherwise silent/automatic upstream changes into observable, evidenceable events, which also supports regulatory defensibility.	AUSSIVI
0.72	ATLAS AML.M0029 — Human In-the-Loop for AI Agent Actions: Systems should require a user or other human stakeholder to approve actions before they are taken; dedicated audit tooling may assist but final adjudication should rest with a human decision-maker. Approval depth should follow the degree of consequence — high-consequence systems may require approval from multiple stakeholders diversified across multiple organizations. Requiring confirmation prevents automatic execution (AML.T0053, AML.T0086, AML.T0101).Consequence-scaled human approval gates (including multi-stakeholder approval for high-impact changes) inject a mandatory organizational action before a change takes effect, defeating silent automatic triggers.	AUUIACATVI
0.70	ATLAS AML.M0035 — AI Red Teaming: Exercise the introduction of controlled untrusted software, data, models and agent tools through representative acquisition and deployment paths, and remediate weaknesses in provenance, validation, approvals, isolation and rollback. Attempt controlled modification or substitution of models, weights, adapters and related configuration and remediate weaknesses in authorization, artifact integrity, deployment approval, monitoring and recovery. Red teaming is continuous and should be repeated when the system, its components, intended use or deployment environment change.Repeated adversarial exercise of the model-substitution and supply-chain deployment paths proves whether approval, integrity and rollback controls actually hold, maturing the organization's response posture against a known/proven precedent.	EVISIATAC

Method

A plain-language walkthrough for GRC and compliance auditors, no technical background required

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.

Rating scale: LOW: Normal and contained. If something went wrong here, you'd find out quickly and fix it without much trouble. MEDIUM: Could cause a real problem, and you might not find out right away, worth tracking, not yet an emergency. 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.
Questionnaire priors: AC:H AR:H AT:N AU:Y AV:L CR:M E:P IR:H PR:N R:A RE:M S:P SA:L SC:L SI:H U:Amber UI:P V:C VA:N VC:L VI:H
Job: 02f05034-3a0f-4352-9cc3-d2f7bdddec47

Assessment run

test run

Ratings by hazard class

Findings

1 Whose AI brain is this, really?Headline

2 What are we feeding it?

3 What does it create from our data: and where does THAT go?

4 Who's deciding what the AI sees and does?

5 Which humans are actually looking at our stuff?

6 Who's holding the steering wheel?

7 How many companies are really in this chain: and did we agree to it?

What ABC should do next

Ranked mitigations

Method