Assessment run

dev · us-east-1
Runs / 79c54e9c-9ff2-44ae-b9f3-2238caaf7cc1Live assessmentCompleted 2026-10-28 23:47 UTC

Procured CRM adds AI summarisation with a third-party model, no notice

Organization
Brightwater Consumer Brands
Vendor / dependency
Orbit CRM (Orbit Insights AI feature)
Industry
Fortune 500 enterprise
Run time
55 min 13 s · 38 agent calls
Headline · class 7
7.4HIGH
SOV:1.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:L/E:A/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:D/RE:M/U:AmberAgent-assigned metrics, deterministically scored; not expert-reviewed.Download walkthrough (Markdown)

Ratings by hazard class

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

ClassCarried byScoreRatingLoad-bearing metrics
1 Whose AI brain is this, really?1.3 Model update / versioning control8.2HIGHACATPRUIVISCSIESAUU
2 What are we feeding it?2.2 Internal documents ingested for RAG6.7MEDIUMACATPRUIVCSCSAUV
3 What does it create from our data: and where does THAT go?3.3 Model outputs / completions7.1HIGHAVACATPRUIVCSCSAU
4 Who's deciding what the AI sees and does?4.1 Retrieval pipeline (RAG) ownership7.9HIGHAVACATPRUISCSISAU
5 Which humans are actually looking at our stuff?5.1 Human review processes5.3MEDIUMACATPRUISU
6 Who's holding the steering wheel?6.4 Configuration and policy management7.9HIGHAVACATUIVISCSIESAUV
7 How many companies are really in this chain: and did we agree to it? ◆7.2 Third-party model providers embedded in a procured product (silent AI feature addition)7.4HIGHACATPRUISCESAU

Findings

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

  1. 1 Whose AI brain is this, really?

    1.3 Model update / versioning control · also 1.1, 1.2
    HIGH8.2

    The artificial intelligence behind Orbit Insights is not Orbit's own: the summaries are produced by a third-party foundation-model provider that Brightwater Consumer Brands has never contracted with, never reviewed and whose processing location it still cannot identify, even though the customer records involved cover people in forty countries. Orbit's contract lets it change features and the underlying model whenever it chooses, with notice only at the moment a change goes live, and Orbit confirms it does not tell customers about these changes in advance. Brightwater has no right to stay on a tested version, no advance notice, no change log and no way to test a new model before it reaches staff. The quarterly release proved the point: the model provider appeared on Orbit's subprocessor list the same day the feature switched on, and Brightwater found out only because a sales manager asked why summaries had started appearing.

    Rating HIGH. Orbit and its model provider can change how the AI behaves at any time without telling Brightwater first, so any assurance you obtain today describes a system that may be different tomorrow.

    Evidence: vector, score and 21 metric rationales

    Vector SOV:1.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:H/SI:H/SA:L/E:A/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:D/RE:M/U:Red Score 8.2 (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?

    MetricValuePriorSourceRationale
    AV Access PathANagent · overrideOverride N -> A. The questionnaire's 'vendor's own cloud, reached directly over its API' describes the Orbit CRM SaaS relationship (the primary dependency). For the Model Layer specifically, the summaries are 'generated by a third-party foundation-model provider that appeared in an updated subprocessor list' — Brightwater has no direct contract or API path to that model. Any model-version or behaviour change reaches Brightwater through Orbit's pipeline, i.e. subprocessor-mediated access, which the rubric defines as A ('Adjacent -- subprocessor-mediated access'). Cited rubric metric definitions for AV.
    AC Compulsion ComplexityLLagentConfirmed. The rubric sets AC=L where 'a standard ToS clause ... suffices'. Orbit's terms expressly 'allow feature changes at its discretion with notice at the time of release', and the questionnaire confirms nothing beyond standard ToS must be overcome. Brightwater holds no customer-managed keys, model-pinning right, or version carve-out that would constitute a barrier to a model/feature change.
    AT Trigger ConditionsNPagent · overrideOverride P -> N. The prior ('only upon a specific event') reflects compelled-access scenarios at the primary dependency, but AT is a primary exploitability axis for 1.3 and must be assessed against model-change control. No triggering event is needed: the contract permits feature and model changes 'at its discretion', the change arrived in a 'routine quarterly release', and the subprocessor list was updated the same day the release shipped. The foundation-model provider can likewise re-version its model at will. Per the rubric, control exercisable at vendor discretion at any time = N.
    PR Position RequiredNNagentConfirmed. Behaviour-affecting change can originate either with Orbit (enabling/altering Insights, swapping the model provider) or with the foundation-model provider itself (updating weights or version). Both are already inside the subprocessor chain and need no further standing, and no Brightwater administrative credential is involved — rubric PR=N ('any party already in the subprocessor chain has sufficient standing').
    UI Org Action RequiredNNagentConfirmed, and this is the metric that carries the dimension. The rubric's UI=N definition names this exact fact pattern: 'silent model swap, ToS change, silently added AI feature'. Orbit Insights was 'on by default for all users', Brightwater's AI governance review 'never triggered because no one in the organisation adopted anything', and the vendor 'does not disclose [sovereignty-relevant changes] before they take effect'. The per-tenant disable switch is a remediation after the fact, not an affirmative org action required to create the exposure, so neither A nor P applies.
    VC Primary Dependency Impact -- ConfidentialityLNagent · overrideOverride of the questionnaire's 'N' (which was answered about the primary dependency, Orbit CRM as a SaaS platform, not about the model layer). At the model layer itself, the content submitted for summarisation — customer email threads and call notes drawn from records that include contract terms, pricing and personal contact details for data subjects in forty countries — is processed by a third-party foundation-model endpoint that appeared on the subprocessor list only on the day the release shipped. Because Orbit may change the model/feature at its discretion with notice only at release (questionnaire: 'It does not disclose them before they take effect'), each un-notified version or provider swap can change which model endpoint sees that content and under what retention/jurisdiction terms, with no prior review by Brightwater. The loss is partial, not total: only the text routed into summarisation is exposed at this layer, not the CRM corpus at rest, and the bulk of the confidentiality exposure lands beyond this dependency (questionnaire: 'Full: sensitive data becomes readable by a party we never contracted with'), which belongs on the subsequent axis. The rubric also places VC primarily on dimension 1.1 (hosting/jurisdiction) rather than 1.3, which supports L rather than H here.
    VI Primary Dependency Impact -- IntegrityHNagent · overrideOverride of the questionnaire prior 'N'. The rubric designates VI as the primary impact axis for dimension 1.3 'Model update / versioning control' and notes that un-notified behaviour change is the defining harm of this dimension. Orbit's terms permit feature and model changes at its sole discretion with notice only at the time of release, and the questionnaire confirms sovereignty-relevant changes (model versions, subprocessors) are not disclosed before they take effect; no org action is required ('the vendor or subprocessor can act unilaterally'), and the change can hit all customers at once. Brightwater therefore has no version pinning, no pre-release evaluation and no detection path — it discovered the feature only when a sales manager asked why summaries were appearing. Behaviour and outputs of the model layer can thus be altered completely and without Brightwater's knowledge or consent, which is a total loss of integrity control at the dependency itself: H.
    VA Primary Dependency Impact -- AvailabilityNNagentConfirm the prior. Nothing in the scenario indicates that the update/versioning regime withdraws or degrades capability at the model layer: the feature is live and functional, it can be disabled per tenant by an administrator, and the questionnaire states the capability could not be withdrawn at this dependency ('None: we could keep operating this component'), with exit judged feasible via manual migration. The rubric likewise assigns VA to dimension 1.2 (weight custody) but lists only VI for 1.3, so availability is not the axis this dimension carries. Residual risk noted (a silent version retirement could make a previously validated model behaviour permanently unavailable), but on the present evidence any availability effect appears downstream only ('some downstream workloads degrade'), which belongs on the subsequent axis rather than here.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentConfirmed at H. Under dimension 1.3 the exercising party is Orbit deciding unilaterally when the underlying model changes, and Orbit's terms permit feature/model changes at its discretion with notice only at release. The release itself demonstrated the mechanism: a third-party foundation-model provider appeared on the subprocessor list the same day the feature shipped, so a model-version decision is simultaneously a decision about which party receives the content. Downstream of the CRM tenant, the summarised material is customer email threads and call notes plus CRM records containing contract terms, pricing and personal contact details for data subjects in forty countries, and the inference jurisdiction is unknown to Brightwater (the classifier's secondary 1.1 finding). A future un-notified version/provider swap therefore makes sensitive data readable by a party Brightwater never contracted with and never reviewed — the questionnaire's 'Full: sensitive data becomes readable by a party we never contracted with'. This matches the rubric's own archetype for Subsequent Confidentiality, where the processing vendor is a DIFFERENT vendor than the org's contracted one. Rated H rather than L because the exposed corpus is the full customer-communication and CRM record set across forty countries, not a bounded subset; confidence is tempered because an update could in principle be model-internal with no change of processor.
    SI Downstream Blast-Radius Impact -- IntegrityHHagentConfirmed at H — this is the metric the dimension exists to express. The rubric's 1.3 entry says verbatim: 'Every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact,' with subsequent_impact_relevant=true. Concretely, Orbit Insights outputs are not terminal artefacts: summaries of email threads and call notes and suggested next actions feed human sales decisions and CRM record-keeping, and the feature was on by default for all users. Because Orbit does not disclose sovereignty-relevant changes (model versions, subprocessors) before they take effect, a behaviour-affecting model swap reaches every seat with no version pin, no changelog and no regression gate on Brightwater's side — the questionnaire's 'Full: downstream systems act on altered outputs without detection'. The detection failure is evidenced in the scenario: Brightwater noticed the original change only when a sales manager asked why summaries were appearing, so there is no monitoring capable of catching a silent behavioural drift. The EU AI Act value-chain provisions on modification/fine-tuning documentation reinforce that undocumented model modification is the recognised integrity failure mode along the chain.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentConfirmed at L. An un-notified model version change can break downstream consumers of the output (prompt/format assumptions, any reporting or workflow that consumes suggested next actions), which the questionnaire records as 'Some downstream workloads degrade' — partial, not total, loss. The affected surface is one narrow workload (summarisation/next-action suggestion) and the capability is reconstitutable with manual migration effort, so the CRM and the sales process keep functioning without it; this is a convenience-layer degradation rather than a near-total availability loss, which rules out H. S (Safety) is rejected because the downstream consumers are commercial CRM and sales decisions at a consumer-brands manufacturer — no physical or safety-relevant failure path, so the EU AI Act systemic-risk safety framing does not apply here; the regulatory consequence of this scenario is carried by the supplemental S metric, not by SA.
    E Precedent MaturityAXagent · overrideOverride of the questionnaire's 'Unknown' (X). For dimension 1.3 the control in question is the vendor's ability to change model/feature behaviour unilaterally with notice only at release. That control has already been exercised against Brightwater itself in the scenario: Orbit shipped Orbit Insights on-by-default in a routine quarterly release, with the third-party foundation-model provider appearing on the subprocessor list the same day the release shipped, and Brightwater learned of it only when a sales manager noticed summaries appearing. An already-realized exercise against the assessed organization is at least as strong as the 'documented real-world cases against comparable orgs' standard for E:A, so 'Unknown' reflects the respondent's lack of market knowledge rather than absence of precedent. Corpus evidence corroborates the class of event: the sovereignty rubric itself names 'silently added AI feature' and 'silent model swap' as the canonical UI:N pattern (sovereignty_cvss_rubric_1.json), and MITRE ATLAS records AML.T0109 'AI Supply Chain Rug Pull' - publishing a component, gaining adoption, then pushing a behaviour-changing update - at maturity Realized, which the CASE/ATLAS mapping converts directly to E:A, evidenced by the incident case study AML.CS0053 (Poisoned Postmark MCP Server, Incident 2025-09-01) where adopters inherited an un-notified behaviour change through a routine version upgrade. ATLAS also rates AML.T0047 'AI-Enabled Product or Service' (indirect access to a model embedded in a product) as Realized → E:A. Note the mapping caveat: ATLAS frames these as adversarial supply-chain actions, whereas here the actor is the contracted vendor acting within its terms; the maturity judgement transfers because the mechanism and the downstream integrity consequence (every consumer of the summaries inherits an un-notified change) are the same. Hence E:A rather than E:P.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)LLquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePPagentConfirmed. The rubric defines S=P as a compromise that independently triggers a reportable regulatory violation, citing GDPR Art. 28 and EU AI Act Title III as the paradigm cases (sovereignty_cvss_rubric_1.json, supplemental.S). Here, a quarterly release routed CRM content containing contract terms, pricing and personal contact details for data subjects in forty countries to a newly-added third-party foundation-model subprocessor, disclosed on the trust site only on the day the release shipped. Under dimension 1.3 the behaviour-affecting update is applied with no pre-effect notice, so Brightwater as controller cannot exercise the prior-authorisation/objection rights it owes itself under Art. 28, and cannot keep its Art. 30 records or DPIA current. The EU AI Act reinforces that deployers must update their assessment when the elements of the system change and must use provider information to keep an Art. 35 GDPR DPIA accurate (eu-ai-act-2024-1689.md, deployer obligations) -- impossible when the model version changes silently. The questionnaire independently answers 'Yes' to the reportable-violation question. Regulatory consequence is therefore Present and arises from this dimension on its own, not only via the confidentiality path of 1.1.
    AU Silent/Automatic TriggerYYagentConfirmed, and this is the metric the rubric itself flags as the supplemental hook for dimension 1.3 (sovereignty_cvss_rubric_1.json: 1.3 'supplemental_hook': 'AU'). Orbit Insights arrived in a routine quarterly release, on by default for all users, under terms permitting feature and model changes at Orbit's discretion. No Brightwater decision, ticket or opt-in gated it -- the questionnaire confirms 'the vendor or subprocessor can act unilaterally' and 'None' required from the organisation. A multi-tenant SaaS release channel propagates a model-behaviour change to the whole customer base simultaneously with no case-by-case determination, which is exactly the Y definition. This also matches dimension 7.2's framing of 'silent AI feature addition' in a procured product.
    R Portability / Exit RecoveryUUagentConfirmed as User. The rubric's primary hook for R is 1.2 (weight custody), so for 1.3 it is read as portability of the summarisation capability whose version Brightwater does not control. Brightwater is not locked in: the feature is a per-tenant toggle and the CRM keeps functioning without it (questionnaire: 'we could keep operating this component'), so this is not Irrecoverable. But it is not Automatic either -- the questionnaire states reconstitution requires 'manual migration effort (re-embedding, re-integration, re-contracting)', and FRB SR 11-7 makes the same point for externally-sourced models: the organisation must hold enough in-house knowledge and contingency planning to stand the capability up elsewhere if the vendor product becomes unavailable (frb-sr-11-7-model-risk-management.md, validation of vendor products). Manual, non-trivial, but achievable = U.
    V Blast-Radius ConcentrationDDagentConfirmed as Diffuse, with reservation. V measures whether the dependency sits in the critical path for many/all of the organisation's AI workloads, e.g. a shared control plane (sovereignty_cvss_rubric_1.json, supplemental.V). Orbit Insights is a single narrow workload -- email/call-note summarisation and next-action suggestions -- and the questionnaire confirms 'one narrow workload' depends on it; the sales organisation only noticed because summaries appeared. The counter-argument is real and worth recording for the reviewer: Orbit's release channel is a shared control plane on the vendor side, and the underlying CRM is Brightwater's eight-year global system of record, so if Orbit extends the same foundation-model dependency to further Insights features V would move to C. On today's facts the blast radius of an un-notified model update is bounded to this one feature, so D stands, at reduced confidence.
    RE Exit / Mitigation EffortMMagentConfirmed as Moderate. Immediate mitigation of the un-notified-update exposure is cheap: an administrator can disable Insights per tenant, and no re-architecture of the CRM or of Brightwater's integrations is required (questionnaire: 'a project, but no re-architecture'). The durable fix -- version-pinning, pre-release notice of model changes, and subprocessor change rights -- requires amending a global enterprise agreement whose current terms reserve feature changes to Orbit's discretion, plus wiring Orbit releases into the AI governance gate that failed to trigger. That is a cross-functional project (legal, procurement, IT) rather than a trivial contractual fix, so L is wrong; but because no infrastructure replacement or platform exit is needed to neutralise this dimension, H overstates it. Reviewer note: if Orbit refuses notice/pinning commitments and the only remedy becomes exiting an eight-year platform relationship, RE should be re-rated H.
    U Vendor Notice PostureRedRedagentConfirmed as Red for this dimension. The rubric distinguishes Red ('never discloses sovereignty-relevant changes before they take effect') from Amber ('discloses concurrently with the change taking effect'). For the subprocessor list alone, Amber is arguable: the updated list appeared on the trust site the same day the release shipped. But dimension 1.3 is about model version/behaviour changes, and there is no disclosure mechanism for those at all: Orbit's terms promise only notice at the time of release of its own feature changes, and subsequent model-version upgrades by the third-party foundation-model provider sit behind Orbit with no publication commitment, so they reach every downstream consumer with no notice whatsoever. The questionnaire states flatly that the vendor 'does not disclose them before they take effect', and the fact that Brightwater learned of Insights only when a sales manager asked shows the posture is passive publication rather than notification. No pre-effect notice, no contractual guarantee = Red.
  2. 2 What are we feeding it?

    2.2 Internal documents ingested for RAG · also 2.1
    MEDIUM6.7

    What is being fed to the AI is not text that Brightwater staff chose to type in; it is existing CRM content assembled automatically by Orbit — customer email threads, call notes, contract terms, pricing and personal contact details for customers in forty countries. Brightwater never decided to send this material anywhere: the feature arrived switched on in a routine release and the platform began packaging records and transmitting them to the external model provider the same day that provider was added to the subprocessor list. There was no review of what would be sent, no opportunity to narrow the scope or redact sensitive fields, and no data protection impact assessment. Because the receiving party was never authorised in advance, the data flow by itself is a reportable data protection failure for Brightwater as the controller.

    Rating MEDIUM. Sensitive customer and commercial records left Brightwater's contracted boundary in bulk without anyone at Brightwater choosing, scoping or approving it, which is an independently reportable compliance breach.

    Evidence: vector, score and 21 metric rationales

    Vector SOV:1.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:L/E:P/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:C/RE:M/U:Amber Score 6.7 (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?

    MetricValuePriorSourceRationale
    AV Access PathANagent · overrideOverride of the questionnaire's 'N'. The prior describes the primary dependency (Orbit's SaaS in its own cloud, reached over its API). For dimension 2.2 the object of assessment is the CRM content itself — email threads, call notes, contract terms, pricing, personal contact details — which Orbit Insights automatically assembles and forwards as retrieval context to a *third-party foundation-model provider* that appeared on the subprocessor list the day the release shipped. The access path to that document corpus is therefore subprocessor-mediated rather than vendor-direct: the model provider never contracts with Brightwater and reaches the documents only through Orbit's pipeline. The rubric defines A as 'Adjacent -- subprocessor-mediated access' (sovereignty_cvss_rubric_1.json, exploitability/AV), and names AV as one of the two exploitability metrics that carry node 2.2.
    AC Compulsion ComplexityLLagentConfirmed. No technical or contractual barrier had to be overcome before the CRM corpus was routed to the model provider: Orbit's terms 'allow feature changes at its discretion with notice at the time of release', the feature was on by default, and nothing in the eight-year enterprise agreement (no customer-managed keys, no data-residency carve-out for the forty countries' customer records) stood in the way. That is exactly the rubric's L: 'a standard ToS clause or routine legal process suffices'.
    AT Trigger ConditionsNPagent · overrideOverride of the questionnaire's 'P'. Ingestion of the internal documents required no sanctions designation, litigation hold or security incident — it began in a *routine quarterly release*, at Orbit's product discretion, on by default for all users, with the subprocessor list updated the same day. That is the rubric's N: 'control can be exercised at vendor discretion at any time'. AT is flagged as a primary exploitability metric for 2.2, and here it is the metric that carries the dimension: the trigger is nothing more than the vendor's own release cadence. The questionnaire's 'specific event' answer appears to reflect legal-compulsion scenarios at the primary dependency, not the mechanism actually observed for the RAG corpus.
    PR Position RequiredNNagentConfirmed. The party that newly obtains the customer records is the third-party foundation-model provider, whose only standing is membership of Orbit's published subprocessor chain; it needs neither prime-contractor status nor any Brightwater administrative credential (indeed Brightwater's admins were unaware). Rubric N: 'any party already in the subprocessor chain has sufficient standing'.
    UI Org Action RequiredNNagentConfirmed. Brightwater took no affirmative step: its AI governance review 'never triggered because no one in the organisation adopted anything', the feature was enabled per-tenant by default, and disclosure came only at release time. The rubric's N value is illustrated by precisely this fact pattern — 'vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature)'. P (passive) was considered because summaries surface during ordinary CRM use, but the corpus-level exposure (records routed to the subprocessor) was created by the vendor's unilateral enablement, not by the org's usage.
    VC Primary Dependency Impact -- ConfidentialityHNagent · overrideOverride of the questionnaire prior ('no sensitive data is exposed here'). The prior describes the primary dependency (the Orbit CRM service relationship), where no new data is exposed. But the dependency named by dimension 2.2 IS the ingested document corpus itself, and the rubric defines VC as confidentiality loss 'AT the dependency named by the taxonomy node' (sovereignty_cvss_rubric_1.json, vulnerable_system_impact). Here the ingested material is customer email threads, call notes, contract terms, pricing and personal contact details for customers in forty countries — automatically assembled and transmitted as model context. The recipient is a third-party foundation-model provider that only appeared on the subprocessor list the day the release shipped, so the full content of the retrieval set left Brightwater's contracted boundary with no review, no DPIA and no opportunity to scope or redact. That is a total, not partial, loss of confidentiality over the corpus at the ingestion surface; it is also consistent with the questionnaire's own downstream answer ('Full: sensitive data becomes readable by a party we never contracted with') and with the supplemental answer that the event alone triggers a reportable violation (GDPR Art. 28 subprocessor authorisation, per the rubric's Safety/Regulatory Consequence definition). ATLAS AML.T0085.000 (RAG Databases as a collection surface) and AML.T0082 note that whatever lands in the retrieval corpus becomes reachable through the pipeline, including material never intended for it.
    VI Primary Dependency Impact -- IntegrityLNagent · overrideOverride of the prior 'None', again because the prior is scored against the CRM service rather than the ingestion pipeline; the rubric names VI as a primary impact axis for dimension 2.2. Brightwater has no control over, and no visibility into, which records Orbit selects and assembles into the model context, and Orbit's terms permit it to change that behaviour at its discretion with notice only at release time (the vendor 'does not disclose [sovereignty-relevant changes] before they take effect'). In addition, machine-generated summaries and 'suggested next actions' are surfaced back into the CRM alongside employee-authored notes, so the authoritative customer record now contains unvalidated derived content that no one reviewed. Corpus precedent shows the ingestion path is an integrity surface in its own right: RAG Poisoning (AML.T0070) and False RAG Entry Injection (AML.T0071, explicitly anchored to CASE dimension 2.2) show externally supplied content — e.g. inbound customer email, exactly what Orbit Insights ingests — being treated as trusted retrieved documents, and AML.CS0059 demonstrates this end-to-end via a customer email auto-ingested into the retrieval set. Scored L rather than H because the underlying CRM records as entered by Brightwater staff are not overwritten or destroyed; the loss is partial — contamination/augmentation of the record set and loss of control over context composition, not total loss of trust in the data.
    VA Primary Dependency Impact -- AvailabilityNNagentConfirms the prior. Nothing in the scenario withdraws or degrades access to the ingested documents: the CRM records remain in place and fully usable, the AI feature is additive and can be switched off per tenant by an administrator, and the questionnaire confirms the component could keep operating ('None: we could keep operating this component') with exit requiring only moderate manual migration. The rubric also does not list availability as an impact axis for dimension 2.2 (primary_impact_axis: VI, VC). Any availability concern in this scenario is downstream workload degradation, which belongs to the subsequent-impact group, not to VA.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentConfirmed. The CASE rubric marks dimension 2.2 as generally 'subsequent_impact_relevant: false' (primary axes VI/VC), because document ingestion usually lands its loss at the dependency itself. In this scenario, however, the ingestion path does not terminate at the contracted vendor: Orbit assembles CRM content (customer email threads, call notes, contract terms, pricing, personal contact details for customers in forty countries) and ships it as context to a third-party foundation-model provider that appeared on the subprocessor list only the day the release shipped. That provider — and anything in its own chain — is a party Brightwater never contracted with and never risk-reviewed, which is the textbook subsequent-confidentiality pattern the rubric describes for onward-hop vendors (e.g. its note on 3.1 embeddings: 'stored by a DIFFERENT vendor than the LLM -- textbook Subsequent Confidentiality (SC) impact, since the [vendor] was never the org's contracted AI vendor'). The questionnaire's 'Full: sensitive data becomes readable by a party we never contracted with' therefore applies directly to this category's own exposure: the entire ingested corpus, including special-category-adjacent personal data across forty jurisdictions, is readable downstream, and the questionnaire confirms this alone would be a reportable regulatory violation. Near-total loss on this axis → H. MITRE ATLAS AML.T0082 further notes that whatever sits in internal documents (including credentials) travels with them into a retrieval pipeline, so the downstream reader inherits the full sensitivity of the source corpus.
    SI Downstream Blast-Radius Impact -- IntegrityLHagent · overrideOverride of the questionnaire's H. The questionnaire's 'downstream systems act on altered outputs without detection' is calibrated to the primary dependency (the silently added feature / subprocessor chain). Assessed on this category's own ingestion surface, the downstream integrity path is narrower: Orbit Insights only summarises threads and 'suggests next actions'. There is no tool-call or write-back to a production system (contrast rubric 2.4 and 4.3, where real-world action makes subsequent impact near-definitional), and a human sales manager reads the summary before acting — indeed a sales manager's query is how Brightwater detected the feature at all. The realistic integrity harm is distorted or poisoned summaries biasing individual sales decisions on one narrow workload (ATLAS AML.T0070 RAG Poisoning and AML.T0071 False RAG Entry Injection are both anchored to dimension 2.2 and are 'Demonstrated', so the mechanism is real), which is partial, bounded corruption of downstream judgement rather than total or near-total loss of downstream integrity. L.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentConfirmed at L. If the ingestion path were withdrawn (Orbit retiring Insights, the model subprocessor being cut off, or an administrator disabling the feature per tenant), the CRM itself and all eight years of record-keeping continue to function — the questionnaire records 'None: we could keep operating this component' at the dependency and only 'some downstream workloads degrade' beyond it, consistent with a single narrow summarisation workload that is reconstitutable with manual migration effort. That is partial, not total, downstream availability loss. Not S: Brightwater is a consumer-brands manufacturer and this pipeline touches CRM text and sales follow-up only, with no control over physical processes or any safety-relevant function, so no availability failure here could cause physical harm.
    E Precedent MaturityPXagent · overrideOverride of the questionnaire's X (prior reflects only that the respondent did not know whether this control had been exercised; corpus evidence supplies the missing precedent record). The exposure in this dimension is that Orbit CRM's customer email threads, call notes, contract terms, pricing and personal contact details are automatically assembled and sent as retrieval context to a third-party foundation-model subprocessor. CASE's ATLAS mapping rule (atlas/README.md) is explicit: 'Realized / Incident -> E:A, Demonstrated / Exercise -> E:P, Feasible -> E:U'. The techniques the taxonomy names as the anchor for dimension 2.2 are RAG Poisoning (AML.T0070) and False RAG Entry Injection (AML.T0071), both carrying maturity 'Demonstrated -> CASE Precedent Maturity E:P'; the closest comparable-organisation evidence is likewise demonstration work rather than confirmed attack: AML.CS0035 'Data Exfiltration from Slack AI via Indirect Prompt Injection' (Type: Exercise -> E:P, PromptArmor, enterprise SaaS auto-indexing internal workspace content into its RAG database) and AML.CS0059 EchoLeak against M365 Copilot (Exercise, where an ordinary inbound email was 'automatically ingested into a RAG database available to Copilot's retrieval pipeline'), plus AML.T0082 RAG Credential Harvesting (Demonstrated -> E:P) for secrets residing in ingested internal documents. These establish that sensitive internal records being swept into a vendor-operated retrieval pipeline, and then read out or altered, is a publicly demonstrated and reproducible exposure against directly comparable enterprise SaaS stacks (Slack, M365) — more than theoretical, so not U. But there is no Incident-type case study for this pattern, and the questionnaire reports precedent against comparable organisations as 'Unknown', with nothing confirmed against Brightwater's own Orbit CRM / Orbit Insights stack — so the 'Attacked' threshold of documented real-world exercise against comparable orgs is not met, and P is the correct value.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)LLquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePPagentConfirmed. The rubric's definition of S cites GDPR Art. 28 as the archetype, and this dimension is where the violation actually crystallises: the material ingested is existing CRM content — contract terms, pricing and personal contact details for customers in forty countries — automatically assembled and sent to a foundation-model provider that appeared on Orbit's subprocessor list only on the day the release shipped. A controller (Brightwater) therefore had personal data disclosed to a new sub-processor with no prior specific or general authorisation and no opportunity to object (Art. 28(2)/(3)(d)), with onward cross-border flows unassessed (Chapter V) and no DPIA performed (Art. 35; cf. the deployer DPIA linkage in the EU AI Act). That is an independently reportable regulatory violation arising from this ingestion path alone, irrespective of any downstream misuse of the summaries.
    AU Silent/Automatic TriggerYYagentConfirmed, and it is even cleaner for this dimension than for the interaction surface. Ingestion of CRM email threads and call notes into the summarisation context required no per-record, per-user or per-tenant decision: Orbit Insights shipped in a routine quarterly release, on by default for all users, and the corpus was assembled automatically by the platform. The rubric recognises this delivery pattern as its own dimension (7.2, 'silent AI feature addition'). The same release therefore began exposing every comparable Orbit tenant's document corpus simultaneously — the loss event is platform-wide and automatic, not case-by-case.
    R Portability / Exit RecoveryUUagentConfirmed. The ingested material is Brightwater's own system-of-record data, not a vendor-generated artefact, so the capability is reconstitutable: records can be exported and re-indexed against a different platform or a self-hosted retrieval pipeline. But it is not automatic — eight years of accreted email threads, call notes and relationship structure under a global enterprise agreement would require export, re-embedding, re-integration and re-contracting, with some fidelity loss in thread and attachment structure. That is the rubric's 'User (manual migration effort)' band, not 'Irrecoverable'. Caveat for the reviewer: R measures reconstitution of the capability, not reversal of harm — the disclosure of the already-ingested corpus to the model provider is irreversible regardless of R.
    V Blast-Radius ConcentrationCDagent · overrideOverride. The questionnaire's 'one narrow workload' answer describes the primary dependency (the Insights summarisation feature). Assessed on its own terms, however, the 2.2 dependency is not the feature but the CRM corpus and the platform-side ingestion path that feeds it — and that sits in the critical path for every AI capability Orbit chooses to enable on the tenant. Orbit demonstrated in this very release that it can switch on a new AI consumer of that corpus unilaterally, at its discretion, in a routine quarterly cycle; any further feature draws on the same pool. The corpus itself is also concentrated rather than scoped: a single repository holding contract terms, pricing and personal contact details for customers in forty countries, i.e. the rubric's 'diffuse per-event, concentrated in aggregate' pattern (noted for 3.5) realised in aggregate form. A single configuration or subprocessor change at that chokepoint therefore exposes the whole customer estate, which is the substance of 'Concentrated'. Confidence is moderate because a strict reading that counts only currently-live AI workloads would support D.
    RE Exit / Mitigation EffortMMagentConfirmed. Stopping the flow is cheap — an administrator can disable the feature per tenant — so the immediate tap can be closed without re-architecture. Durable mitigation of this ingestion surface is nonetheless a project rather than a trivial fix: re-contracting Orbit's 'feature changes at its discretion with notice at the time of release' clause to require prior subprocessor authorisation and advance notice, obtaining deletion/non-retention assurances from a model provider Brightwater never contracted with, running the missing DPIA, and establishing tenant-level controls so the next default-on feature cannot re-ingest the corpus. That is the Moderate band; it stops short of High because no re-architecture or infrastructure replacement is required while Brightwater remains on Orbit.
    U Vendor Notice PostureAmberRedagent · overrideOverride to the more precise rung. The questionnaire answer ('does not disclose before they take effect') is consistent with both Red and Amber, but the scenario shows disclosure did occur, concurrently: the updated subprocessor list naming the foundation-model provider was published on Orbit's trust site the same day the release shipped, and the terms expressly provide for feature changes 'with notice at the time of release'. The rubric reserves Red for a vendor that never discloses sovereignty-relevant changes before they take effect and defines Amber as disclosure concurrent with the change taking effect — which is exactly the observed posture. Reviewer caveat: this sits on the Red/Amber boundary, because the disclosure was pull-based (a trust-site page Brightwater had to go and read) rather than pushed to the customer, which is why the organisation only learned of the ingestion when a sales manager asked about the summaries; if the assessor's convention treats passive trust-site publication as non-disclosure, Red applies.
  3. 3 What does it create from our data: and where does THAT go?

    3.3 Model outputs / completions · also 3.5
    HIGH7.1

    The feature creates new material from Brightwater's data: a written summary of each email thread and call note plus a suggested next action, saved back into the customer record. These summaries concentrate the most sensitive content — pricing, contract terms and named contact details — into a compact form, and they are produced by, and may be retained by, both Orbit and the external model provider. Nobody at Brightwater knows whether those summaries are kept for quality monitoring, for how long, who can read them or in which country they are stored, because the model provider was never assessed and no contract term covers retention of this output. The feature was on for every user, so this applies to every summary generated, not to a small sample.

    Rating HIGH. Brightwater cannot say where copies of AI-written summaries of its customer data are held, how long they persist or under whose laws, so it cannot answer a regulator's or customer's question about them.

    Evidence: vector, score and 21 metric rationales

    Vector SOV:1.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:L/E:P/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:D/RE:M/U:Amber Score 7.1 (High)

    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?

    MetricValuePriorSourceRationale
    AV Access PathNNagentConfirmed. The completion is written back into the CRM record held in Orbit's own cloud and reached directly over its API, so the derivative sits on the same vendor-direct path as the primary dependency — no intermediary is required to reach it. The subprocessor-mediated copy (the model provider's completion logs) is a second, parallel route rather than the only route; consistent with CVSS convention the more exposed path governs AV, and the subprocessor-chain dimension is scored separately under PR=N. The CLOUD Act white paper reinforces that provider-controlled data is reachable wherever it physically rests, so the hosting location of the generating model does not narrow the path (doj-cloud-act-white-paper-2019.md).
    AC Compulsion ComplexityLLagentConfirmed. Nothing had to be overcome: Orbit's terms already 'allow feature changes at its discretion with notice at the time of release', and the subprocessor was added to the trust-site list the same day the release shipped. There are no customer-managed keys, no data-residency carve-outs and no negotiated DPA term governing completion retention for this feature — Brightwater's own AI governance gate never even engaged. For legal-process routes, the CLOUD Act white paper confirms routine domestic process suffices against any provider with a jurisdictional hook, with disclosure to the customer potentially barred by the issuing country's law (doj-cloud-act-white-paper-2019.md).
    AT Trigger ConditionsNPagent · overrideOVERRIDE of prior P. The prior describes the primary dependency, where a sanctions designation or litigation hold would be needed to compel disclosure. For model outputs specifically, no triggering event is required: completions are generated, transmitted to the foundation-model provider and retained as a matter of ordinary operation, and retention of automatically generated logs by whichever party controls them is the standing regulatory baseline (EU AI Act Arts. 19 and 26(6), minimum six months). Orbit has already demonstrated pure discretion over this surface — it enabled the feature and added the subprocessor unilaterally, with no pre-disclosure of sovereignty-relevant changes. Quality-monitoring retention and model-version swaps can thus be exercised at vendor or subprocessor discretion at any time. Confidence is moderated because the corpus yielded no commercial LLM API logging terms to confirm the specific retention practice, which is itself the unknown that drives this dimension.
    PR Position RequiredNNagentConfirmed. The completion is held by at least two parties, and the foundation-model provider — a subprocessor Brightwater never contracted with or reviewed — holds the output directly as the party that generated it. No elevated standing is needed: any party already in the subprocessor chain has sufficient position to retain, inspect or be compelled to produce the summaries. EU AI Act Art. 25 confirms that third parties in the chain can hold provider-level control and obligations over the system and its outputs.
    UI Org Action RequiredNNagentConfirmed, and this metric substantially carries the dimension. The rubric's N examples include a 'silently added AI feature', which is literally this scenario: Orbit Insights was on by default for all users in a routine quarterly release, so completions began being generated and sent to an unreviewed subprocessor with no affirmative act by Brightwater — 'no one in the organisation adopted anything'. The exposure is the default state, and it is *disabling* the feature that requires an affirmative administrative action; Brightwater only learned of it when a sales manager asked why summaries were appearing. I considered P (routine use triggers exposure), since summaries arise as staff work customer threads, but reading email in a CRM is not an AI-specific action and the exposure was created unilaterally by the vendor, not by any user election. Orbit also 'does not disclose [sovereignty-relevant changes] before they take effect', consistent with Art. 50(2)'s carve-out for assistive-editing systems (eu-ai-act-2024-1689.md).
    VC Primary Dependency Impact -- ConfidentialityHNagent · overrideOverride of the questionnaire's 'N'. The prior answers describe the primary dependency as the Orbit CRM/API surface where 'no sensitive data is exposed here'; for Category 3.3 the dependency in scope is the derivative itself — the generated summary of customer email threads and call notes plus the suggested next action written back into the CRM record. Those completions condense exactly the sensitive content of the records: contract terms, pricing and personal contact details for customers in forty countries. The rubric assigns VC as the primary impact axis for 3.3 precisely because completions are retained by the vendor and the foundation-model subprocessor for quality monitoring under a retention policy and jurisdiction that are unknown here (the subprocessor appeared on the trust site the day the release shipped and was never reviewed). Because the feature was on by default for all users and the exposure applies to every completion generated, rather than case-by-case, the loss of confidentiality control over this derivative class is total or near-total → H.
    VI Primary Dependency Impact -- IntegrityLNagent · overrideOverride of 'N', but only to Low. Orbit reserves the right to change features at its discretion with notice at the time of release and does not disclose model versions, subprocessors or hosting changes before they take effect, so the content and behaviour of the completion layer can be altered unilaterally and un-notified; ATLAS material on model substitution/integrity erosion (AML.T0018, AML.T0031) shows such changes yield plausible but altered outputs that are hard to detect, and SR 11-7 treats absence of vendor change disclosure, logged changes and outcome monitoring as an unmanaged integrity risk for third-party model outputs. The loss is partial rather than total: the authoritative source artefacts (email threads, call notes, contract and pricing fields) remain intact and human-readable, and only the summary/next-action derivative is affected, so corruption is bounded and correctable. The rubric also locates total-integrity impact at 1.3 (model update/versioning) rather than at 3.3, and the compounding effect of altered next actions being acted upon belongs to the subsequent-impact group, not VI.
    VA Primary Dependency Impact -- AvailabilityNNagentConfirms the prior. If Orbit withdrew or degraded Orbit Insights — or if Brightwater's administrator disabled it per tenant, as it can — no capability Brightwater relies on is lost: the CRM records, email threads and call notes remain fully usable and the organisation operated without summaries for the previous eight years. The questionnaire's own answer at this dependency ('None: we could keep operating this component') is consistent, and the rubric does not list availability as an impact axis for 3.3. Residual availability concerns (summaries already persisted in records being purged) are speculative and not evidenced in the scenario.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentCONFIRM prior. The rubric designates SC/SI/SA as the group expressing loss that propagates beyond the named dependency, and marks 3.3 (model outputs/completions) as subsequent_impact_relevant with gap_severity Medium-High and 'no existing standard' (sovereignty_cvss_rubric_1.json). Here the completion itself is the derivative: a summary of customer email threads and call notes that, by construction, distils contract terms, pricing and personal contact details for customers in forty countries. The subsequent system is the foundation-model provider (and Orbit's own quality-monitoring logs): it appeared on the subprocessor list the same day the release shipped, was never reviewed by Brightwater's AI governance process, and its completion-retention policy, retention period and jurisdiction are entirely unknown. This is the same structure the rubric calls 'textbook Subsequent Confidentiality (SC) impact' for 3.1 — a derivative held by a vendor that 'was never the org's contracted AI vendor'. The questionnaire confirms the mechanism: the exposure requires no action by Brightwater (vendor/subprocessor acts unilaterally), any party already in the subprocessor chain has sufficient standing, and access needs nothing beyond standard ToS or routine legal process. ATLAS AML.T0126 notes that conversation histories, logs and other operational data are themselves targeted material in AI environments. Because the content made readable to an uncontracted party is regulated personal data plus commercially sensitive pricing/contract terms across forty jurisdictions — and the questionnaire records that this alone would trigger a reportable regulatory violation — the loss on this axis is near-total rather than partial.
    SI Downstream Blast-Radius Impact -- IntegrityLHagent · overrideOVERRIDE prior H to L. There is a genuine downstream integrity exposure: the completion is written back into the CRM record as a summary plus a suggested next action, carries no provenance marking distinguishing it from human-entered notes, and Orbit does not disclose model-version or subprocessor changes before they take effect — the condition the rubric describes for 1.3, where 'every downstream consumer of the model inherits an un-notified behavior change'. EU AI Act recital 133 is directly on point on why unmarked synthetic content degrades the integrity of the record it enters, and ATLAS AML.T0067 shows that 'recommended follow-up actions' are a manipulable output component that can be made to look trustworthy. But H requires total or near-total loss downstream, and three facts cap this at partial: (a) the authoritative source data — the underlying emails and call notes — is unaltered, so corrupted summaries are detectable and correctable against ground truth, which is the corrigibility/reversibility factor the EU AI Act Art. 7 criteria treat as risk-reducing; (b) the output is advisory, read by a human sales user, and does not execute — no tool-call or agentic write-back is evidenced, so the rubric's 2.4/4.3 'acts on a live production system' pattern does not apply here; (c) the questionnaire scopes this to one narrow workload. The prior's 'downstream systems act on altered outputs without detection' describes the primary Category 7 subprocessor dependency; for this category's own exposure (a summarisation completion) the classifier itself notes exposure is 'real but narrower than Category 7's'.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentCONFIRM prior. If the completion capability is withdrawn or degraded — Orbit retiring the feature, a product decision, or the foundation-model subprocessor being cut off by sanctions designation or an incident — the CRM itself and its customer records keep functioning; only the summarisation/next-action layer stops. The questionnaire matches this: no availability loss at the dependency ('we could keep operating this component') and only 'some downstream workloads degrade' beyond it, with the capability reconstitutable elsewhere through manual migration at moderate, non-re-architecting effort. That is partial, not total, downstream availability loss. S (Safety) is explicitly rejected: a sales-facing summarisation feature in a consumer-brands CRM has no physical or safety-relevant failure mode; the regulatory exposure flagged in the questionnaire belongs on the supplemental Regulatory Consequence hook (S:P in the rubric's supplemental group), not on SA.
    E Precedent MaturityPXagent · overrideOverride of the X prior: the corpus does contain relevant precedent, so 'not defined' is not warranted. For dimension 3.3 the sovereignty-relevant control is the vendor's (and the un-reviewed foundation-model subprocessor's) retention, logging and reuse of generated summaries and suggested next actions. ATLAS carries several directly comparable, publicly documented demonstrations of completion-layer exposure in default-on enterprise SaaS AI features: AML.CS0035 (Slack AI — private data surfaced through an auto-enabled summarisation/Q&A feature), AML.CS0021 (ChatGPT conversation exfiltration), AML.CS0060 (Lenovo 'Lena' — a completion persisted in vendor-side chat history and later rendered against a support agent), and technique AML.T0057 LLM Data Leakage. Every one of these is typed Exercise / Demonstrated, which atlas/README.md maps explicitly to E:P; none is an Incident/Realized case study, which is what E:A would require. This matches the scenario: no evidence that Orbit or its model subprocessor has actually exercised retention, quality-monitoring reuse, or legal-process disclosure of Brightwater's completions — indeed the questionnaire answers 'Unknown' to whether this control has been exercised against comparable organisations, and Brightwater never reviewed the subprocessor so its own stack has not been tested. E:U (theoretical only) is too low: the rubric's own 3.3 entry (primary_impact_axis VC, subsequent_impact_relevant true, gap_severity Medium-High, existing_standard 'None identified') frames this as a recognised, documented exposure class rather than a hypothetical one, and completion retention for quality monitoring is standard, publicly described practice among foundation-model API providers. P is therefore the correct middle value: demonstrated in research/incident reports, not confirmed against Brightwater's own Orbit Insights deployment.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)LLquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePPagentConfirmed. Completions generated from CRM content necessarily embed personal data (contact details) and commercial terms for customers in 40 countries, and are produced — and potentially logged/retained for quality monitoring — by a foundation-model subprocessor that was not authorised, reviewed or flowed down in any DPA before processing began. Under the rubric's own worked example this is the GDPR Art. 28 case (processing by an un-authorised sub-processor, with unknown retention and transfer jurisdiction for the output artefacts), and it is independently reportable irrespective of any further compromise. The EU AI Act likewise anticipates written agreements specifying information and access between providers and third parties supplying integrated services, which is absent here.
    AU Silent/Automatic TriggerYYagentConfirmed. The completion-generating feature was enabled by default for all users in a routine quarterly release; no per-customer decision, contract amendment or opt-in was involved. Any vendor-side change to how completions are logged, retained or routed to the model provider is a single platform-wide configuration that takes effect for every tenant simultaneously, so the sovereignty-loss event at this dimension is automatable in the rubric's sense.
    R Portability / Exit RecoveryUUagentConfirmed. Summarisation/next-action generation is a commodity capability that Brightwater could reconstitute with another provider, but not without work: re-contracting, re-integration with CRM objects and re-establishing the write-back of derivatives into records. Equally, past completions already persisted in Orbit records (and any copies held by the model provider) would have to be exported or re-generated manually. This is manual migration effort, not automatic reconstitution, and it is not irrecoverable because nothing proprietary to Orbit (e.g. custom weights or org-specific embeddings) is required.
    V Blast-Radius ConcentrationDDagentConfirmed for this category. Although Orbit CRM itself is enterprise-wide, the derivative-producing dependency assessed here is a single feature (Orbit Insights summaries/next-action suggestions) serving one narrow workload; it is not a shared AI control plane on which other Brightwater AI workloads depend. Per the rubric, that is Diffuse. The breadth of the exposure comes from the number of data subjects, which is captured in the impact metrics, not in blast-radius concentration.
    RE Exit / Mitigation EffortMMagentConfirmed. Stopping further completions is near-trivial (an administrator can disable the feature per tenant), but that is suppression of the capability rather than mitigation of the exposure. Durably fixing dimension 3.3 means establishing what the vendor and the foundation-model subprocessor log and retain of the completions, obtaining zero-retention / no-training commitments and a flowed-down DPA, deleting or repatriating already-generated summaries, and running the AI governance review that never triggered — a project involving contract and process work but no re-architecture or infrastructure replacement. That is Moderate, not Low.
    U Vendor Notice PostureAmberRedagent · overrideOverride (prior Red). The questionnaire answer ('does not disclose before they take effect') is consistent with both Red and Amber, so the scenario facts decide: Orbit does operate a disclosure mechanism and used it — the updated subprocessor list naming the foundation-model provider was published on the trust site on the same day the release shipped, and the terms expressly provide notice at the time of release. Per the rubric that is disclosure concurrent with the change taking effect (Amber), not a vendor that never discloses (Red). Confidence is only moderate because the disclosure is concurrent-and-passive (pull from a trust page) and says nothing about the dimension-specific question of completion logging, retention period or jurisdiction, so in practice it gave Brightwater no actionable window — a reviewer preferring Red on that basis would be defensible.
  4. 4 Who's deciding what the AI sees and does?

    4.1 Retrieval pipeline (RAG) ownership · also 4.2, 4.4
    HIGH7.9

    Orbit alone decides which customer records, email threads and call notes are pulled together and sent to the model for each summary, and Brightwater has no visibility into that selection at all. Orbit can change what is selected, how it is ranked, and which party in its chain performs that step, under the same contract clause that lets it change features at its discretion with notice only at release. Because the sales team reads the resulting summaries and suggested next actions as part of the customer record, a quiet change to what the pipeline includes — or quietly leaves out — would produce different, confident-looking conclusions with no signal to Brightwater and nothing to compare against. Brightwater also cannot bound what has already been sent, because it cannot see what the selection step chose.

    Rating HIGH. Brightwater can neither verify nor limit what customer information is handed to the AI, and would not detect a change that silently alters the advice its sales staff act on.

    Evidence: vector, score and 21 metric rationales

    Vector SOV:1.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:H/SI:H/SA:L/E:P/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:D/RE:M/U:Amber Score 7.9 (High)

    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?

    MetricValuePriorSourceRationale
    AV Access PathNNagentThe retrieval/selection stage that chooses which CRM records, email threads and call notes are packaged for the model runs inside Orbit's multi-tenant SaaS cloud and is reached only through Orbit's own service/API; nothing of this stage resides in a Brightwater-managed environment and there is no intermediary between Brightwater and Orbit. That matches the rubric's AV:N 'Network -- vendor-direct API access, no intermediary' (sovereignty_cvss_rubric_1.json). AV:A would apply if access to this stage were mediated by a subprocessor; here the subprocessor (the foundation-model provider) sits downstream of the selection stage rather than in front of it. Confirms the questionnaire prior.
    AC Compulsion ComplexityLLagentOrbit's terms expressly allow feature changes at its discretion with notice only at the time of release, and the retrieval pipeline was changed (and a new subprocessor inserted) under those standard terms alone. There are no customer-managed keys, data-residency carve-outs or contractual gates on what the pipeline may select or where it sends it, so no technical or contractual barrier has to be overcome: AC:L 'a standard ToS clause or routine legal process suffices' (rubric). Confirms the prior.
    AT Trigger ConditionsNPagent · overrideOVERRIDE of the prior (P). The prior reflects legally triggered access to the dependency in general (sanctions, litigation hold, incident). For dimension 4.1 the control at issue is ownership of the selection/packaging stage, and Orbit exercised exactly that control with no triggering event: a routine quarterly release turned Orbit Insights on by default and changed what CRM content is retrieved and fed to a model, under terms that 'allow feature changes at its discretion'. Changes to retrieval scope, ranking or the subprocessor performing it are therefore exercisable at vendor discretion at any time, which is the rubric's AT:N. Lower confidence because the scenario does not describe the pipeline mechanics, so a future change could in principle be event-gated.
    PR Position RequiredNNagentConfirms the prior, with a noted tension. Orbit (the primary contracted vendor) decides what is selected, which alone would read as PR:L; however Orbit can and did insert additional parties into the pipeline unilaterally -- the foundation-model provider appeared on the trust-site subprocessor list the same day the release shipped -- and Brightwater has no visibility into which chain party performs retrieval, ranking or packaging. Any party already in that chain (including a reranking or model subprocessor that receives and can reorder/condition the packaged context before generation) therefore has sufficient standing to affect what reaches the model without needing Brightwater's privileges; that is PR:N in the rubric. Confidence is moderate because the scenario does not state whether a subprocessor other than Orbit touches the retrieval stage itself. The rubric names PR as a primary exploitability metric for 4.1, so this judgement is weight-bearing.
    UI Org Action RequiredNNagentThe retrieval-and-summarisation pipeline was switched on for all users by default in Orbit's own release; Brightwater adopted nothing, its AI governance review never triggered, and it learned of the change only when a sales manager noticed summaries appearing. This is the rubric's canonical UI:N case -- 'vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature)'. The existence of a per-tenant admin disable does not make it UI:A, because the exposure arises without any affirmative Brightwater action. Confirms the prior.
    VC Primary Dependency Impact -- ConfidentialityLNagent · overrideOverride of the questionnaire's 'N' (which described the primary dependency, the foundation-model feature, not this stage). The 4.1 dependency is Orbit's selection-and-packaging stage, and that stage by definition reads and assembles the most sensitive CRM content — contract terms, pricing and personal contact details for customers in forty countries — into model context. Brightwater has zero visibility into which records, threads and call notes are selected, so it cannot even enumerate what was exposed. Impact at the stage itself is nonetheless only partial (L), not total: Orbit is an already-contracted processor that has legitimately held this data for eight years under the enterprise agreement, so the retrieval stage does not create a new reader of the corpus; the total, uncontracted-party confidentiality loss materialises one hop later at the external model provider and belongs in Subsequent Confidentiality, consistent with the rubric placing 4.1's weight on subsequent impact (primary_impact_axis: []).
    VI Primary Dependency Impact -- IntegrityLNagent · overrideOverride of 'N'. Orbit alone owns the retrieval/ranking logic, Orbit's terms allow feature changes at its discretion with notice only at the time of release, and the questionnaire confirms sovereignty-relevant changes (model versions, subprocessors, hosting) are not disclosed before they take effect. Orbit can therefore silently change what the stage selects and how it is ordered — the integrity of this stage's own behaviour is not under Brightwater's control, and the subprocessor-list-on-release-day pattern matches the ATLAS 'AI Supply Chain Rug Pull' precedent of a legitimate component being silently altered post-adoption. I score this L rather than H to avoid double-counting: the rubric explicitly routes the material consequence of altered selection to a later pipeline stage ('Subsequent Integrity impact on a later pipeline stage'), i.e. the summaries and recommended next actions the sales team acts on, which is where total undetected alteration (SI) should be recorded. At the stage itself the loss is a partial, unverifiable loss of assurance over selection, not destruction of the stage's function.
    VA Primary Dependency Impact -- AvailabilityNNagentConfirms the prior. Orbit can enable, degrade or withdraw the Insights retrieval pipeline unilaterally (it was switched on by default in a quarterly release and is tenant-disableable), but loss of that stage does not remove any capability Brightwater owns at this node: the underlying CRM and its record search continue to operate, the questionnaire states the component could keep operating / is not needed to keep operating, and the dependency supports one narrow workload reconstitutable with moderate migration effort. The operational consequence of withdrawal is degradation of downstream workloads (the summary/next-action workflow), which the questionnaire records as 'some downstream workloads degrade' and which belongs in Subsequent Availability, not at the vulnerable system. Rubric support: 4.1 carries no primary impact axis and is scored through subsequent impact.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentThe 4.1 exposure is that Orbit alone decides which CRM records, email threads and call notes are selected and packaged for the model. Whatever that selection stage pulls in is, by construction, forwarded out of the tenant boundary to a third-party foundation-model provider that appeared on the subprocessor list the same day the release shipped and that Brightwater never contracted with or reviewed. The candidate corpus is contract terms, pricing and personal contact details for customers in forty countries, so the downstream recipient can receive near-total exposure of the sensitive record set; Brightwater has no visibility into retrieval scope, so it cannot even bound what left. This matches the rubric's own characterisation of the subsequent-impact group as the metric that expresses sovereignty loss compounding into parties beyond the primary vendor (rubric: subsequent_system_impact note; cf. dimension 3.1 'textbook Subsequent Confidentiality impact, since the embedding vendor was never the org's contracted AI vendor'). Confirms the questionnaire prior of 'Full: sensitive data becomes readable by a party we never contracted with'.
    SI Downstream Blast-Radius Impact -- IntegrityHHagentThe rubric flags 4.1 as subsequent_impact_relevant with the explicit note that 'a reranking vendor can alter what gets fed to the model -- Subsequent Integrity impact on a later pipeline stage'. Here the later stages are the generated summary and the suggested next action that the sales team acts on. Because selection and packaging are wholly vendor-controlled, unassessed and changeable at Orbit's discretion with notice only at release time, a silent change in which threads, call notes or records are retrieved (or omitted) propagates into materially different summaries and recommendations with no signal to Brightwater and no ground truth to compare against — the condition SR 11-7 describes for vendor components whose internals are not visible to the user, where the user cannot validate inputs/assumptions and must fall back on benchmarking it is not doing here. Omission is as integrity-relevant as alteration: a summary built from a truncated or mis-ranked record set looks authoritative while being wrong. Downstream decisions are therefore altered without detection, which is total loss on this axis. Confirms the prior.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentIf the retrieval stage stops returning records or is withdrawn, the downstream effect is that summaries and suggested next actions degrade or disappear. The underlying email threads, call notes and CRM records remain available in Orbit and the sales process reverts to reading them manually; the questionnaire confirms only 'some downstream workloads degrade', that the capability itself could be kept operating, that a single narrow workload depends on it, and that reconstitution is a moderate migration project rather than a re-architecture. That is partial, not total, downstream availability loss. S (Safety) is not warranted: Brightwater is a consumer-brands manufacturer and the affected output is a sales summary and a recommended next action — no physical harm or safety-relevant failure mode is described. Note the regulatory exposure flagged in the questionnaire ('would trigger a reportable regulatory violation') belongs on the supplemental Regulatory Consequence metric (rubric: supplemental S), not on SA, so it does not push SA to S. Confirms the prior.
    E Precedent MaturityPXagent · overrideOverride of the questionnaire's X (which reflected the respondent's "Unknown" answer about precedent, i.e. absence of knowledge rather than absence of evidence). The corpus contains concrete, published demonstrations of exactly this exposure class — a vendor-owned retrieval/selection stage inside a SaaS product deciding what content is packaged for the model, with the resulting summary or recommended action being wrong in a way the user cannot see. Slack AI (AML.CS0035), M365 Copilot transaction hijacking (AML.CS0026) and EchoLeak (AML.CS0059) are all directly analogous to Orbit Insights summarising CRM threads and call notes, and all are typed "Exercise → CASE Precedent Maturity E:P"; the underlying ATLAS techniques (T0064, T0066, T0070) are likewise rated "Demonstrated → E:P". That rules out U (theoretical only). It does not reach A: every retrieved case is a researcher red-team exercise, none is a confirmed real-world exercise of this control against a comparable enterprise, Brightwater has no visibility into Orbit's selection mechanics to confirm it against its own stack, and the questionnaire reports precedent as Unknown. Confidence is moderate rather than high because the precedents are adversary-driven security exercises whereas the 4.1 sovereignty concern here is unilateral vendor/subprocessor control of the same stage — the same mechanism, a different actor, so the mapping is close but not exact.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)LLquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePPagentConfirmed. The retrieval stage Orbit owns is what actually selects and packages CRM content — contract terms, pricing and personal contact details for data subjects in forty countries — and ships it to a foundation-model provider that appeared on the subprocessor list only on the day the release went live. Under GDPR Art. 28(2)/(3)(d) a processor may not engage a new sub-processor without prior authorisation/notice giving the controller an opportunity to object; a selection stage that silently routes personal data to an uncontracted party is therefore an independently reportable compliance failure for Brightwater as controller, independent of any security breach. The EU AI Act likewise places value-chain information duties on upstream suppliers towards the integrating provider (recital 88), reinforcing that undisclosed pipeline composition is a regulatory, not merely technical, defect. The questionnaire also answers 'Yes' to an independent reportable violation.
    AU Silent/Automatic TriggerYYagentConfirmed. Orbit Insights — and with it the vendor-side retrieval/packaging stage — was switched on in a routine quarterly release, on by default for all users, with no per-tenant or per-customer decision. The same release therefore changed what gets selected and fed to a model simultaneously across Orbit's entire customer base; Brightwater discovered it only because a sales manager noticed summaries appearing. This is the definition of a sovereignty-loss event occurring at once across all customers with no case-by-case action.
    R Portability / Exit RecoveryUUagentConfirmed as User (manual migration). Brightwater owns the underlying records (CRM data is exportable under its eight-year enterprise agreement), so the capability 'select relevant threads/call notes and summarise them' can be reconstituted outside Orbit — but only by standing up its own retrieval layer: export/extract, re-index or re-embed the CRM corpus, rebuild selection and ranking logic, and re-contract a model provider. Nothing in the scenario indicates the retrieval artefacts (indexes, rankers, selection heuristics) are retrievable from Orbit, so recovery is not automatic; equally, nothing indicates the capability is impossible without Orbit, so not Irrecoverable. Matches the questionnaire's 'manual migration effort (re-embedding, re-integration, re-contracting)'.
    V Blast-Radius ConcentrationDDagentConfirmed as Diffuse. The vendor-owned retrieval stage assessed here serves a single AI workload — Orbit Insights thread/call-note summarisation and next-action suggestions. It is not a shared control plane across Brightwater's AI estate, and the questionnaire reports only one narrow workload depending on it. Note the tension: the stage has reach across the whole CRM corpus (forty countries) and sits in the critical path of every downstream Insights output, but that breadth is captured by the subsequent-impact metrics (SC/SI), not by blast-radius concentration across AI workloads. Confidence is moderate because the scenario does not describe whether Orbit reuses this retrieval layer for other AI features Brightwater may later consume.
    RE Exit / Mitigation EffortMMagentConfirmed as Moderate. There is a cheap stop-gap — an administrator can disable the feature per tenant, which halts the vendor-side selection and packaging immediately — but that removes the capability rather than mitigating the exposure. A durable fix means either re-contracting (prior-notice and sub-processor-approval terms Orbit's current ToS explicitly does not offer, since it permits feature changes at its discretion with notice at release) or bringing retrieval in-house over exported CRM data. That is a project with re-indexing and re-integration work, but it does not require re-architecting Brightwater's core platforms or replacing physical infrastructure, so it falls short of High.
    U Vendor Notice PostureAmberRedagent · overrideOverride Red -> Amber. The questionnaire answer ('does not disclose before they take effect') is consistent with both Red and Amber, but the scenario gives the more precise fact pattern: the updated sub-processor list naming the foundation-model provider was published on Orbit's trust site the same day the release shipped, and Orbit's terms allow feature changes at its discretion 'with notice at the time of release'. Disclosure therefore occurred concurrently with the change taking effect — the rubric's Amber definition — rather than never occurring (Red). This is still a failure posture for governance purposes: concurrent notice gave Brightwater's AI review process no opportunity to intervene before CRM content began flowing through a vendor-owned retrieval stage to a new party. It is not Green or Clear because there is no advance notice and no contractual guarantee of any.
  5. 5 Which humans are actually looking at our stuff?

    5.1 Human review processes · also 5.3
    MEDIUM5.3

    Nothing in Orbit's disclosure tells Brightwater whether people — rather than only software — read its customer content once it reaches the model provider. Model providers commonly have staff sample prompts and outputs for quality, safety or abuse review, and because this provider was never assessed and no agreement rider was negotiated, Brightwater holds no commitment that no human sees its material, no limit on who may see it and no statement of where those reviewers are located. The content at risk is raw email threads and call notes containing named contact details, pricing and contract terms for customers in forty countries. This exposure is inferred from the absence of any disclosed policy rather than evidenced, but Brightwater currently has no basis on which to rule it out.

    Rating MEDIUM. Brightwater cannot tell a customer or regulator whether a stranger's staff have read their emails and call notes, because no one ever asked the question of the model provider.

    Evidence: vector, score and 21 metric rationales

    Vector SOV:1.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:L/SA:L/E:P/CR:H/IR:M/AR:L/S:P/AU:N/R:U/V:D/RE:M/U:Red Score 5.3 (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?

    MetricValuePriorSourceRationale
    AV Access PathANagent · overrideOverride of the questionnaire prior (N). The prior describes the primary dependency — Orbit CRM, which Brightwater reaches directly over Orbit's API in Orbit's cloud. Category 5.1, however, concerns a human being at the other end of the pipeline: a reviewer at the third-party foundation-model provider that appeared on Orbit's subprocessor list the day the release shipped. That party does not have vendor-direct access to Brightwater's tenant; it receives email threads and call notes forwarded to it by Orbit, i.e. its sight of the data is mediated by the primary contracted vendor. Per the rubric, 'A = Adjacent -- subprocessor-mediated access' is the matching value (sovereignty_cvss_rubric_1.json, exploitability.AV). Confidence is moderate because the retrieved corpus contains no evidence of the model provider's actual reviewer access arrangements — the subprocessor was never assessed.
    AC Compulsion ComplexityLLagentConfirmed. Nothing has to be overcome for a human at the subprocessor to see this content: Orbit's terms permit feature changes at its discretion with notice only at release time, the content was routed to the model provider under Orbit's own subprocessor terms, and because Brightwater's AI governance review never triggered there is no negotiated DPA rider, customer-managed key, data-residency carve-out or no-human-review commitment standing in the way. That is the rubric's 'L = Low -- a standard ToS clause or routine legal process suffices' (sovereignty_cvss_rubric_1.json, exploitability.AC).
    AT Trigger ConditionsNPagent · overrideOverride of the prior (P). The prior's triggering events (sanctions designation, litigation hold, incident, product decision) describe compelled or discretionary action against the primary vendor. Human review at a model provider is ordinarily a standing practice — quality sampling, abuse/safety review and evaluation of retained prompt-and-completion logs — exercisable whenever the provider chooses, rather than something gated on a discrete external event. Since the provider was never assessed, Brightwater holds no commitment that review is limited to flagged or incident cases, so the exposure must be scored as available at the provider's discretion at any time: 'N = None -- control can be exercised at vendor discretion at any time' (sovereignty_cvss_rubric_1.json, exploitability.AT). Confidence is low-moderate: this is inferred from the absence of any disclosed review policy rather than evidenced, and a flag-triggered-only review regime (P) remains possible.
    PR Position RequiredNNagentConfirmed, and this is the metric the rubric flags as carrying 5.1 (primary_exploitability: ['PR'] for node 5.1 'Human review processes'). The foundation-model provider is already a named entity in Orbit's subprocessor chain, so its staff need no additional standing, no primary-vendor status and no compromise of Brightwater's administrative credentials to view the summarised customer emails and call notes: 'N = None -- any party already in the subprocessor chain has sufficient standing' (sovereignty_cvss_rubric_1.json, exploitability.PR).
    UI Org Action RequiredNNagentConfirmed. The rubric's 'N' value is defined to include exactly this fact pattern — 'vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature)' (sovereignty_cvss_rubric_1.json, exploitability.UI). Orbit Insights was enabled by default in a routine quarterly release, the new foundation-model subprocessor was added the same day, and Brightwater took no affirmative step — no one adopted anything, which is precisely why the AI governance gate never fired. Although the data only reaches a human reviewer once sales staff use the mailbox and call-note features (which would argue for P/Passive), the decision that exposed the content to a new human-review path was taken unilaterally by the vendor and its subprocessor, so N is the correct scoring.
    VC Primary Dependency Impact -- ConfidentialityLNagent · overrideOverride of the questionnaire's 'N'. The prior answers the primary (technical/subprocessor-residency) dependency; for 5.1 the dependency under assessment is the human-review path itself, where the loss mechanism is a person at Orbit or the undisclosed foundation-model provider reading raw Brightwater content. Because the model provider was never assessed and Orbit does not disclose subprocessor/feature changes before they take effect, its retention, abuse-monitoring and quality-review practices are unknown, and no written arrangement constrains staff or subcontractor access — exactly the gap third-party risk guidance says must be closed contractually when PII is handed to a third party and its subcontractors (interagency-third-party-risk-guidance-2023.md), and the kind of strict, documented, 'authorised persons only' access control the AI Act expects where personal data is processed (eu-ai-act-2024-1689.md). The content at stake is sensitive (pricing, contract terms, personal contact details, 40 jurisdictions) and loss would be reportable. It is scored L rather than H because any such review is sampling-based and bounded to the one narrow summarisation workload's prompts/outputs, not the CRM corpus as a whole, and the path is inferred rather than evidenced; confidence is correspondingly moderate.
    VI Primary Dependency Impact -- IntegrityNNagentConfirms the prior. A human reviewer in an abuse-, safety- or quality-sampling role observes content; nothing in the scenario indicates such reviewers can write back to Brightwater's CRM records or alter the summaries Brightwater sees. Review-derived labelling could in principle influence future model behaviour, but that is speculative and would be an upstream model-change issue rather than an integrity loss at this human-review dependency. No evidence of modification capability, so N.
    VA Primary Dependency Impact -- AvailabilityNNagentConfirms the prior. A human review process does not withdraw or degrade the capability Brightwater relies on; at most a content-policy decision could suppress individual summaries. Orbit Insights is a non-essential, default-on convenience feature over a single narrow workload that an administrator can switch off, and the eight-year-old CRM itself keeps operating regardless, so there is no availability loss attributable to this dimension.
    SC Downstream Blast-Radius Impact -- ConfidentialityLHagent · overrideOVERRIDE H -> L. The questionnaire's 'Full: sensitive data becomes readable by a party we never contracted with' describes the primary dependency (the undisclosed foundation-model subprocessor ingesting Orbit CRM email threads and call notes). For dimension 5.1 that total loss is the *primary* axis (VC), not a subsequent one: the rubric records 5.1 with primary_impact_axis ['VC'] and subsequent_impact_relevant=false, and reserves the subsequent group for genuinely multi-hop dimensions (3.1/3.2/5.2, Category 7). Residual downstream loss is nonetheless not zero and not merely theoretical: abuse/quality review at foundation-model providers is routinely sub-outsourced to further review contractors who were never named on Orbit's trust site, so contract terms, pricing and personal contact details for customers in forty countries could be re-read one hop further out, and anything a human has read cannot be clawed back by tenant-level feature disablement. That is partial, not near-total, propagation -> L. Confidence is limited because the scenario states nothing about the provider's review practices (they were never assessed), consistent with the classifier's 'live but unconfirmed exposure'.
    SI Downstream Blast-Radius Impact -- IntegrityLHagent · overrideOVERRIDE H -> L. The prior ('downstream systems act on altered outputs without detection') is a sound reading of the silently enabled summarisation feature as a whole, but it attaches to the model/output dimensions (1.x, 3.3), not to a human-review path. Reading data does not by itself alter Brightwater's records or downstream decisions. The limited-but-real integrity channel is indirect: reviewer-generated flags, corrections or quality feedback can reshape how summaries and 'suggested next actions' are produced, and Brightwater's sales staff act on those suggestions with no governance review and no pre-notification of changes (Orbit 'does not disclose them before they take effect'). Systematic reviewer-driven retraining of outputs would belong to 5.2 (annotation/labeling, where the rubric does mark subsequent impact relevant); for 5.1 the propagating effect is partial -> L rather than H, and not N because an unreviewed, undisclosed review loop is uncontrolled.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentCONFIRM L. Consistent with the questionnaire ('some downstream workloads degrade') and with the narrow scope of the exposure: Orbit Insights is one feature inside a CRM Brightwater has run for eight years, and the capability can be reconstituted with manual migration effort. The plausible availability path from a human-review process is an abuse-review or policy decision at the undisclosed model provider suspending or throttling summarisation for the tenant, which degrades the summarise/next-action workflow for sales users while the CRM of record keeps operating -> partial, not total, downstream availability loss. Not S: Brightwater is a consumer-brands manufacturer and the affected workload is sales-note summarisation, with no physical-harm or safety-relevant failure mode (the regulatory consequence of this scenario is captured by the supplemental S/Regulatory Consequence metric, not by SA=Safety).
    E Precedent MaturityPXagent · overrideOverride of the questionnaire's X (and of the questionnaire's 'Unknown' answer to whether this control has been exercised), but only as far as P, not A. The rubric defines E:P as 'demonstrated in research/incident reports, not confirmed against this org's own stack' and E:A as requiring 'documented real-world cases of this control being exercised against comparable orgs' (s3://.../sovereignty_cvss_rubric_1.json, threat.metrics.E); the ATLAS mapping note confirms CASE's convention that only Realized/Incident-grade documentation supports E:A, while Demonstrated-grade evidence maps to E:P (s3://.../atlas/README.md). For dimension 5.1 the exposure is a human at the undisclosed foundation-model subprocessor seeing raw Orbit CRM content (contract terms, pricing, personal contact data for 40 countries) through quality/abuse review. Human review of customer content by provider staff or contractors is a well-known, publicly reported industry practice (vendor abuse-monitoring and transcription/'grading' review programmes), and the EU AI Act itself presumes named natural persons are assigned to review AI system operation and that their identity be logged (s3://.../eu-ai-act-2024-1689.md, Art. 14 and Annex IV human-oversight provisions), i.e. a human review path is an expected, documented feature of such services rather than a purely theoretical one — which rules out U ('theoretical only'). However, no retrieved source documents this review path actually being exercised on a comparable enterprise CRM tenant, the model provider was never assessed by Brightwater, Orbit does not disclose subprocessor/feature changes before they take effect, and the scenario states nothing about who reviews Brightwater's summaries. So the precedent is generic-industry, not org-specific or comparable-org-documented: P. Note the corpus returned no case study or incident report specifically on subprocessor human review of enterprise data, so this value rests on the rubric definitions plus the scenario and is held at low-to-moderate confidence, consistent with the classifier's own note that 5.1 here is 'inferred rather than evidenced'.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)LLquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePPagentConfirms the prior. If staff at the undisclosed foundation-model provider (or Orbit) can read raw email threads and call notes, the material seen is personal contact data plus contract and pricing terms for customers in forty countries. Human eyes at a party Brightwater never contracted with is, on its own, an independently reportable event: processing by an unauthorised (sub)processor outside the controller's instructions and documented chain (GDPR Art. 28(2)-(3)), with notification/breach exposure under Arts. 33-34 and transfer exposure under Chapter V if reviewers sit outside the EEA. The EU AI Act reinforces that the deployer/provider split carries its own documentation and transparency duties for an AI system put into service in this way (Arts. 13, 14, 50; recital 73), so the governance gap is not merely contractual hygiene. Scenario-specific aggravator: Brightwater's own AI governance review never ran, so no DPIA or Art. 28 assessment exists to rely on.
    AU Silent/Automatic TriggerNYagent · overrideOverrides the prior for this category. The prior 'Y' correctly describes the primary dependency: Orbit flipped Insights on for every tenant at once, and data routing to the model provider required no per-customer decision. But the loss event in 5.1 is a human being reading organisation data, and that is intrinsically a discrete act: a reviewer opens a flagged sample, a quality-rating task, or a specific ticket. Even a blanket retention-for-review policy only creates the precondition; the exposure materialises record by record and cannot be executed simultaneously across all customers the way an automated pipeline change can. Confidence is only moderate because the provider's review practices are undisclosed, so a wholesale 'all traffic sampled for human rating' configuration cannot be excluded; if that were evidenced, Y would be correct.
    R Portability / Exit RecoveryUUagentConfirms the prior. Control over the human-review path can be re-established without the original vendor's permission but not for free: an administrator can disable Insights per tenant immediately, yet restoring a governed state requires manual work — re-contracting or amending the DPA with Orbit, obtaining named-subprocessor and no-human-review/zero-retention commitments, and re-running the skipped AI governance review; if Brightwater instead wanted reviewed summarisation elsewhere, that is a migration project on top of an eight-year global CRM agreement. Not A, because nothing reconstitutes automatically and the governance posture is not self-healing. Not I, because the capability (thread summarisation) is commodity and obtainable from other suppliers. Note separately that any data already seen by human reviewers is unrecoverable, but R scores capability reconstitution, not data recall.
    V Blast-Radius ConcentrationDDagentConfirms the prior, with a caveat. Functionally the foundation-model provider sits behind exactly one narrow workload — summarising email threads and call notes and suggesting next actions. It is not a shared control plane for Brightwater's other AI workloads, and its failure or withdrawal would not cascade into unrelated AI systems (the questionnaire itself records 'None: we could keep operating this component'). The countervailing argument is data concentration rather than workload concentration: because the feature was on by default for all users, the single review path can see CRM content for the whole customer base across forty countries. That breadth is already captured on the confidentiality impact axes (VC/SC) rather than here, so D remains the correct reading of this metric's definition. Confidence moderate because an assessor weighting value density by data richness rather than workload count could defensibly choose C.
    RE Exit / Mitigation EffortMMagentConfirms the prior. The technical half of the fix is trivial (tenant-level admin toggle), but closing the 5.1 exposure properly is a project rather than a switch: Orbit must be pressed to disclose the model provider's abuse/quality-review and retention practices, contractual language must be added to constrain human access and subprocessor changes, and the terms currently permit Orbit to change features at its discretion — so the leverage must come from re-contracting under the enterprise agreement. No re-architecture of Brightwater's systems and no infrastructure replacement is required, which rules out H; the need for legal negotiation with a vendor holding an eight-year incumbency rules out L.
    U Vendor Notice PostureRedRedagentConfirms the prior for this dimension. Orbit gave no advance notice of anything: the subprocessor list was updated on the trust site the same day the release shipped, and the terms expressly allow feature changes at Orbit's discretion with notice only at time of release — a posture Brightwater cannot rely on to trigger a pre-adoption review. For 5.1 specifically it is stronger than 'concurrent': what was published was a name on a list, while the sovereignty-relevant facts for human review — whether the model provider retains prompts for abuse or quality review, who may read them, and in which jurisdiction — were never disclosed at all, before or at the change. Amber was considered because of the same-day trust-site posting, which is why confidence is moderate rather than high; it is rejected because concurrent publication of a subprocessor's identity is not disclosure of the human-review change itself and offers no window for objection.
  6. 6 Who's holding the steering wheel?

    6.4 Configuration and policy management · also 6.1
    HIGH7.9

    The decisive decision in this whole episode was a settings decision that Brightwater did not make: Orbit shipped Orbit Insights switched on for every user, and the only control Brightwater has is to switch it off per tenant after the fact. Brightwater's own rule — that no AI service may be used until it has passed a governance review — was effectively overridden, and the governance record now says no AI service was adopted while an AI service was live in production across the business. The administration console did not proactively surface the change, so Brightwater had no monitoring that would have caught it; discovery came from a sales manager's question. Orbit applied the same default to its whole customer base at once, with no case-by-case decision and no opportunity to object.

    Rating HIGH. Brightwater's AI governance policy can be overridden by a vendor release note, and its own compliance records will not show it happened.

    Evidence: vector, score and 21 metric rationales

    Vector SOV:1.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:H/SI:H/SA:L/E:A/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:C/RE:M/U:Amber Score 7.9 (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?

    MetricValuePriorSourceRationale
    AV Access PathNNagentConfirms the prior. The configuration object that matters here — the tenant-level enable/disable state of Orbit Insights — is stored and evaluated inside Orbit's own multi-tenant SaaS control plane and reached directly over Orbit's service/API; nothing resides in a Brightwater-managed environment. Per the rubric, AV:N = 'Network -- vendor-direct API access, no intermediary' (sovereignty_cvss_rubric_1.json, exploitability.AV). Orbit needed no intermediary and no customer-side presence to flip the default on in a routine quarterly release.
    AC Compulsion ComplexityLLagentConfirms the prior. Rubric AC:L = 'a standard ToS clause or routine legal process suffices'. The scenario states outright that 'Orbit's terms allow feature changes at its discretion with notice at the time of release' — the existing eight-year enterprise agreement is itself the whole authorisation. There are no customer-managed keys, no change-approval gate, no data-residency or configuration-freeze carve-out that Orbit had to overcome before altering the default policy state for Brightwater's tenant. AC:H would require such a barrier to exist.
    AT Trigger ConditionsNPagent · overrideOVERRIDES the prior P. The questionnaire prior bundles 'product decision' in with sanctions/litigation/incident triggers, but the rubric defines AT:P as requiring 'a specific triggering event' and AT:N as 'control can be exercised at vendor discretion at any time'. For this dimension the control event was a default-state configuration change made in a *routine* quarterly release under terms that 'allow feature changes at its discretion'. Discretion exercisable at any release boundary is the definition of no trigger condition, not a trigger. This is reinforced by the questionnaire's own answer that the event 'could happen to all of the vendor's customers at once, with no case-by-case decision' (rubric supplemental AU:Y) — a conditioning event would require case-by-case evaluation. ATLAS AML.T0081, the rubric's taxonomy anchor for 6.4, likewise describes configuration changes that persist and propagate to everything sharing the configuration without any precondition.
    PR Position RequiredLNagent · overrideOVERRIDES the prior N. The prior (N = 'any party already in the subprocessor chain has sufficient standing') is correct for the primary category (7.2 / the foundation-model subprocessor, which sees the data by virtue of being in the chain). But 6.4 asks who can *change the configuration and policy state*. The default-on switch, the subprocessor list, and the per-tenant disable control are all held by Orbit as the primary contracted platform operator; the third-party foundation-model provider has no standing to enable a feature in Brightwater's CRM tenant or to alter Orbit's release defaults. That matches PR:L = 'requires being the primary contracted vendor'. PR:H is excluded because no Brightwater administrative credential was compromised or needed — Orbit acted from its own platform position.
    UI Org Action RequiredNNagentConfirms the prior, and this is the metric that carries the dimension (rubric lists UI first in 6.4's primary_exploitability). The rubric's N definition names this exact fact pattern: 'None -- vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature)'. Orbit Insights 'was on by default for all users'; Brightwater's AI governance review 'never triggered because no one in the organisation adopted anything', and the change was discovered only when a sales manager noticed summaries appearing. UI:A is excluded because there was no opt-in or accepted update; UI:P understates it because the exposure was created by the vendor's configuration decision, not merely by Brightwater's ordinary use of the CRM.
    VC Primary Dependency Impact -- ConfidentialityNNagentThe 'primary dependency' for this category is the configuration/policy-management plane itself (Orbit's feature-flag and default-state machinery plus the tenant admin console), not the CRM data store. Nothing in the scenario indicates that configuration or policy state, admin credentials, or guardrail settings were exposed to an unauthorised party at that plane: Orbit changed a default it already legitimately controlled, and the subprocessor list was published openly on its trust site. The real confidentiality loss -- customer contract terms, pricing and personal data for 40 countries becoming readable by a foundation-model provider Brightwater never contracted with -- occurs downstream of the configuration event and belongs to the subsequent-system axis (rubric: subsequent_system_impact, 'loss propagating beyond the named dependency'), consistent with the questionnaire answer 'Full: sensitive data becomes readable by a party we never contracted with' for beyond-the-dependency confidentiality. Confirms the questionnaire prior of N for the dependency itself.
    VI Primary Dependency Impact -- IntegrityHNagent · overrideOverride of the prior (which describes the primary dependency, the AI summarisation service, rather than the control plane). At the configuration/policy plane the integrity loss is total: Orbit unilaterally set the effective state of an AI feature for all users in Brightwater's tenant, with notice only at the time of release, and Orbit's terms reserve that discretion. Brightwater's authoritative policy state (its rule that no AI service is adopted without governance review) was overwritten without its knowledge or consent -- the governance gate 'never triggered because no one in the organisation adopted anything'. The rubric anchors ATLAS AML.T0081 'Modify AI Agent Configuration' to dimension 6.4; that technique describes exactly this failure mode -- a configuration change that is made outside the owner's control, persists, and 'affects any agents that share the configuration', with mitigations framed as change approval, integrity monitoring and restoration from trusted configurations. Here the vendor holds the default-state switch and exercised it across its whole customer base, so the organisation's control over its own policy configuration is near-totally lost, not partially.
    VA Primary Dependency Impact -- AvailabilityLNagent · overridePartial rather than no loss. Brightwater retains a working configuration lever -- 'the feature can be disabled per tenant by an administrator' -- so the control plane is not withdrawn and the organisation can keep operating (consistent with the prior's 'we could keep operating this component'). But that lever is only reactive and coarse: it exists after the fact, at whole-tenant granularity, with no pre-release opt-out, no per-user or per-data-class scoping, and no proactive surfacing of the change (the vendor 'does not disclose them before they take effect'; Brightwater learned of it only when a sales manager asked). The function the configuration plane is supposed to provide -- enforcing the organisation's own policy at the moment of change -- was unavailable when it mattered, which is a limited, not total, degradation. Assigned with moderate confidence; a reviewer who treats timing/granularity limits purely as an integrity-of-control issue could justify N.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentCONFIRMED. The configuration control plane itself holds no customer data, so the entire confidentiality consequence of the 6.4 exposure lands downstream. The default-on switch, flipped unilaterally by Orbit, routed contract terms, pricing and personal contact details for customers in forty countries to a third-party foundation-model provider that appeared on the subprocessor list the same day the release shipped -- a party Brightwater never contracted with, never assessed, and whose involvement its AI governance review never evaluated because 'no one in the organisation adopted anything'. This matches the questionnaire's 'Full: sensitive data becomes readable by a party we never contracted with' and the respondent's confirmation that loss of control here would, on its own, trigger a reportable regulatory violation. The EU AI Act's value-chain provisions (Art. 25, recitals 88-90) treat insertion of a third-party model supplier into an already-deployed system as an event requiring written arrangements and information flow to the deploying organisation, and the Act expressly leaves the organisation's GDPR controller obligations intact regardless of the vendor's unilateral act -- so the disclosure is not merely broad but legally consequential. ATLAS AML.T0081 (the corpus's own anchor for dimension 6.4) notes that configuration changes 'affect any agents that share the configuration' and can 'redirect outputs ... to malicious services', confirming that a single default-state change propagates to the full data population rather than a sample. Total loss on this axis: H.
    SI Downstream Blast-Radius Impact -- IntegrityHHagentCONFIRMED, with the caveat noted below. Two downstream integrity effects compound. (1) Output integrity: AI-generated summaries and 'next action' suggestions were injected into every customer email thread and call note for all users, unvalidated and unlabelled, and staff consumed them as part of the customer record -- the questionnaire's 'Full: downstream systems act on altered outputs without detection'. The detection claim is evidenced directly by the scenario: the only reason Brightwater learned of the change was a sales manager asking why summaries were appearing, i.e. there was no detection path at all. ATLAS AML.T0130/CS0072 establishes the recognised harm pattern -- unnoticed alteration of assistant outputs 'degrades the integrity and trustworthiness of the assistant's responses on topics the user may rely on ... without the user being aware that the advice has been skewed'. (2) Policy-state integrity, which is the 6.4-specific axis: the authoritative configuration governing whether an AI system processes Brightwater's customer data was changed by a party outside Brightwater, and Brightwater's own control record (its mandatory pre-adoption AI review) was rendered false -- the governance artefact says no AI service was adopted while an AI service was in production. Per AML.T0081, such changes 'persist' and affect everything sharing the configuration. Caveat lowering confidence to 0.7: the summaries are advisory and a human reads them, so an assessor could argue partial (L) rather than near-total loss. I retain H because the alteration was tenant-wide, undetected, and simultaneously corrupted the governance record that is the subject of this dimension.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentCONFIRMED. Availability is the weakest downstream axis for this dimension. The configuration lever cuts both ways but is bounded: an administrator can disable Orbit Insights per tenant, and the underlying CRM -- eight years of records under a global enterprise agreement -- keeps running either way. The questionnaire's own answers are consistent: 'None: we could keep operating this component' at the dependency, and only 'Some downstream workloads degrade' beyond it. The realistic degradation is that remediation (switching the feature off, or suspending use pending the governance review that never ran) removes summarisation and next-action support from sales workflows that had silently begun depending on it, and the capability is reconstitutable elsewhere with manual migration effort. That is partial, not total, loss: L. S is not warranted -- this is consumer-brands CRM summarisation of email threads and call notes, with no actuation, no physical process, and no safety-relevant decision in the downstream path, so no availability failure here could cause physical harm.
    E Precedent MaturityAXagent · overrideOverride of the questionnaire's X (and of the 'Unknown' answer to 'has this kind of control actually been exercised against organizations like yours'). The rubric defines E:A as 'documented real-world cases of this control being exercised against comparable orgs' (sovereignty_cvss_rubric_1.json, threat.metrics.E). For dimension 6.4 the control in question is the vendor's unilateral hold on the default-state switch for AI configuration/policy — and in this scenario that control has already been exercised, not merely postulated: Orbit shipped Orbit Insights in a routine quarterly release 'on by default for all users', added the foundation-model subprocessor to its trust site the same day, and Brightwater only learned of it when a sales manager noticed summaries appearing. The same release reached Orbit's entire tenant base simultaneously with no case-by-case decision (consistent with the questionnaire's 'Yes' to the all-customers-at-once question), so comparable enterprise tenants were subject to the identical configuration decision. That is a realized event rather than a research demonstration, which is what separates E:A from E:P. Supporting corpus context: CASE maps ATLAS 'Realized/Incident' to E:A and 'Demonstrated/Exercise' to E:P (atlas/README.md); the ATLAS anchor for 6.4, AML.T0081 'Modify AI Agent Configuration', is rated Demonstrated→E:P, but that entry covers *adversarial* modification of agent configuration, whereas the sovereignty control here is the legitimate vendor exercising a discretionary default-state change under terms that 'allow feature changes at its discretion with notice at the time of release' — and that exercise is a matter of record in this scenario. Residual uncertainty (hence 0.82 rather than higher) is only about how widely documented the pattern is beyond Brightwater's own instance; the exposure at this org's own stack is nevertheless confirmed, which the rubric treats as stronger than P ('not confirmed against this org's own stack').
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)LLquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePPagentConfirmed. The configuration event itself — a vendor-side default-on switch that started routing CRM content (contract terms, pricing, personal contact details for data subjects in forty countries) to a newly added third-party foundation-model subprocessor, disclosed on the trust site the same day the release shipped — is independently reportable. As controller, Brightwater had no prior opportunity to object to or authorise the new subprocessor and no DPIA/review before processing began (its own AI governance gate never fired). That is an Art. 28 processor/sub-processor authorisation and instruction failure and an Art. 35/Art. 5 purpose-limitation exposure on its face, irrespective of any further misuse. The EU AI Act transparency/deployer-oversight duties (Art. 50, deployer obligations and human-oversight provisions) also attach to an AI feature that was in production without the deployer knowing it existed, so a second regulatory trigger is plausible. Hence Present.
    AU Silent/Automatic TriggerYYagentConfirmed, and this is the defining fact for 6.4 here. The sovereignty-loss event was a default configuration state set in a routine quarterly release and applied 'on by default for all users' — a single platform-wide release decision, with no per-tenant, per-customer or per-user decision step. Every Orbit tenant with equivalent data was placed in the same state at the same moment. The rubric's analogue for vendor-side configuration change affecting every consumer of a shared configuration is exactly this (ATLAS AML.T0081, anchored to dimension 6.4: a configuration change 'affects any agents that share the configuration').
    R Portability / Exit RecoveryUUagentConfirmed as User. Recovery of the governance posture is not automatic: it requires a deliberate human act by a tenant administrator (locating the setting and disabling Orbit Insights per tenant, after the fact), plus retrospective work — identifying what was summarised, what left to the model provider, and whether deletion can be obtained. The underlying capability is not irrecoverable: the feature can be switched off and the CRM/AI-summarisation capability could in principle be reconstituted with another vendor, albeit through manual migration and re-contracting of an eight-year global enterprise agreement. What Brightwater cannot reconstitute is the default-state switch itself (that stays with Orbit), but that argues for the Exit Effort and Notice metrics rather than Irrecoverable here.
    V Blast-Radius ConcentrationCDagent · overrideOVERRIDE of the questionnaire's Diffuse. The prior describes the primary dependency (one narrow summarisation workload); this category is the configuration/policy plane, which is shared. The mechanism exercised — vendor-held default-state control over AI features in the CRM release train — sits in the critical path for every user and every record in the platform: it was enabled 'for all users', across customer records spanning forty countries, and the same mechanism can turn on any future AI feature or re-point it to a new model subprocessor without Brightwater acting. The rubric treats the control plane dimensions as the canonical V=Concentrated hook (6.1 'affects every downstream AI workload the org runs', supplemental_hook 'V (Value Density -- Concentrated)'), and 6.4 shares that plane; ATLAS AML.T0081 makes the same point for shared configuration.
    RE Exit / Mitigation EffortMMagentConfirmed Moderate. The immediate mitigation is cheap (an administrator toggles the feature off per tenant), but that is not a durable fix: Orbit's terms permit feature changes at its discretion with notice only at release, so closing this dimension requires renegotiating the global enterprise agreement for change-control/prior-authorisation of new AI subprocessors, standing monitoring of release notes and the trust-site subprocessor list, and wiring vendor-side defaults into Brightwater's AI governance gate. That is a project across procurement, legal, privacy and IT — but no re-architecture of systems and no infrastructure replacement, so neither Low nor High.
    U Vendor Notice PostureAmberRedagent · overrideOVERRIDE of the questionnaire's Red. The scenario states Orbit's terms allow feature changes at its discretion 'with notice at the time of release', and the updated subprocessor list naming the foundation-model provider was published on the trust site 'the same day the release shipped'. Disclosure therefore occurred, but concurrently with the change taking effect — the textbook definition of Amber — rather than never. Red would understate that a published subprocessor list and release notice existed and were discoverable; it was Brightwater's monitoring, not Orbit's disclosure, that was absent. Notice is nonetheless contemporaneous, passive and not contractually guaranteed in advance, so Green/Clear are excluded; the secondary 6.1 observation that the admin console did not proactively surface the change reinforces Amber rather than Green.
  7. 7 How many companies are really in this chain: and did we agree to it?Headline

    7.2 Third-party model providers embedded in a procured product (silent AI feature addition) · also 7.1
    HIGH7.4

    This is the headline finding. Brightwater bought Orbit CRM eight years ago for reasons that had nothing to do with artificial intelligence, and Orbit has now inserted an AI feature and a new foundation-model provider into that relationship without Brightwater's agreement. The subprocessor list naming the model provider was published on the same day the feature went live, so the chain of companies handling Brightwater's customer data expanded with no prior authorisation and no opportunity to object. Brightwater's mandatory pre-adoption AI review never ran — not because it was bypassed, but because it is triggered by someone choosing to adopt AI, and nobody chose anything. The result is that customer email threads, call notes, pricing, contract terms and personal contact details for forty countries became readable to a company Brightwater never contracted with, continuously and for every user, until the exposure was found by accident.

    Rating HIGH. Brightwater's AI governance controls do not reach the largest AI exposure it currently has, because that exposure arrived inside a product it already owned.

    Evidence: vector, score and 21 metric rationales

    Vector SOV:1.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:L/E:A/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:D/RE:M/U:Amber Score 7.4 (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?

    MetricValuePriorSourceRationale
    AV Access PathANagent · overrideOVERRIDE (N -> A). The questionnaire prior correctly describes Orbit CRM itself: a multi-tenant SaaS in the vendor's cloud reached over its API. But the dependency named by taxonomy node 7.2 is the *third-party foundation-model provider embedded in the procured product*, and Brightwater has no path to or from that party at all. Customer contract terms, pricing and personal data reach the model provider only because Orbit relays email threads and call notes to it; the provider appears on Orbit's subprocessor list, not on any Brightwater contract. The rubric defines A as 'Adjacent -- subprocessor-mediated access', which is exactly this topology, versus N 'vendor-direct API access, no intermediary'. MITRE ATLAS AML.T0047 describes the same indirect-access structure (model reached 'under the hood' of a product rather than directly). Confidence is moderate because a reviewer could reasonably score the primary contracted SaaS plane as N; the mediation, however, is the defining feature of this category.
    AC Compulsion ComplexityLLagentCONFIRM L. Orbit needed to overcome nothing: its own terms 'allow feature changes at its discretion with notice at the time of release', and it unilaterally published an updated subprocessor list on the day the release shipped. There are no customer-managed keys, no data-residency carve-out and no contractual pre-approval gate for subprocessor additions that had to be circumvented, despite the data covering customers in forty countries. This is the rubric's 'standard ToS clause suffices' case. The eight-year global enterprise agreement conferred no technical or contractual barrier that bit here.
    AT Trigger ConditionsNPagent · overrideOVERRIDE (P -> N). The questionnaire answer bundled 'product decision' in with sanctions designation, litigation hold and security incident, but the rubric reserves P for 'a specific triggering event' and assigns N where 'control can be exercised at vendor discretion at any time'. A vendor product decision is the definition of vendor discretion, not an external trigger: Orbit Insights shipped in a *routine quarterly release*, on by default, under terms that expressly permit feature changes at Orbit's discretion. Nothing had to happen first, and nothing constrains Orbit from swapping the underlying model provider again on the same basis. The rubric names AT as one of the two primary exploitability metrics for dimension 7.2, so this correction is material; the dimension note ('the org's own governance never touches the primary system at all') presupposes a change that fires without any precondition the org could monitor for.
    PR Position RequiredNNagentCONFIRM N. No elevated position was required. The foundation-model provider obtained read access to CRM content purely by being added to Orbit's subprocessor list — i.e. 'any party already in the subprocessor chain has sufficient standing'. Brightwater's own administrative credentials were never compromised or needed (H is excluded), and while Orbit is the primary contracted vendor (which would suggest L), the party that actually gains the sovereignty-relevant access is a downstream subprocessor Brightwater never reviewed, which is the rubric's N condition. Per EU AI Act Recital 88 / Art. 25, such value-chain parties act on the strength of the provider's written arrangements, not on any standing granted by the deployer.
    UI Org Action RequiredNNagentCONFIRM N, and this is the metric that carries the dimension. The rubric lists 'silently added AI feature' as a named example of UI=None, and the 7.2 note describes 'UI=None in its most extreme form: the org's own governance never touches the primary system at all'. Brightwater matches exactly: the feature was on by default for all users, the AI-governance review 'never triggered because no one in the organisation adopted anything', and the exposure was discovered only when a sales manager asked why summaries were appearing. The per-tenant administrator disable switch does not move this to A — that is post-hoc remediation, not an affirmative act required to create the exposure. Nor is it P: ordinary use was not the precondition either, since the subprocessor addition and default-on activation were complete before any user touched a summary.
    VC Primary Dependency Impact -- ConfidentialityNNagentCONFIRM prior. The named dependency is Orbit CRM as procured. No confidentiality is lost at Orbit itself: the data in the CRM (contract terms, pricing, personal contact details for 40 countries) is held by the same vendor under the same eight-year global enterprise agreement that already governed it, and Orbit gained no new read access it did not already hold. The genuine confidentiality loss is that an unreviewed third-party foundation-model provider -- added to the subprocessor list the same day the release shipped -- now receives customer email threads and call notes; that is a party Brightwater never contracted with, so the loss lands beyond the primary dependency and belongs in SC, not VC. The rubric scopes the vulnerable-system group to loss 'AT the dependency named by the taxonomy node itself' and assigns node 7.2 an empty primary_impact_axis with subsequent_impact_relevant=true, precisely because 'every impact is Subsequent relative to what the org believes it procured'. Questionnaire agrees: 'None: no sensitive data is exposed here' at the dependency, versus 'Full' beyond it.
    VI Primary Dependency Impact -- IntegrityNNagentCONFIRM prior. Orbit CRM's own records and core behaviour were not altered: the quarterly release added a summarisation feature on top of the CRM rather than changing the integrity of stored customer data, and the feature remains administrator-disableable per tenant. Orbit's terms permitting discretionary feature changes with notice at release time is an exploitability fact (it is why AT/UI carry this node), not an integrity loss at the dependency. The integrity exposure that matters is that AI-generated summaries and 'suggested next actions' from an unreviewed model provider can be wrong or manipulated and flow into sales decisions without detection -- a downstream effect, captured by SI. Questionnaire confirms 'None' at the dependency against 'Full: downstream systems act on altered outputs without detection' beyond it.
    VA Primary Dependency Impact -- AvailabilityNNagentCONFIRM prior. Nothing about the Orbit CRM capability was withdrawn or degraded -- the release added function rather than removing it, and Brightwater can continue operating the CRM unchanged (it can even disable Orbit Insights per tenant and still have the platform it procured). The questionnaire states 'None: we could keep operating this component', and exit is rated as moderate manual migration rather than loss of capability. Any availability concern is the partial degradation of downstream workloads that have begun relying on the summaries, which is scored under SA; the questionnaire correspondingly reports only 'Some downstream workloads degrade' beyond the dependency.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentCONFIRM prior H. Per the rubric's own 7.2 note, in a silent AI feature addition the org's governance never touches the primary system, so essentially all impact lands on subsequent systems. Here the subsequent party is a third-party foundation-model provider that appeared on Orbit's subprocessor list the same day the release shipped, i.e. a party Brightwater never contracted with, reviewed, or authorised. The content exposed is not incidental: full customer email threads and call notes, plus the CRM records they summarise, containing contract terms, pricing and personal contact details for customers in forty countries. The feature was on by default for all users, so exposure was tenant-wide and continuous until discovered by accident. That is a total-or-near-total loss on the downstream confidentiality axis, and it matches the questionnaire's own characterisation ('Full: sensitive data becomes readable by a party we never contracted with'). The EU AI Act value-chain provisions (recitals 88-90 and the Art. 25 third-party supply obligations) presuppose a written agreement specifying information and access between the integrating provider and the third-party component supplier; no such instrument exists on Brightwater's side, and interagency TPRM guidance treats exactly this - disclosure of customer and personally identifiable information to an undisclosed subcontractor - as the contractual control that must be in place. Reinforced by AU=Yes (all Orbit tenants at once) and the vendor's practice of not disclosing sovereignty-relevant changes before they take effect.
    SI Downstream Blast-Radius Impact -- IntegrityLHagent · overrideOVERRIDE prior H to L. The integrity exposure is real and undetectable - Orbit does not disclose model versions or subprocessor changes before they take effect, so the foundation model behind Insights can be swapped or re-tuned silently, and because governance never fired there is no accuracy baseline, evaluation or provenance marking for the summaries (cf. EU AI Act recital 133 on the difficulty of distinguishing generated content and the resulting integrity-of-information risk; MITRE ATLAS AML.T0062 shows hallucinated content is a recurring, cross-model failure mode). So SI is clearly not None. But H requires total or near-total loss, and the corrupted surface here is confined to a derived advisory layer: Insights summarises threads and call notes and *suggests* next actions to human users. The authoritative records - the underlying emails, call notes, contract terms and pricing - are not written back to or altered, and a human reads the summary and can compare it against the source thread (indeed a sales manager's own scrutiny is how the feature was discovered). EU AI Act recital 53 treats precisely this pattern - a system performing a narrow task over, or improving the result of, a previously completed human activity - as not materially influencing the substance of decision-making. The questionnaire's 'downstream systems act on altered outputs without detection' overstates the scenario, which describes no autonomous action or automated write-back. Partial/limited downstream integrity loss is the defensible reading; this would move to H if Insights were shown to write back into CRM fields or trigger actions without human review.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentCONFIRM prior L. Availability loss is the mildest axis here. At the dependency itself availability impact is None (the questionnaire confirms Brightwater could keep operating the component - the CRM functions without Insights, as it did for eight years), and the feature is disabled per tenant by an administrator. Downstream, withdrawal or degradation of the summarisation capability - whether by Orbit's product decision or by the model provider upstream - would degrade only those sales workflows that have come to lean on summaries and suggested next actions, matching the questionnaire's 'some downstream workloads degrade'. R=User (manual re-integration) and V=Diffuse (one narrow workload) both bound the blast radius. Not S: Brightwater is a consumer-brands manufacturer and the affected function is CRM note summarisation, with no safety component, no physical process and no health-or-safety-relevant decision in the loop (contrast EU AI Act recital 47, which reserves safety framing for AI acting as a safety component of a product or in high-stakes health settings).
    E Precedent MaturityAXagent · overrideOverride of the X prior (and of the questionnaire's 'Unknown' answer to the precedent question). The rubric defines E:A as 'documented real-world cases of this control being exercised against comparable orgs' (sovereignty_cvss_rubric_1.json, threat group). Here the control has not merely been demonstrated, it has already been fully exercised: Orbit unilaterally enabled Orbit Insights on by default for all users in a routine quarterly release, routed CRM content (contract terms, pricing, personal contact data for customers in 40 countries) to a third-party foundation-model provider, and published that provider on its subprocessor list the same day the release shipped. The questionnaire confirms the event class is non-discretionary and simultaneous across the customer base ('Could the loss event happen to all of the vendor's customers at once... Yes') and that the vendor 'does not disclose [sovereignty-relevant changes] before they take effect', so every comparable Orbit tenant underwent the same exercise of control. A realized event against the assessed org and its peer tenants is the strongest available grounding for E:A; the 'Unknown' questionnaire answer reflects absence of external reporting, not absence of occurrence. Corroborating corpus evidence: MITRE ATLAS AML.T0047 'AI-Enabled Product or Service' (indirect access to a model embedded under the hood of a procured product) carries maturity 'Realized', which the ATLAS-to-CASE mapping in the corpus README translates directly to CASE Precedent Maturity E:A. EU AI Act recitals 87-90 and Art. 25 treat downstream embedding of third-party models into procured products as established, recurring market practice rather than a hypothetical. Confidence held at 0.85 because the taxonomy records 'None identified' as the existing standard for dimension 7.2, so no sovereignty-framed incident registry exists to cite by name.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)LLquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePPagentConfirmed. The rubric names GDPR Art. 28 as the canonical trigger for S=Present, and this is that fact pattern: a new sub-processor (the foundation-model provider) began processing special-category-adjacent personal data (contract terms, pricing, personal contact details for customers in 40 countries) with the subprocessor list published the same day the release shipped — i.e., no prior general or specific written authorisation and no opportunity for Brightwater, as controller, to object before processing began. That is an independent, reportable compliance failure under Art. 28(2) and 28(3)(d), with likely knock-on Art. 44 (undisclosed onward transfer) and Art. 35 (no DPIA) exposure. Independently, EU AI Act deployer obligations (Art. 50 transparency; Art. 26(9) DPIA linkage) attach to Brightwater as deployer whether or not it knowingly 'adopted' the feature, so the governance gap does not excuse the trigger. The regulatory violation arises from the configuration change itself, not from any further compromise.
    AU Silent/Automatic TriggerYYagentConfirmed, and this is the metric that most sharply characterises dimension 7.2. Orbit Insights shipped in a routine quarterly release, on by default for all users, across the vendor's tenant base. The sovereignty-loss event (customer data flowing to an unreviewed model provider) occurred simultaneously for every customer with no per-customer decision, no contract amendment and no opt-in — matching the rubric's AU=Yes cell ('simultaneously across all customers with no case-by-case decision'). This pairs with UI=None in the exploitability group: the trigger was unilateral and automatic, which is exactly why Brightwater's adoption-gated review never fired.
    R Portability / Exit RecoveryUUagentConfirmed. Not Irrecoverable: the capability at stake is commodity thread/call-note summarisation, not custody of unique model weights (the rubric's primary hook for R), and Brightwater retains the per-tenant administrator toggle plus its own CRM record estate. Not Automatic either: reconstituting equivalent summarisation outside Orbit would require re-integration against a different model provider, re-contracting, and re-establishing the data pipeline into the CRM — the rubric's 'manual migration effort' cell. Note a residual that R cannot express: data already sent to the model provider during the silent-enablement window cannot be recalled, so recovery is forward-looking only.
    V Blast-Radius ConcentrationDDagentConfirmed, but narrowly and on a strict reading of the rubric cell. V measures concentration across *AI workloads*: Orbit Insights is a single narrow AI workload (email-thread and call-note summarisation with next-action suggestions) and is not a shared control plane that other Brightwater AI workloads route through, so 'scoped to one narrow workload' fits. The countervailing fact — that the affected data estate is enterprise-wide (all CRM records, all sales users, 40 countries, under an eight-year global agreement) — is real but is already captured by the subsequent-impact metrics (SC/SI) rather than by V; double-counting it here would distort the supplemental layer. Lower confidence recorded because a reviewer weighting V by data blast radius rather than AI-workload count would reasonably argue C.
    RE Exit / Mitigation EffortMMagentConfirmed. The immediate tactical mitigation is cheap — an administrator can disable the feature per tenant — which argues toward L. But RE should score the durable fix, not the kill switch. Orbit's terms permit feature changes at its sole discretion with notice only at release, so preventing recurrence requires re-contracting that notice/authorisation clause within a global enterprise agreement with a leading SaaS vendor, plus retrospective DPIA, Art. 28 remediation, records-of-processing updates and standing monitoring of the trust-site subprocessor list. That is a project. It does not require re-architecture or infrastructure replacement (the CRM stays, the toggle exists), so H overstates it. Moderate is the correct cell.
    U Vendor Notice PostureAmberRedagent · overrideOVERRIDE of the questionnaire prior (Red). The questionnaire option selected — 'it does not disclose them before they take effect' — is literally true but conflates the rubric's Red and Amber cells, since neither involves advance notice. The scenario supplies the discriminating facts: Orbit's terms expressly provide for feature changes 'with notice at the time of release', and the updated subprocessor list naming the foundation-model provider was published on the trust site the same day the release shipped. That is disclosure *concurrent with the change taking effect*, which is the rubric's Amber definition verbatim; Red is reserved for a vendor that never discloses sovereignty-relevant changes before they take effect at all, i.e. no contemporaneous disclosure channel. Amber is therefore the more precise cell. Two caveats a reviewer should weigh: the practical effect approached Red (Brightwater learned of the change only when a sales manager asked why summaries were appearing), and concurrent publication on a vendor-hosted trust site offers no opportunity to object — the whole point of the 7.2 gap. Confidence set at 0.68 to reflect that Red is defensible if 'disclosure' is read as requiring actual notice to the customer rather than passive publication.

What Brightwater Consumer Brands should do next

Written by the narrative agent from the findings and mitigations

  1. Brightwater should decide immediately whether to disable Orbit Insights at the tenant level while the review it never got to perform is carried out, and record that decision and its rationale.
  2. Brightwater should put a written demand to Orbit for the identity, processing locations and retention practices of the foundation-model provider, and for confirmation of whether any human at Orbit or that provider can read Brightwater content.
  3. Brightwater should treat the undisclosed addition of a new processor to personal data for forty countries as a potentially reportable matter and have its data protection function assess notification obligations and complete the missing impact assessment without waiting for Orbit's answers.
  4. Brightwater should serve notice under the enterprise agreement seeking contractual change: advance notice of sovereignty-relevant changes, the right to approve new subprocessors before processing begins, the right to stay on a tested model version, and explicit limits on retention of prompts and AI-generated summaries.
  5. Brightwater should redefine the trigger for its AI governance review so it fires on vendor-initiated change — new or changed AI features, new subprocessors, new model providers — rather than only on a deliberate adoption decision by its own staff.
  6. Brightwater should maintain a living inventory of the AI components, models and data flows inside every procured platform, so that a new model provider appearing in a vendor's chain is visible to the organisation rather than buried in a trust-site update.
  7. Brightwater should require logging of AI feature usage, inputs and outputs that it can see and retain itself, together with monitoring that alerts on AI features switching on or on summary output appearing, so that the next change is detected by a control rather than by a sales manager's question.
  8. Brightwater should put output controls in place for any AI feature it does keep — screening of what is sent as context for personal data, pricing and contract terms, and clear labelling of AI-generated text in the customer record — and define a short, documented test it runs against the feature whenever the vendor changes it.
  9. Brightwater should run this same review across its other long-standing SaaS platforms, since any vendor with comparable discretionary-change terms can repeat exactly what Orbit did.

Ranked mitigations

Retrieved from the mitigation library for the adverse metrics

10
RelevanceMitigationTargets
0.92AML.M0008 — Validate AI Model (Technical - AI; AI Model Evaluation, Monitoring and Maintenance): Validate that AI models perform as intended by testing for backdoor triggers, potential for data leakage, or adversarial influence. Monitor AI model for concept drift and training data drift, which may indicate data tampering and poisoning. Mitigates AML.T0010.003 Model (ensure acquired models do not respond to backdoor triggers), AML.T0018 Manipulate AI Model (validation against a wide range of adversarial inputs increases confidence the model has not been manipulated), AML.T0018.001 Modify AI Model Architecture, AML.T0057 LLM Data Leakage (robust evaluation detects privacy concerns, data leakage and potential for revealing sensitive information), and AML.T0115.001 Models (evaluate submissions for backdoors, data leakage and unexpected behaviour before listing).A standing acceptance-test and drift-monitoring gate on every model version is the single most direct control for silent vendor-side model updates (1.3) and procured-product AI additions (7.2), converting an automatic, unannounced change into a detected and blocked one.AUUVISIATUIVC
0.90AML.M0020 — Generative AI Guardrails (Technical - AI; Model Engineering, Evaluation, Deployment, Monitoring): Safety controls placed between users, tools and generative AI models to evaluate prompts, retrieved context, model outputs and agent actions before they are accepted, executed or shown to a user. Implementations include input moderation; output moderation (scan responses for harmful content, PII, secrets, policy violations, unsupported claims); system prompt and policy enforcement; tool and action guardrails; retrieval guardrails that filter and validate retrieved documents before they enter model context (untrusted sources, malicious instructions, irrelevant context, sensitive data); groundedness and factuality checks against trusted sources; sensitive data and secret protection (detect, redact, block PII, credentials, tokens, proprietary data, system prompts in prompts, retrieved context, tool outputs and responses); and structured output validation enforcing schemas, type checks, allowed values and safe formats before outputs are consumed by downstream systems. Guardrails should be continuously evaluated and red-teamed, and guardrail decisions logged. Mitigates AML.T0057 LLM Data Leakage, AML.T0066 Retrieval Content Crafting, AML.T0070 RAG Poisoning, AML.T0071 False RAG Entry Injection, AML.T0069 Discover LLM System Information.Output moderation, groundedness checks and structured output validation directly contain confidentiality and integrity harm from model completions (3.3) and poisoned retrieval context (4.1) before it propagates to downstream consumers.VCVISCSIVAC
0.84AML.M0024 — AI Telemetry Logging (Technical - Cyber; Deployment, Monitoring and Maintenance): Implement logging of inputs and outputs of deployed AI models. When deploying AI agents, log intermediate steps of agentic actions and decisions, data access and tool use, installation commands, and the identity of the agent. Monitoring logs can help detect security threats and mitigate impacts, and enabled logging discourages adversaries who want to remain undetected. Mitigates AML.T0040 AI Model Inference API Access (audit API usage of the model), AML.T0047 AI-Enabled Product or Service, AML.T0085/AML.T0085.000 Data from AI Services / RAG Databases (log requests to AI services to detect malicious queries for data), AML.T0024 Exfiltration via AI Inference API, and AML.T0114 AI Service Web Interface.Comprehensive input/output and version telemetry is what makes an otherwise silent, automatically triggered vendor change or embedded AI feature observable and evidenced, and gives the audit trail needed for regulatory defence.AUUSESCSIVC
0.82AML.M0013 — Code Signing: Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing. Developers should also cryptographically sign SBOM and AIBOM components that track model or data provenance. Enforcement of code signing can prevent compromise of the AI supply chain and prevent execution of malicious code. Mitigates AML.T0010.001 AI Software (enforce properly signed drivers and ML frameworks), AML.T0010.003 Model (enforce properly signed model files), AML.T0011.000 Unsafe AI Artifacts, AML.T0018 Manipulate AI Model, AML.T0018.000 Poison AI Model, AML.T0018.001 Modify AI Model Architecture, AML.T0018.002 Embed Malware.Signature enforcement on model files and signed AIBOM components pin the exact artifact in use, so an unapproved or substituted model version cannot be activated without an explicit, detectable failure.VISIAUACATAV
0.80AML.M0023 — AI Bill of Materials (AIBOM): Maintain an AI BOM recording the components, dependencies, models, data and software that make up an AI system, including dataset provenance — a detailed history of datasets used for AI applications covering source and a complete record of any modifications. Mitigates AML.T0010 AI Supply Chain Compromise (an AI BOM helps users identify untrustworthy components of their AI supply chain), AML.T0011 User Execution, AML.T0011.000 Unsafe AI Artifacts, AML.T0011.001 Malicious Package, AML.T0020 Training Data Poisoning.An enforced AIBOM is the governance artefact that surfaces third-party models silently embedded into a procured product (7.2) and records which model version and data sources are live (1.3, 4.1), reducing concentration blindness.UAUVSEVI
0.78AML.M0005 — Control Access to AI Models and Data at Rest (Policy): Establish access controls on internal model registries and limit internal access to production models; limit access to training data only to approved users. Mitigates AML.T0018 Manipulate AI Model (access controls prevent tampering with AI artifacts and unauthorized modification), AML.T0018.001 Modify AI Model Architecture, AML.T0020 Training Data Poisoning, AML.T0012 Valid Accounts (restrict registries and training data to approved identities), AML.T0069 Discover LLM System Information (restrict access to stored system prompts, configuration files and model metadata), AML.T0069.002 System Prompt (restrict access to stored system prompts and prompt templates), AML.T0112.001 AI Artifacts (restrict write access to model registries and AI artifact stores).Restricting write access to model registries, prompt templates and configuration files is the core control for configuration and policy management (6.4) and raises the privilege and effort needed to alter a pinned model version.PRACVISIVCAV
0.74AML.M0019 — Control Access to AI Models and Data in Production (Policy; Deployment, Monitoring and Maintenance): Require users to verify their identities before accessing a production model. Require authentication for API endpoints and monitor production model queries to ensure compliance with usage policies and prevent model misuse. Mitigates AML.T0006 Active Scanning (require authenticated access to production AI endpoints), AML.T0012 Valid Accounts, AML.T0063 Discover AI Model Outputs (controlling access to the model in production prevents adversaries inferring information from model outputs), AML.T0069 Discover LLM System Information (authenticate and monitor access to production models and configuration interfaces), AML.T0091 Use Alternate Authentication Material, AML.T0096 AI Service API (authenticate AI service API callers and monitor queries for policy violations and misuse).Authenticating and monitoring production inference and configuration interfaces closes the open network access path exploited in dimensions 3.3 and 6.4 and limits confidentiality loss through model outputs.AVPRUIVCSCAC
0.72AML.M0026 — Privileged AI Agent Permissions Configuration (Technical - Cyber; Deployment): When deploying a privileged AI agent, or an agent that interacts with multiple users, implement robust policies and controls on the agent's permissions, including Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC) and the principle of least privilege, so the agent is granted only the permissions needed for its designated tasks. Mitigates AML.T0082 RAG Credential Harvesting, AML.T0085 Data from AI Services, AML.T0085.000 RAG Databases (proper access controls limit an adversary's ability to collect data from RAG databases if the agent is compromised), AML.T0086 Exfiltration via AI Agent Tool Invocation, AML.T0101 Data Destruction via AI Agent Tool Invocation.Least-privilege RBAC/ABAC over the retrieval layer and its credentials shrinks the downstream blast radius and concentration of a compromised or vendor-controlled RAG pipeline (4.1).SCSIVPRVC
0.70AML.M0014 — Verify AI Artifacts (Technical - Cyber; Business and Data Understanding, Data Preparation, AI Model Engineering): Verify the cryptographic checksum of all AI artifacts to confirm the file was not modified by an attacker. Mitigates AML.T0002.001 Models (introduce proper checking of signatures so unsafe AI models are not introduced to the system), AML.T0010 AI Supply Chain Compromise, AML.T0010.002 Data (signature checking so unsafe AI data is not introduced), AML.T0011 User Execution, AML.T0011.000 Unsafe AI Artifacts.Checksum verification at ingestion gives a deterministic integrity gate on every model and dataset artifact entering the estate, blocking unverified updates before deployment.VISIAUATAC
0.66AML.M0035 — AI Red Teaming: Continuous adversarial exercising of the AI system, repeated as the threat landscape evolves and whenever changes are made to the system, its components, intended use or deployment environment. Includes: AML.T0010 AI Supply Chain Compromise — exercise introduction of controlled untrusted software, data, models and agent tools through representative acquisition and deployment paths, remediating weaknesses in provenance, validation, approvals, isolation and rollback; AML.T0010.003 Model — introduce a controlled untrusted or modified model through representative acquisition and deployment paths and verify provenance, scanning, signing, approval, isolation and rollback; AML.T0018 Manipulate AI Model — attempt controlled modification or substitution of models, weights, adapters and related configuration, remediating weaknesses in authorization, artifact integrity, deployment approval, monitoring and recovery; AML.T0024 Exfiltration via AI Inference API — exercise inference interfaces and improve privacy controls, output restriction, rate limits and monitoring.Repeating adversarial exercises on every change explicitly tests the approval, integrity, monitoring and rollback path for model substitution, which is the assurance evidence needed where exploit precedent is already mature.EVISIAUSAC

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:L AR:L AT:P AU:Y AV:N CR:H E:X IR:M PR:N R:U RE:M S:P SA:L SC:H SI:H U:Red UI:N V:D VA:N VC:N VI:N
Job
79c54e9c-9ff2-44ae-b9f3-2238caaf7cc1