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
- 65 min 50 s · 38 agent calls
Headline · class 7
8.2HIGH
SOV:1.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/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: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
| Class | Carried by | Score | Rating | Load-bearing metrics |
|---|---|---|---|---|
| 1 Whose AI brain is this, really? | 1.1 Model hosting location / jurisdiction | 6.7 | MEDIUM | ACATPRUIVCSCSAU |
| 2 What are we feeding it? | 2.2 Internal documents ingested for RAG | 6.3 | MEDIUM | ACATPRUIVCSCSAU |
| 3 What does it create from our data: and where does THAT go? | 3.3 Model outputs / completions | 7.9 | HIGH | AVACATPRUIVCSCSISAU |
| 4 Who's deciding what the AI sees and does? | 4.2 Orchestration / agent framework | 7.1 | HIGH | AVACATUIVISCSISAU |
| 5 Which humans are actually looking at our stuff? | 5.3 Support / debugging access | 5.6 | MEDIUM | ACPRUIVCS |
| 6 Who's holding the steering wheel? | 6.4 Configuration and policy management | 7.9 | HIGH | AVACATUIVISCSIESAUV |
| 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) | 8.2 | HIGH | ACATPRUISCSIESAUV |
Findings
What we found per class, in the auditor's language; open the evidence to see each metric's rationale
- MEDIUM6.7
1 Whose AI brain is this, really?
1.1 Model hosting location / jurisdiction · also 1.3The summaries that now appear in Brightwater Consumer Brands' CRM are not produced by Orbit CRM itself but by a third-party foundation-model provider that Brightwater has never reviewed, contracted with or assessed. Because that provider was disclosed only through a subprocessor list published on Orbit's trust site on the day the release shipped, Brightwater cannot say in which country or under which legal system the summarisation actually happens. The material being sent there is regulated data: customer contract terms, pricing and personal contact details for customers in forty countries. Orbit's terms also allow it to change the feature, and therefore the model behind it, at its own discretion with notice only at the moment of release, so the provider could change again without Brightwater being told in advance.
Rating MEDIUM. Brightwater cannot answer the most basic question an auditor or regulator will ask — where its customers' personal and contract data is processed and whose laws apply to it.
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:L/SC:H/SI:L/SA:L/E:P/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:D/RE:L/U:Amber Score 6.7 (Medium)
Ask the vendor Whose AI model is actually answering our questions, yours, or one you're renting from someone else? · If we stopped paying you tomorrow, could we take this AI capability somewhere else, or does it just disappear? · Can the AI's behavior change overnight without you telling us?
Metric Value Prior Source Rationale AV Access Path A N agent · override OVERRIDE of prior N. The prior correctly describes the primary dependency (Orbit, in its own cloud, reached directly over its API). But this category is the model layer: the summaries are generated by a third-party foundation-model provider that Brightwater has no contract with and no API relationship to. Brightwater's data reaches that model only because Orbit forwards it — the provider 'appeared in an updated subprocessor list published on Orbit's trust site the same day the release shipped'. That is the rubric's definition of Adjacent: 'subprocessor-mediated access'. Interagency third-party risk guidance treats such foreign-based onward parties as a distinct jurisdictional and cross-border-flow exposure requiring its own assessment, which never happened here. AC Compulsion Complexity L L agent CONFIRMED. No technical or contractual barrier protects the model-hosting question: Orbit's terms 'allow feature changes at its discretion with notice at the time of release', there is no data-residency carve-out, no customer-managed key, and no Brightwater review of the model host. Against the unknown host itself, the DOJ CLOUD Act white paper establishes that routine domestic legal process suffices to compel production of data a provider controls even when stored abroad, and that nearly every jurisdiction examined asserts that authority given a jurisdictional hook. Standard ToS plus routine legal process is therefore sufficient — Low. AT Trigger Conditions N P agent · override OVERRIDE of prior P. The prior is framed around legal-authority events (sanctions designation, litigation hold, incident) against Orbit. For dimension 1.1 the exposure is the routing of regulated personal and contractual data to a model host in an unassessed jurisdiction — and that required no triggering event at all. It was effected by a unilateral product decision in a 'routine quarterly release', on by default, with the subprocessor list updated the same day. A pure vendor-discretion product change exercisable at any time is the rubric's 'None' value, not 'Present'. The CLOUD Act material reinforces this: cross-border movement of data between a global provider's storage locations happens automatically and near-constantly, with no discrete event and sometimes without the provider itself knowing the location. PR Position Required N N agent CONFIRMED. No privileged position is needed: the foundation-model provider is itself already in the subprocessor chain and processes Brightwater's customer contract terms, pricing and personal contact details without ever having contracted with Brightwater. Any party in that chain — Orbit, the model provider, or an onward host — has sufficient standing, and the authority asserting jurisdiction over the host needs only the host's territorial presence as a hook, not any Brightwater credential. UI Org Action Required N N agent CONFIRMED. This is the rubric's paradigm case of 'silently added AI feature': Orbit Insights was enabled by default for all users, the model subprocessor was published the same day the release shipped, the vendor 'does not disclose [sovereignty-relevant changes] before they take effect', and Brightwater's mandatory pre-adoption AI review never triggered 'because no one in the organisation adopted anything'. The organisation discovered it only when a sales manager asked why summaries were appearing. No affirmative or even routine-use action by Brightwater was required to create the exposure — the vendor acted unilaterally. VC Primary Dependency Impact -- Confidentiality H N agent · override Override of the questionnaire's 'N'. The prior was answered about the primary dependency (Orbit CRM, where Brightwater sees the data as staying inside its contracted tenant). For Category 1 / dimension 1.1 the dependency IS the third-party foundation-model inference infrastructure, and the rubric defines vulnerable-system impact as CIA loss AT the dependency named by the taxonomy node (sovereignty_cvss_rubric_1.json, 'vulnerable_system_impact'). Every email thread and call note summarised by Orbit Insights — contract terms, pricing and personal contact details for customers in forty countries — is transmitted to that model host, whose location and jurisdiction Brightwater has never assessed (it learned of the subprocessor only after the fact). Because the hosting jurisdiction is unknown, the data is exposed to whatever compelled-disclosure regime applies there: providers can be ordered to produce data under their control irrespective of storage location (CLOUD Act / Budapest Convention Art. 18(1)(a)), and in multi-region cloud estates even the provider may not know where data resides (doj-cloud-act-white-paper-2019). With no customer-managed keys, residency carve-out or external key escrow of the kind sovereign-control offerings provide (google-cloud-sovereign-controls), there is nothing to overcome beyond standard ToS/routine legal process — the organisation itself answers that this would trigger a reportable regulatory violation. That is a total loss of confidentiality of the regulated content at this node, hence H. VI Primary Dependency Impact -- Integrity L N agent · override Override of 'N', but only to Low. 1.1 is not primarily an integrity dimension (the rubric assigns VI as the primary axis to 1.3 Model update/versioning control, noted as the secondary dimension here). Still, integrity at this node is not untouched: Orbit's terms permit feature changes at its discretion with notice only at release, and the organisation states the vendor 'does not disclose them before they take effect', so the model behind Orbit Insights can be swapped or re-tuned — or re-routed to a different hosting region/sub-model — without Brightwater's knowledge, changing the summaries and 'next action' suggestions sales staff rely on. The rubric records that for 1.3 'every downstream consumer of the model inherits an un-notified behavior change'. The alteration is a change of behaviour in a narrow summarisation feature rather than a total subversion of the model's function, and the underlying CRM records themselves are not rewritten, so partial/limited loss (L) is the right calibration. VA Primary Dependency Impact -- Availability L N agent · override Override of 'N' to Low rather than confirmation. Jurisdictional exposure runs in both directions: because the model host's jurisdiction is unassessed, the specific trigger events the organisation itself identified (sanctions designation, litigation hold, a localisation or export-control order, or a unilateral Orbit product decision) could suspend inference for the affected regions, and no party in the chain needs Brightwater's cooperation to act (AT=Present, UI=None in its own answers). The effect, however, is bounded: Orbit Insights is one narrow workload (V=Diffuse), the eight-year-old CRM core keeps functioning without it, and the capability is reconstitutable with manual migration effort (R=User), with only 'some downstream workloads degrade' reported. That is degradation of this component, not total or near-total loss, so L rather than H; retaining N would understate the fact that the feature's continued availability rests entirely on an unknown jurisdiction's tolerance. SC Downstream Blast-Radius Impact -- Confidentiality H H agent Confirmed. Beyond the named dependency (the inference host itself), the undisclosed foundation-model provider sits on infrastructure of unknown location operated by parties Brightwater has no contract with and never assessed. The content entering it is customer email threads and call notes drawn from CRM records containing contract terms, pricing and personal contact details for customers in forty countries. Because the hosting jurisdiction is unanswerable, Brightwater cannot bound which further subprocessors or which legal authorities can reach that content; the DOJ CLOUD Act white paper documents precisely this condition — globally distributed storage whose location is sometimes unknown even to the provider, compellable by routine legal process. The questionnaire confirms the operative facts: access requires 'nothing beyond its standard terms of service or routine legal process', 'any party already in the subprocessor chain' has sufficient standing, no action by Brightwater is needed, and a loss of control here alone would be a reportable regulatory violation. That is a near-total loss of confidentiality control over regulated data at parties downstream of the model host, so H. SI Downstream Blast-Radius Impact -- Integrity L H agent · override Override H -> L for this category. The questionnaire's 'full, undetected' downstream integrity answer is driven by the un-notified model-swap pathway, which the rubric assigns to dimension 1.3 (model update/versioning control: primary_impact_axis VI, subsequent_impact_relevant true), not to 1.1, whose primary impact axis is VC and for which the rubric sets subsequent_impact_relevant: false. Assessed on its own terms, a change of hosting location or jurisdiction of the inference provider does not by itself corrupt outputs totally: Orbit Insights produces advisory artefacts — thread summaries and suggested next actions — consumed by sales staff in one narrow workload, and it does not overwrite the authoritative CRM fields (contract terms, pricing, contact details) that downstream commercial decisions rest on. Detection is genuinely weak (Brightwater did not know the feature existed until a sales manager asked, and the vendor 'does not disclose changes before they take effect'), which is why this is not N, but the propagation is partial rather than total, so L. SA Downstream Blast-Radius Impact -- Availability L L agent Confirmed. If the unknown-jurisdiction inference host became unreachable — sanctions designation, a legal restriction on cross-border transfer, or a unilateral product decision, all triggers the questionnaire flags — summarisation and next-action suggestions would stop, but the CRM itself and the underlying sales process continue; the questionnaire records 'some downstream workloads degrade' and 'we could keep operating this component', with migration possible through manual re-embedding and re-integration (a moderate project). Partial, not total, downstream availability loss. S is not applicable: this is a consumer-brands sales and CRM workflow with no physical-process or safety-relevant function, so loss of the summarisation capability cannot cause physical harm. E Precedent Maturity P X agent · override Override of the questionnaire's X (which merely reflects Brightwater's own ignorance — it answered 'Unknown' to whether this control has been exercised against peers, and it never reviewed the model host at all, so absence of knowledge is not evidence of absence). The corpus establishes that the underlying mechanism of this dimension — a legal authority or the provider itself reaching personal and contractual data processed on infrastructure whose jurisdiction the customer has not assessed — is demonstrated, not theoretical: the DoJ CLOUD Act white paper documents that U.S. legal process reaches provider-held data stored outside the United States (the Microsoft Ireland dispute, resolved by the 2018 SCA amendment), that partner-country orders can be served directly on providers under CLOUD Act agreements without prior U.S. review, and cites survey evidence that 'every single country that we examined vests authority in the government to require a Cloud service provider to disclose customer data', often including data physically stored abroad where a jurisdictional hook exists (s3://.../doj-cloud-act-white-paper-2019.md). The questionnaire's own answers align with that mechanism: access requires 'nothing beyond its standard terms of service or routine legal process', any party already in the subprocessor chain can act unilaterally, and the trigger set includes sanctions designation and litigation hold. MITRE ATLAS also records indirect access to an underlying model through an AI-enabled product or service as a Realized technique (AML.T0047), i.e. consumption of a model via a third-party product is a documented access path. What is missing for E:A is a documented case of this specific control — lawful-access or vendor-side disclosure at an undisclosed foundation-model inference host sitting behind a CRM subprocessor list — being exercised against a comparable multinational enterprise; the retrieved corpus contains no such case study, and the EU AI Act material returned speaks to transparency/provider-obligation duties (Art. 25 re-provider rules, Annex VIII/IX registration and DPIA summaries) rather than to realized incidents. That places the evidence at 'demonstrated in research/legal and incident reporting, not confirmed against this org's own stack' = P. Confidence is moderate because the inference transfers well-documented cloud lawful-access precedent onto the model-hosting layer by analogy rather than from a layer-specific case. CR Confidentiality Criticality (org context) H H questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. IR Integrity Criticality (org context) M M questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. AR Availability Criticality (org context) L L questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. S Regulatory Consequence P P agent Confirmed. The Model Layer exposure here is that email threads and call notes containing contract terms, pricing and personal contact details for customers in forty countries are processed by a foundation-model provider whose hosting location and jurisdiction Brightwater has never assessed, and which appeared on Orbit's subprocessor list only on the day the release shipped. That is independently reportable on two grounds: (a) processor/sub-processor engagement and cross-border transfer of EU personal data without a prior authorisation, transfer assessment or DPIA (GDPR Art. 28/Chapter V), and (b) the EU AI Act's express concern with AI systems established in third countries whose output is used in the Union, where the regulation applies precisely to prevent circumvention of EU protection (eu-ai-act-2024-1689). The DOJ CLOUD Act white paper documents that in global cloud estates even the provider may not know in which jurisdiction data sits, which is exactly the unanswerable question in dimension 1.1 and the reason the regulatory trigger stands on its own rather than needing a further compromise. AU Silent/Automatic Trigger Y Y agent Confirmed. Orbit Insights was shipped in a routine quarterly release and was on by default for all users, with the model subprocessor added the same day; no Brightwater decision, ticket or opt-in was involved (questionnaire: 'None: the vendor or subprocessor can act unilaterally'). A change of model host or model subprocessor behind a multi-tenant SaaS feature propagates to the whole customer base at once with no case-by-case action, which is the rubric's definition of Y. The rubric's own note on the sibling dimension 1.3 makes the same point: every downstream consumer of the model inherits an un-notified behaviour change. R Portability / Exit Recovery U U agent Confirmed. Nothing in the Model Layer is proprietary to Brightwater: the capability is generic thread summarisation and next-action suggestion. Brightwater holds no model weights (the rubric hooks R primarily to 1.2 model weight custody, and here custody sits entirely with the third-party provider), so reconstitution is not automatic — it would require procuring an alternative model/vendor, re-integrating with the CRM and re-contracting, i.e. manual migration effort rather than irrecoverable loss. The source CRM data remains in Brightwater's tenant, so no unique asset is trapped with the provider. V Blast-Radius Concentration D D agent Confirmed for this category. The undisclosed-jurisdiction model host sits behind exactly one feature — Orbit Insights summarisation/next-action inside the CRM. It is not a shared control plane for Brightwater's other AI workloads, so per the rubric it is 'scoped to one narrow workload' (D). Note the tension a reviewer should see: the blast radius is wide in terms of *data subjects* (forty countries, all CRM users, on by default) but narrow in terms of *AI workloads*, and V measures the latter. Confidence is moderated because the same model provider could later be wired into further Orbit features, which would move this toward C. RE Exit / Mitigation Effort L M agent · override Override of the prior M, on the category's own facts. For dimension 1.1 the exposure is the flow of regulated CRM content to an unassessed model host, and the scenario states that exposure is removable by a single administrative action: 'The feature can be disabled per tenant by an administrator.' Brightwater never adopted the feature and has no workflow dependency on it, so switching it off halts the cross-border inference entirely with no re-architecture, no data migration and no capability Brightwater was relying on — the rubric's L ('swap-out or contractual fix is trivial'). The prior M reflects the broader Orbit dependency (eight-year global enterprise agreement, re-contracting for subprocessor transparency), which is genuinely a project; but that is a governance/contract remediation for the vendor relationship, not the effort to mitigate this model-hosting exposure. A reviewer who scopes RE to 'retain the summarisation capability *and* obtain jurisdictional assurance' would reasonably read H (re-contracting), which is why confidence is held at 0.6. U Vendor Notice Posture Amber Red agent · override Override of the prior Red to Amber, on the precise rubric wording. Red is reserved for a vendor that *never* discloses sovereignty-relevant changes before they take effect in the sense of not disclosing them at all; Amber is 'discloses concurrently with the change taking effect'. The scenario records concurrent disclosure twice: the foundation-model provider 'appeared in an updated subprocessor list 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'. So a channel exists and was used — simultaneously, not in advance. The organisation's questionnaire answer ('it does not disclose them before they take effect') is literally true and is exactly what distinguishes Amber from Green/Clear, but it does not establish Red. The practical governance failure (Brightwater learned of the change only when a sales manager asked about summaries) is captured by AU=Y and by the absence of contractually guaranteed advance notice, not by inflating U. - MEDIUM6.3
2 What are we feeding it?
2.2 Internal documents ingested for RAG · also 2.1What is being fed to the AI feature is not staff-typed questions but Brightwater's own system of record: customer email threads, call notes, contract terms, pricing and personal contact details already stored in Orbit CRM. Brightwater never selected this content for AI processing — Orbit began reading and transmitting it on Brightwater's behalf when the feature shipped on by default for all users. No terms covering how the model provider logs, retains or has people review that content have ever been reviewed by Brightwater, because Brightwater did not know the provider was involved. The scope is the whole record store for forty countries, not a sample or a pilot.
Rating MEDIUM. Brightwater's most commercially sensitive and personal customer records have been flowing to an outside party under conditions nobody at Brightwater has read or approved.
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:N/E:P/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:D/RE:M/U:Amber Score 6.3 (Medium)
Ask the vendor What do our employees actually type into this thing, and does it include customer or confidential information? · Did we upload or connect any of our own internal documents for it to search? · Can this AI take real actions, look things up, change things, or does it only talk?
Metric Value Prior Source Rationale AV Access Path A N agent · override Override of the questionnaire's N. The prior describes the primary dependency (Orbit CRM running in the vendor's cloud, reached over its API). For dimension 2.2 the exposed asset is the corporate record set itself — email threads, call notes, contract terms, pricing, personal contacts — and the party that now receives it is the third-party foundation-model provider that appeared on Orbit's subprocessor list the day the release shipped. Brightwater has no API, contract or direct channel to that provider; the documents reach it only through Orbit's ingestion pipeline. That is precisely the rubric's 'Adjacent -- subprocessor-mediated access' rather than 'Network -- vendor-direct API access, no intermediary' (sovereignty_cvss_rubric_1.json, exploitability/AV). The rubric also flags AV as one of the two primary exploitability axes for 2.2, so the subprocessor hop is the determining fact rather than an aside. AC Compulsion Complexity L L agent Confirmed. Orbit's existing terms permit feature changes at its discretion with notice only at the time of release, and the subprocessor list was updated unilaterally on the same day. There are no customer-managed keys, no data-residency carve-outs and no per-region gating on the CRM content for customers in forty countries, so nothing had to be overcome to route stored records into the summarisation pipeline — the rubric's 'Low: a standard ToS clause ... suffices'. The only control that exists (per-tenant admin disable) is after-the-fact, not a barrier to ingestion. AT Trigger Conditions N P agent · override Override of the questionnaire's P. The prior reflects event-gated controls over the primary dependency (sanctions, litigation hold, incident). For the ingestion of internal documents no triggering event was or is needed: Orbit turned Orbit Insights on by default for all users in a routine quarterly release, as a pure product decision at its own discretion, and the records began flowing to the model subprocessor immediately. That matches 'None -- control can be exercised at vendor discretion at any time' (sovereignty_cvss_rubric_1.json). AT is listed as a primary exploitability axis for 2.2, and the scenario shows the discretionary path has already been exercised once. PR Position Required N N agent Confirmed. The party that gains readable access to the ingested documents is a foundation-model provider whose only standing is membership of Orbit's published subprocessor list — it need not be the primary contracted vendor, and no Brightwater administrative credential is involved (the admin role can only switch the feature off afterwards). This is the rubric's 'None -- any party already in the subprocessor chain has sufficient standing'. MITRE ATLAS AML.T0085.000 corroborates that a RAG store of this kind can expose 'the majority of an organization's internal documents' to whoever can query the service layer. UI Org Action Required N N agent Confirmed. Brightwater took no affirmative action: the feature was enabled by default in a vendor release, its AI governance review never triggered because nothing was adopted, and the exposure was discovered only when a sales manager noticed summaries appearing. The rubric names exactly this case under UI:N — 'vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature)'. Although summarisation is triggered by ordinary user activity (which would suggest P), the sovereignty-relevant decision to ingest the system of record was made unilaterally by the vendor, so N is the correct reading. VC Primary Dependency Impact -- Confidentiality H N agent · override Override of the questionnaire's 'no sensitive data exposed here'. That prior was answered about the primary dependency (the Orbit CRM platform relationship); for Category 2 / dimension 2.2 the named dependency IS the ingested document corpus, and the rubric assigns VC as a primary impact axis for 2.2 (sovereignty_cvss_rubric_1.json: id 2.2, primary_impact_axis ['VI','VC'], subsequent_impact_relevant false). The corpus being ingested is Brightwater's system of record: customer email threads, call notes, contract terms, pricing and personal contact details for customers in forty countries. All of it is read and transmitted to a third-party foundation-model provider that only appeared on the subprocessor list the day the feature shipped, under terms Brightwater has never reviewed, with no disclosure of logging, retention or human-review practice. Because the exposed set is the whole commercially and personally sensitive record store rather than a subset, this is a total/near-total loss on the confidentiality axis at the dependency itself. ATLAS material confirms that CRM/document corpora fed into retrieval pipelines are high-value collection targets (AML.T0082 credentials in RAG-ingested internal documents; AML.CS0037 where an agent retrieved all records from a victim's CRM). VI Primary Dependency Impact -- Integrity L N agent · override Override of the prior 'None', which again described the primary vendor relationship rather than the ingestion pipeline. Partial — not total — integrity loss applies here. Partial, because: (a) Brightwater has no control over what is ingested, when, by which model version, or under what retention — Orbit changes features at its discretion with notice only at release and does not disclose model/subprocessor/hosting changes before they take effect, so the composition and processing of the corpus can be altered without the org's knowledge or consent; (b) the ingested material includes inbound customer email threads, i.e. untrusted third-party content flowing automatically into a summarisation/next-action pipeline — the documented RAG-poisoning / false-RAG-entry pattern (ATLAS AML.T0070, AML.T0071, and AML.CS0059 where an emailed instruction was auto-ingested into the retrieval corpus), which Brightwater cannot detect or filter since it did not know the pipeline existed. Not High, because the authoritative CRM records themselves are not rewritten or destroyed by the feature; the system of record remains intact and the integrity loss is confined to the control and trustworthiness of the ingestion/summarisation layer. Hence 'partial or limited loss'. VA Primary Dependency Impact -- Availability N N agent Confirms the prior. Nothing in the scenario removes or degrades Brightwater's access to the ingested documents: the CRM records remain in Brightwater's tenant and are unaffected by whether Insights is on; the feature can be switched off per tenant by an administrator and the underlying CRM continues to operate, consistent with the questionnaire answer 'None: we could keep operating this component'. Availability is also not a primary impact axis for dimension 2.2 in the rubric. Availability concerns in this scenario are downstream (summary-dependent workflows), not at the document-input dependency. SC Downstream Blast-Radius Impact -- Confidentiality H H agent Confirms the prior. The documents ingested for summarisation are Brightwater's CRM system of record: customer email threads, call notes, contract terms, pricing and personal contact details for customers in forty countries. These leave the contracted boundary (Orbit) and reach a third-party foundation-model provider that appeared on the subprocessor list the same day the release shipped, with no DPA, retention or human-review terms ever reviewed by Brightwater. The rubric's own treatment of the analogous case — content handled by 'a DIFFERENT vendor than the LLM ... textbook Subsequent Confidentiality (SC) impact, since the [other] vendor was never the org's contracted AI vendor' — applies directly, and the taxonomy's note that 'no training on prompts' does not resolve logging, retention or human review means the exposure cannot be bounded downward. Questionnaire likewise records 'Full: sensitive data becomes readable by a party we never contracted with', and PR:None / UI:None mean any party in the subprocessor chain can realise it unilaterally. Near-total loss on this axis. SI Downstream Blast-Radius Impact -- Integrity L H agent · override Overrides the prior down from H. A real downstream integrity channel exists: ATLAS anchors RAG Poisoning and False RAG Entry Injection (AML.T0070, AML.T0071, maturity 'Demonstrated') to dimension 2.2, and AML.CS0059 shows ingested mail content steering an enterprise assistant's output undetected — so altered or fabricated summaries of contract terms and pricing could propagate into sales decisions. But the loss is partial, not near-total: Orbit Insights emits advisory summaries and 'suggested next actions' consumed by human sales users (indeed a sales manager's query is how Brightwater discovered the feature at all), not machine-executed actions, and the authoritative artefacts — the underlying email threads, call notes and CRM contract records — are not written to or altered by the feature. The questionnaire's 'downstream systems act on altered outputs without detection' describes the primary dependency's worst case; for this category's own exposure the altered outputs are human-mediated and checkable against the source thread. The rubric also marks 2.2 as subsequent_impact_relevant: false, arguing against a maximal downstream integrity rating here. SA Downstream Blast-Radius Impact -- Availability N L agent · override Overrides the prior from L to N for this category. On the availability axis, the relevant event is ingestion/summarisation ceasing — Orbit withdrawing the feature, the model subprocessor being cut off, or an administrator disabling it per tenant. Nothing downstream of the ingestion pipeline depends on the summaries: Brightwater never adopted the feature, no business process was built on it, and the CRM itself (the system of record for the forty-country customer base) keeps functioning unchanged. Disabling the feature is in fact the remediation, not a harm. The questionnaire's 'some downstream workloads degrade' is credited to the primary dependency rather than to document ingestion for RAG, and the rubric marks 2.2 subsequent impact as not normally relevant. Safety (S) is not applicable: the outputs are sales summaries for a consumer-goods manufacturer with no physical or safety-relevant control path. E Precedent Maturity P X agent · override Override of the questionnaire's X (respondent answered 'Unknown' to whether this control has been exercised). The corpus supplies direct, dimension-specific precedent anchors: MITRE ATLAS AML.T0070 'RAG Poisoning' and AML.T0071 'False RAG Entry Injection' are both rated 'Demonstrated -> CASE Precedent Maturity E:P' and are explicitly tagged as the CASE taxonomy anchor for dimension 2.2, i.e. exactly the exposure here (corporate records silently indexed and summarised by an external model). AML.T0085/.000 'Data from AI Services -> RAG Databases' (Demonstrated, E:P) describes collection of 'the majority of an organization's internal documents' through an AI service's retrieval path, and the case studies show the pattern against stacks closely comparable to Brightwater's: AML.CS0059 (an email auto-ingested into M365 Copilot's RAG index, zero-click exfiltration) and AML.CS0037 (an AI agent with Salesforce get-records and a customer-account CSV knowledge source used to pull an entire CRM). All of these are researcher exercises / demonstrations rather than confirmed attacks on a Fortune 500 CRM tenant, and nothing in the corpus documents Orbit-style default-on CRM summarisation being abused against a comparable organisation in the wild. That is the definition of P: demonstrated in research/incident reports but not confirmed against this org's own stack. U would understate a well-documented, repeatedly demonstrated technique class; A would overstate it, since the evidence base is exercises and the scenario itself reports only unexpected summaries appearing, with no observed loss event. Confidence is moderate-high: the technique precedent is explicit and 2.2-anchored, but precedent for the sovereignty-flavoured variant (vendor-initiated ingestion by an unreviewed subprocessor, rather than adversary poisoning) is only partially covered by the cited material. CR Confidentiality Criticality (org context) H H questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. IR Integrity Criticality (org context) M M questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. AR Availability Criticality (org context) L L questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. S Regulatory Consequence P P agent Confirmed. The ingested material is not prompts but the CRM system of record: customer email threads, call notes, contract terms, pricing and personal contact details for data subjects in forty countries. Those records began flowing to a third-party foundation-model provider that appeared on Orbit's subprocessor list the same day the release shipped, with no prior controller authorisation and no reviewed terms. The rubric's own worked example for S:P is exactly this ("GDPR Art. 28"): a processor engaging a new sub-processor to process controller personal data without prior authorisation, plus an undocumented cross-border transfer path and a processing activity absent from the Art. 30 record and any DPIA, is an independently reportable violation irrespective of any further compromise. The scale (40 countries, special categories of commercial sensitivity) makes the trigger unambiguous. Note: the EU AI Act text retrieved points the other way for Title III purposes — summarisation of a deployer's own text is an assistive function that does not substantially alter input semantics, so the AI Act transparency/high-risk hooks are weak here; the regulatory trigger rests on data-protection law, which is sufficient for P. AU Silent/Automatic Trigger Y Y agent Confirmed, and this category is where the metric bites hardest. Ingestion of internal documents started as a consequence of a routine quarterly platform release that was 'on by default for all users' — no tenant-by-tenant decision, no per-record selection, no adoption event. The corpus taxonomy names this pattern directly as dimension 7.2, 'silent AI feature addition', which is the mechanism by which 2.2 ingestion was initiated here. Because the trigger was a platform-wide release flag, the same document-ingestion exposure materialised simultaneously across Orbit's entire customer base, which satisfies 'can occur simultaneously across all customers with no case-by-case decision'. The questionnaire's own 'no action by your organization / vendor acts unilaterally' answers corroborate this. R Portability / Exit Recovery U U agent Confirmed as U, on the capability axis the metric measures. Brightwater retains custody of the underlying corpus — the records live in its own CRM tenant and are not vendor-generated artefacts — and the feature is disablable per tenant by an administrator, so the pre-feature state is restorable and equivalent summarisation could be reconstituted elsewhere with manual effort (re-integration, re-embedding, re-contracting). That is more than Automatic (an admin action plus a migration project is required, not a no-loss failover) and clearly short of Irrecoverable. Caveat the reviewer should see: the rubric attaches a recovery hook for data-input dimensions to deletion/purgeability (see 2.3 'R -> deletion SLA'), and on that reading the already-ingested content is not recoverable at all — Brightwater has reviewed no terms with the model provider, so retention, logging and human-review disposition of the summarised records is unknown and no deletion SLA is in hand. R:U therefore describes capability portability only; the disclosure itself is irreversible and should be treated as such in mitigation planning. V Blast-Radius Concentration D D agent Confirmed D, held deliberately against the temptation to escalate. The metric is defined by position in the critical path of AI workloads, not by volume of data at risk: Orbit Insights is one narrow workload (thread summarisation and next-action suggestions) and is not a shared control plane for Brightwater's other AI systems. The rubric also records subsequent_impact_relevant = false for 2.2, which is consistent with a scoped rather than concentrated footprint for this dimension. The counter-argument, which a reviewer may reasonably weigh differently, is that the ingested source is the single corporate system of record for forty countries and any future Orbit AI feature will draw on the same corpus behind the same undisclosed model provider — a data-concentration argument for C. I keep D because no second AI workload presently depends on this path, and record moderate confidence accordingly. RE Exit / Mitigation Effort M M agent Confirmed M. The stop-the-bleeding step is genuinely cheap — an administrator can disable the feature per tenant, halting further document ingestion with no re-architecture — which argues toward L. But mitigating the exposure rather than merely stopping it is a project: obtaining a DPA amendment and subprocessor-change rights from Orbit under an eight-year global enterprise agreement, establishing a lawful transfer basis and deletion assurance for records already summarised by a model provider whose terms Brightwater has never reviewed, updating Art. 30 records and running a retrospective DPIA, and closing the governance gap that let a default-on vendor feature bypass the AI review gate. That is moderate effort (re-contracting and process work) without physical infrastructure replacement, so neither L nor H fits. U Vendor Notice Posture Amber Red agent · override OVERRIDE of the prior (Red -> Amber). The rubric distinguishes Red ('never discloses sovereignty-relevant changes before they take effect') from Amber ('discloses concurrently with the change taking effect'), and the scenario facts match Amber specifically: the updated subprocessor list naming the foundation-model provider was published on Orbit's trust site the same day the release shipped, and Orbit's terms expressly allow feature changes at its discretion 'with notice at the time of release'. Disclosure therefore exists and is contractually anchored at T-zero — concurrent, not absent. Red would understate what Orbit actually does and would misdirect mitigation, since the realistic fix is to monitor the trust-site subprocessor feed and negotiate advance-notice/objection rights, not to assume no signal exists. Confidence is only moderate because the disclosure is pull-only (a trust-site posting Brightwater had no process to watch; it learned of the change when a sales manager asked about the summaries), which makes the practical effect close to Red; a reviewer who treats effective notice rather than published notice as the test should read this as Red. - HIGH7.9
3 What does it create from our data: and where does THAT go?
3.3 Model outputs / completions · also 3.6The feature produces thread summaries and suggested next actions that are shown to sales staff and written back into CRM records, where they become part of the customer file other staff rely on later. A summary of a pricing or contract conversation contains the sensitive substance of that conversation, so every summary carries regulated content to the outside model provider, and neither Orbit nor that provider has told Brightwater whether these outputs are kept for quality monitoring, for how long, or in which country. Brightwater has no way to detect it if the model behind the feature is changed and the summaries start being skewed, incomplete or simply wrong, because the vendor does not disclose such changes before they take effect. Staff are acting on these suggestions in front of customers with only partial review.
Rating HIGH. AI-written content is already part of Brightwater's authoritative customer record and is being acted on commercially, with no assurance that it is accurate and no record of where copies of it are kept.
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:L/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 Does this turn our documents into some kind of derived file (an “embedding”) so it can search them faster? · If so, who stores that derived file, you, or a completely different company? · Do you keep a copy of everything the AI said back to us, a log of how we used it, or a record of when we said the answer was wrong?
Metric Value Prior Source Rationale AV Access Path N N agent Orbit Insights runs in Orbit's own cloud and is reached over Orbit's API/UI; the summaries and suggested next actions are generated server-side and written straight back into the tenant's CRM records. For the actor set that matters here (Orbit itself, and the foundation-model provider that produces the completions), the output artefacts are directly network-reachable with no intermediary step required — Orbit can read/log every completion in its own platform, and the model provider sees the completion at generation time. The nested subprocessor relationship (model provider behind Orbit) argues for 'Adjacent', but since the exposure does not *require* traversing the subprocessor to reach the outputs, the rubric's 'Network -- vendor-direct API access, no intermediary' is the closer fit. Confirms the questionnaire prior. Rubric definition: sovereignty_cvss_rubric_1.json (exploitability.AV). AC Compulsion Complexity L L agent No technical or contractual barrier stands between the vendor chain and the completions. Orbit's terms expressly 'allow feature changes at its discretion with notice at the time of release', the feature shipped on-by-default, and the model provider was added to the subprocessor list the same day. There are no customer-managed keys, no output-retention carve-out, and no data-residency commitment covering summaries/next-action suggestions for customers in forty countries — retention policy and jurisdiction for logged outputs are simply unknown. A standard ToS clause therefore suffices: AC = Low, confirming the prior. Rubric: sovereignty_cvss_rubric_1.json (exploitability.AC 'standard ToS clause or routine legal process suffices'). AT Trigger Conditions N P agent · override OVERRIDE of the prior 'P'. The prior reflects the primary dependency framing (access compelled by a sanctions designation, litigation hold or incident). For this dimension the controlling fact pattern is different: whether and where model outputs are logged, retained and used for quality monitoring is a standing vendor/subprocessor product decision exercisable at any time, not one that waits on a triggering event. The scenario demonstrates this directly — Orbit turned on an output-generating AI feature for all tenants in a 'routine quarterly release', at its sole discretion under existing terms, and the organisation reports the vendor 'does not disclose [sovereignty-relevant changes] before they take effect'. The same applies to a silent model-version swap that would change the content of completions. Control over outputs is therefore exercisable at vendor discretion at any time: AT = None. Rubric: sovereignty_cvss_rubric_1.json (exploitability.AT 'None -- control can be exercised at vendor discretion at any time'). PR Position Required N N agent Confirms the prior. The completions are produced by a third-party foundation-model provider that Brightwater never contracted with and which appeared on the subprocessor list only on the day of release; that provider is already positioned to see, retain and alter the outputs without any additional standing. Orbit as prime vendor is likewise positioned. No compromise of Brightwater's own admin credentials is needed — the only Brightwater-side control (the per-tenant disable switch) is a mitigation, not a precondition for the vendor chain's access. PR = None per sovereignty_cvss_rubric_1.json (exploitability.PR 'any party already in the subprocessor chain has sufficient standing'). UI Org Action Required N N agent Confirms the prior, and this is the metric that most clearly carries the dimension. The rubric's 'None' value is defined with this exact fact pattern in mind — 'vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature)'. Brightwater took no affirmative action: the feature was enabled by default for all users in a vendor-side release, so summaries and next-action suggestions began being generated, surfaced to sales staff and persisted into CRM records with no adoption decision, no governance review (the AI governance gate 'never triggered because no one in the organisation adopted anything'), and discovery only when a sales manager noticed the summaries. A 'Passive' rating would understate this: ordinary use is not the trigger, the unilateral vendor change is. UI = None. VC Primary Dependency Impact -- Confidentiality H N agent · override Override of the questionnaire's 'N' (which was answered about the primary SaaS/API dependency, not about this category's artefact). The artefact at 3.3 is the generated summary / suggested next action. Every completion is a condensed restatement of customer email threads and call notes that, per the scenario, contain contract terms, pricing and personal contact details for customers in forty countries. Those completions are produced inside the third-party foundation-model provider's environment (vendor-cloud, direct API per the questionnaire) and, as the taxonomy's sovereignty question for 3.3 states, are typically logged by the vendor for quality monitoring under a retention policy and jurisdiction that are unknown here for both Orbit and the newly-listed model subprocessor. The model provider and Orbit therefore have, by construction, complete read access to the full population of outputs, with no technical or contractual barrier beyond standard ToS ('nothing beyond its standard terms of service or routine legal process') and no pre-notice of subprocessor/hosting changes. Total loss of confidentiality over the output artefact class = H. Corroborating: MITRE ATLAS AML.T0063 notes model outputs commonly persist in logs and API responses and can themselves carry sensitive information (mitigations M0012/M0019 exist precisely because output stores are a disclosure surface); the rubric assigns VC as the primary impact axis for output-type nodes. VI Primary Dependency Impact -- Integrity L N agent · override Override of 'N'. Integrity of the completions is not under Brightwater's control at all: Orbit's terms permit feature changes at its discretion with notice only at release time, the model subprocessor appeared the same day the feature shipped, and the vendor 'does not disclose [model versions, subprocessors, hosting, terms] before they take effect'. A silent model swap or prompt/template change therefore alters the content of every subsequent summary and suggested next action without Brightwater's knowledge — the rubric's own example of unilateral action (UI:N 'silent model swap') and the pattern it flags for versioning control nodes, where 'every downstream consumer of the model inherits an un-notified behavior change'. The loss is scored L rather than H because it is partial at the artefact layer: the authoritative source material (the original email threads, call notes and CRM fields) is unchanged and remains available for verification, summaries receive partial human review by the sales staff who consume them, and the organisation itself rates undetected output change as Moderate rather than severe. The full, undetected-propagation case is expressed on the subsequent axis (downstream systems acting on altered outputs), not here. VA Primary Dependency Impact -- Availability L N agent · override Mild override of 'N'. The same unilateral discretion that switched Orbit Insights on by default can switch it off, deprecate it, rate-limit it, or drop the model subprocessor (questionnaire: vendor/subprocessor can act unilaterally; loss 'could happen to all of the vendor's customers at once'). If that happens, generation of new summaries and next-action suggestions — this dimension's artefact — ceases entirely, and continued access to previously generated completions is governed by the vendor's undisclosed retention policy. The impact is scored L, not H, because the surrounding capability survives: the CRM itself keeps working, the dependency is scoped to 'one narrow workload' (rubric V:D, diffuse), exit/reconstitution is possible with manual migration effort (rubric R:U), and only 'some downstream workloads degrade'. So: real but limited availability loss on the artefact, no total loss of a critical-path capability. SC Downstream Blast-Radius Impact -- Confidentiality H H agent Confirmed. The artefacts in scope for 3.3 are thread summaries and suggested next actions generated from CRM records containing contract terms, pricing and personal contact details for customers in forty countries. A summary is not a sanitised abstraction of that material — it is a condensation of exactly its sensitive substance, and the prompt/completion pair necessarily carries the source content to the third-party foundation-model provider that appeared on Orbit's subprocessor list the same day the release shipped. Brightwater has no contract with that provider, and the taxonomy's 3.3 question (are outputs logged for quality monitoring, under whose retention policy and jurisdiction) is unanswered for both Orbit and the model provider. The EU AI Act places output logging under the provider's control and retention regime (Art. 19), which is precisely the sovereignty gap here. The questionnaire confirms full downstream confidentiality loss ('sensitive data becomes readable by a party we never contracted with') and that the event alone would trigger a reportable regulatory violation — consistent with forty-jurisdiction personal data reaching an undisclosed processor. Near-total loss on this axis. SI Downstream Blast-Radius Impact -- Integrity H H agent Confirmed. For this dimension the output *is* the downstream payload: summaries and suggested next actions are surfaced to sales staff and feed customer-facing decisions with only partial review, and the summaries are evidently persisted back into CRM records (secondary 3.6) that no one assessed, so a contaminated or silently re-versioned output becomes the system of record for later staff and any downstream process reading those fields. Orbit's terms permit feature changes at its discretion with notice only at release time, and the vendor does not disclose model-version or subprocessor changes before they take effect, so output behaviour can shift with no deployer-side detection point. ATLAS AML.CS0064 documents that output-level integrity compromise is hard to detect because the model behaves normally absent a trigger and manipulated output components appear relevant and trustworthy to the user; EU AI Act Art. 15(4) flags the feedback-loop risk where outputs influence inputs for future operations, which is the CRM write-back pattern here. The questionnaire's own answer is 'Full: downstream systems act on altered outputs without detection'. I note the org elsewhere rates undetected output change as only Moderate, but that rating is about the magnitude of a single bad summary, not about the propagation path; given unreviewed persistence into the authoritative customer record, H is the defensible value. SA Downstream Blast-Radius Impact -- Availability L L agent Confirmed. Loss or withdrawal of the completions is a degradation of convenience, not of the business process: Orbit CRM operated for eight years without Insights, the feature is tenant-disableable, and the questionnaire reports only that 'some downstream workloads degrade' with the capability reconstitutable elsewhere through manual migration. Partial, not total, availability loss downstream. S is not warranted: this is consumer-brands sales and account management, with no physical process, no safety-relevant actuation, and no pathway from a missing email-thread summary to bodily harm. The corpus returned nothing specific on availability of an auxiliary summarisation feature, so this rests on the scenario text, which is unambiguous on the point. E Precedent Maturity P X agent · override Override of the questionnaire's X: the corpus does contain evidence, but it stops short of a documented exercise of *this* control against a comparable organisation. The 3.3 sovereignty question is whether Orbit and the foundation-model provider log the generated summaries/next-action suggestions for quality monitoring, under whose retention policy and jurisdiction, and whether those outputs can change without Brightwater's knowledge. For the integrity half, ATLAS supplies multiple research demonstrations against precisely this artefact class — AI summarisation of customer mail/tickets feeding staff and downstream workflows: AML.CS0037 (Copilot Studio customer-service agent, Exercise), AML.CS0039 (Jira Service Management, Exercise), AML.CS0041 (assistant output manipulated via configuration, Exercise) — all mapped by the ATLAS README to E:P, plus AML.T0063 (model outputs persisted in logs/API responses, Demonstrated → E:P). For the confidentiality/retention half, the exposure rests on documented legal *capability* rather than a documented case: provider-held records are compellable regardless of storage location (18 U.S.C. §2713 / CLOUD Act white paper) and log retention is mandated for in-scope systems (EU AI Act Arts. 12 and 19), which matches the questionnaire's 'nothing beyond standard terms or routine legal process' and 'any party already in the subprocessor chain'. The one Realized/Incident precedent in the neighbourhood, AML.CS0072 / AML.T0130 (AI Recommendation Poisoning — assistant outputs biased and persisted in memory across M365 Copilot, ChatGPT, Perplexity, Grok; E:A), concerns third parties poisoning outputs rather than the vendor/subprocessor-side logging and retention control assessed here, so it is corroborating context, not grounds for A. No incident is confirmed against Orbit Insights or its undisclosed model provider, and Brightwater itself answers 'Unknown' to whether this control has been exercised against peers — which is the textbook definition of P ('demonstrated in research/incident reports, not confirmed against this org's own stack') rather than A. U is too low: this is far from theoretical, and the aggravating facts (default-on feature, subprocessor added the day of release, no pre-effective disclosure, summaries persisted back into CRM records no one assessed, downstream systems acting on altered outputs without detection) are the same conditions the cited demonstrations exploit. CR Confidentiality Criticality (org context) H H questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. IR Integrity Criticality (org context) M M questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. AR Availability Criticality (org context) L L questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. S Regulatory Consequence P P agent Confirmed. The completions here are summaries of customer email threads and call notes for data subjects in forty countries, generated by a foundation-model provider that first appeared on Orbit's subprocessor list the same day the feature shipped. Processing of that personal data by an unannounced subprocessor, with no prior authorisation or objection window and with output logging/retention location unknown for both Orbit and the model provider, is independently reportable under GDPR Art. 28(2)/(3) (sub-processor authorisation and flow-down) and Arts. 5/13-14/44 (transparency and transfer basis) — the rubric names Art. 28 as the archetypal trigger for S=Present. Additionally, because the generated summaries are surfaced to sales staff with only partial review and persisted back into CRM records, the org cannot demonstrate accuracy or satisfy access/erasure requests over these derived artefacts; the AI Act likewise treats generated text and its logs as artefacts carrying provider/deployer duties (Art. 50 marking of generated content, Arts. 19/26 log retention), reinforcing that an uncontrolled-output condition is a compliance event in its own right. AU Silent/Automatic Trigger Y Y agent Confirmed, and it is if anything more clearly Yes for this category than for the primary dependency. Orbit Insights was enabled by default for all users in a routine quarterly release, so output generation — and whatever vendor-side logging of those completions accompanies it for quality monitoring — began for every tenant simultaneously with no per-customer decision or opt-in. The same holds for a future silent model-version or subprocessor change behind the feature: Orbit's terms permit feature changes at its discretion, so output behaviour and output custody can change fleet-wide at once. R Portability / Exit Recovery U U agent Confirmed as User. The underlying source material (emails, call notes, CRM records) remains Brightwater's, so the summarisation capability can be rebuilt on another model or an in-tenant service, but only with manual effort: re-integration into CRM, re-prompting/re-generation, and re-contracting. Reconstitution is not loss-free — the existing completions already written into CRM records are non-deterministic artefacts that a different model will not reproduce identically, and any copies retained in Orbit's or the model provider's quality-monitoring logs are outside Brightwater's reach to export or purge. That is manual-migration-with-degradation, not Irrecoverable (no proprietary weights or unique corpus are locked in). V Blast-Radius Concentration D D agent Confirmed as Diffuse on the rubric's own terms: V measures whether the dependency sits in the critical path for many or all of the organisation's AI workloads (a shared control plane). The output-generation path here serves exactly one workload — Orbit Insights thread summarisation and next-action suggestion — and no other Brightwater AI workload consumes these completions. Noted tension: the completions are persisted back into the enterprise CRM system of record used by sales across forty countries, so the *business* blast radius of corrupted or leaked outputs is wide (hence the Full subsequent-impact answers); but that breadth is captured by the subsequent-impact metrics, not by Value Density, which would double-count it here. RE Exit / Mitigation Effort M M agent Confirmed as Moderate. Stopping further exposure is cheap — an administrator can disable the feature per tenant — so the kill-switch alone would read Low. But mitigating this category's actual exposure is a project: identifying and remediating the summaries and suggested next actions already written into CRM records across forty countries, establishing what the model provider and Orbit log and retain of the completions and under which jurisdiction, obtaining contractual retention/no-training commitments and subprocessor notice rights, and running the DPIA/AI-governance review that never triggered. None of this requires re-architecting Brightwater's systems or replacing infrastructure, which rules out High. U Vendor Notice Posture Amber Red agent · override Override of the Red prior. The rubric reserves Red for a vendor that *never* discloses sovereignty-relevant changes before they take effect, and Amber for disclosure *concurrent* with the change. The scenario shows concurrent disclosure, not absent disclosure: 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. The disclosure was useless for pre-adoption review — which is why Brightwater's AI governance gate never fired and the feature was only noticed when a sales manager asked — but it did occur simultaneously with the change, which is the definition of Amber. The questionnaire answer ('does not disclose them before they take effect') is literally true and is fully consistent with Amber; mapping it to Red overstates the posture. No advance or contractually guaranteed notice exists, so Green/Clear are excluded. - HIGH7.1
4 Who's deciding what the AI sees and does?
4.2 Orchestration / agent framework · also 4.4Every step between Brightwater's CRM data and the AI model sits inside Orbit's own platform: Orbit decides which email threads and call notes are picked up, how they are bundled together, which model provider receives them, what filtering is applied, and how the suggestion is shown to the sales user. Brightwater has no visibility into any of those decisions and no ability to constrain them; the eight-year-old enterprise agreement predates AI features entirely and says nothing about them. Orbit can rewire any part of that chain at its discretion and is not obliged to tell Brightwater beforehand. That means Brightwater cannot state which customer records are selected for processing, nor evidence that the selection has not changed.
Rating HIGH. Brightwater has no insight into, and no say over, how its customer data is gathered up and sent to an AI model — it must simply take the vendor's word.
Evidence: vector, score and 21 metric rationales
Vector SOV:1.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/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.1 (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?
Metric Value Prior Source Rationale AV Access Path N N agent Confirms the prior. The entire orchestration layer for Orbit Insights — which email threads and call notes get selected, how they are assembled into a model call, which provider receives the call, how the suggestion is rendered back into the CRM UI — executes inside Orbit's own multi-tenant cloud and is reached only over Orbit's API. Nothing of the agent loop is resident in a Brightwater-managed environment, so there is no 'Local' or 'Physical' boundary to cross. The access path to the pipeline is the primary contracted vendor's own hosted service: Network. (ATLAS case studies on SaaS copilots describe exactly this topology — the provider control plane and its internal retrieval/assembly pipeline are the reachable surface, not any customer-side component: s3://case-dev-559335786764-corpus-content/atlas/techniques/AML.T0006.md, s3://case-dev-559335786764-corpus-content/atlas/case-studies/AML.CS0059.md.) AC Compulsion Complexity L L agent Confirms the prior. The scenario states plainly that 'Orbit's terms allow feature changes at its discretion with notice at the time of release' — i.e. a standard ToS clause is the whole of the authority needed to introduce, re-route or re-wire the orchestration chain. There are no customer-managed keys, no data-residency carve-out, no pinning of the prompt-assembly logic or the downstream provider in the eight-year-old enterprise agreement (which predates any AI feature and cannot plausibly name this pipeline). The EU AI Act anticipates that technical access and assistance between a system provider and its component suppliers must be *specified by written agreement* to be guaranteed; absent such terms there is no barrier to overcome (s3://case-dev-559335786764-corpus-content/eu-ai-act-2024-1689.md). AT Trigger Conditions N P agent · override OVERRIDE of the prior 'P'. The prior fits dependencies where control is latent until a sanctions designation, litigation hold or incident occurs. For the orchestration layer the scenario demonstrates the opposite: the pipeline was stood up and switched on for every tenant in a 'routine quarterly release', on by default, as a pure product decision with no triggering event whatsoever. Orbit's terms permit feature changes 'at its discretion', and the vendor 'does not disclose [sovereignty-relevant changes] before they take effect' — so the selection logic, the assembly of CRM content into prompts, the choice of foundation-model provider and any guardrail in the chain can all be altered at vendor discretion at any time. That is AT:N. (The questionnaire's own answer lists 'product decision' alongside the genuine trigger events, which collapses to vendor discretion for this layer.) ATLAS material on hosted copilot pipelines likewise treats changes to the provider-side retrieval/assembly and safety-filter configuration as something the operating party can do unilaterally, without an external trigger: s3://case-dev-559335786764-corpus-content/atlas/techniques/AML.T0081.md. PR Position Required L N agent · override OVERRIDE of the prior 'N', narrowing it to this category. The questionnaire's 'any party already in the subprocessor chain' is correct for the data-exposure dependency (Category 7): the foundation-model provider and any guardrail/safety filter in the chain see the CRM content without needing Orbit's standing. But the control this dimension measures — which threads and notes are selected, how they are assembled into a call, which provider is routed to, how the suggestion is rendered — is Orbit's own internal loop. Only the primary contracted vendor holds that position; a downstream subprocessor can alter what a model returns but cannot re-wire the selection and assembly stages. That maps to PR:L (requires being the primary contracted vendor). It is not H, since nothing requires compromising Brightwater's administrative credentials: Brightwater's admin role here is purely a per-tenant off switch it did not know to use. Confidence is moderate because the scenario does not itemise which chain participants hold configuration rights over the pipeline (consistent with the classifier's low-moderate confidence note for this category). UI Org Action Required N N agent Confirms the prior, and this is the strongest-evidenced metric in the group. The orchestration pipeline was introduced by the vendor unilaterally: 'on by default for all users', discovered only when a sales manager asked why summaries were appearing, with the subprocessor list updated the same day the release shipped and notice only at release time. Brightwater took no affirmative action — its AI governance review 'never triggered because no one in the organisation adopted anything' — so this is not A, and it is more than P (ordinary use) because the exposure was created by the vendor's act, not by Brightwater's usage pattern. This is the textbook 'silently added AI feature' case for UI:N. ATLAS's M365 Copilot case study documents the same property: the provider-side pipeline ingests and acts on enterprise content with zero required user interaction (s3://case-dev-559335786764-corpus-content/atlas/case-studies/AML.CS0059.md). VC Primary Dependency Impact -- Confidentiality L N agent · override Override of the questionnaire's N (which was answered about the primary dependency, the foundation-model provider). Assessed at dimension 4.2 itself: Orbit's internal agent loop is the component that selects which email threads and call notes are read, assembles them into a provider call, and renders the result. It therefore necessarily reads contract terms, pricing and personal contact details for customers in forty countries, and it also mints new derived artifacts (prompt payloads, selection metadata, summaries) that Brightwater never sees or logs, since the loop runs ahead of Brightwater's own logging. This is not a *total* new confidentiality loss at this node, because Orbit already lawfully holds the same CRM records under the eight-year enterprise agreement; what is newly exposed is the orchestration-layer copy and its derivatives, with zero tenant visibility. The rubric does not list VC as a primary axis for 4.2 (primary_impact_axis: ['VI'], s3://case-dev-559335786764-corpus-content/sovereignty_cvss_rubric_1.json), and the full third-party readability lands downstream (SC). Hence partial, not high. VI Primary Dependency Impact -- Integrity H N agent · override Override of the prior N. The rubric designates VI as the primary impact axis for dimension 4.2 'Orchestration / agent framework' (primary_impact_axis: ['VI'], subsequent_impact_relevant: true). Every behavioural parameter of this loop is set unilaterally by Orbit: which threads/notes are selected, how they are concatenated into a call, which foundation-model provider receives them, what guardrail filter inspects input and output, and how the suggestion is rendered to the sales user. Orbit's terms allow feature changes at its discretion with notice only at the time of release, and the questionnaire records that it 'does not disclose [sovereignty-relevant changes] before they take effect'. Brightwater had no visibility at all until a sales manager asked why summaries were appearing, so the behaviour of this component can be altered end to end without the tenant's knowledge or consent — near-total loss of integrity control at the dependency. The rubric's analogous reasoning for 1.3/6.4 (un-notified behaviour change inherited by every downstream consumer → VI) and ATLAS AML.T0124's note that orchestration-layer constraints and scope-drift detection are only available where the organisation has 'sufficient administrative control' (it has none here) both support H. VA Primary Dependency Impact -- Availability L N agent · override Partial override of N. The questionnaire's 'we could keep operating this component' is true of the CRM of record, but the orchestration loop itself exists only inside Orbit's cloud: a quarterly release decision, a provider swap, or rate limiting can degrade or retire it for all tenants at once (the questionnaire confirms the loss event is non-case-by-case and vendor-unilateral). That is a real but bounded availability loss at this node: only one narrow workload depends on it, the capability is reconstitutable with moderate manual migration effort, and the same release mechanism that enabled Insights can disable it without touching core CRM availability. Partial loss (L) rather than total (H) or none (N). SC Downstream Blast-Radius Impact -- Confidentiality H H agent CONFIRM. The orchestration layer is the mechanism by which confidentiality is lost beyond Orbit: Orbit Insights' internal loop selects which email threads and call notes to pull and assembles them into a provider call, so it is the component that decides what contract terms, pricing and personal contact details for customers in forty countries leave the tenant boundary. The recipient is a third-party foundation-model provider that appeared on the subprocessor list the same day the release shipped and is not covered by the eight-year-old enterprise agreement — i.e. sensitive data becomes readable by a party Brightwater never contracted with, matching the questionnaire's 'Full' downstream confidentiality answer. Brightwater has zero visibility into which records the loop selects, so the loss is unbounded from its perspective, which is the 'total or near-total' end of the axis. ATLAS AML.CS0059 and AML.CS0037 document exactly this pattern of a vendor-hosted assembly/retrieval loop moving enterprise records to an onward endpoint without tenant observability. SI Downstream Blast-Radius Impact -- Integrity H H agent CONFIRM, with the caveat below. Everything that determines the content of a summary is inside Orbit's loop: which threads and notes are selected, how they are concatenated into the prompt, which provider version answers, and how the suggestion is rendered to the sales user. Orbit can change any of those steps unilaterally under terms that allow feature changes at its discretion, and it does not disclose model-version/subprocessor/hosting changes before they take effect. The downstream consumers are Brightwater's sales staff and the next-action decisions they take on contract and pricing conversations; because the guardrail/filter and the chain see every input and output before Brightwater's own logging does, an altered or silently biased summary is acted on without any means of detection — the questionnaire's 'Full: downstream systems act on altered outputs without detection'. The rubric assigns 4.2 exactly this axis (primary VI, subsequent impact relevant) and notes for 4.1 that a party controlling what is fed to the model creates subsequent integrity impact on later pipeline stages; ATLAS AML.T0130/AML.CS0072 show biased outputs being presented to users as neutral recommendations. Caveat lowering confidence: the scenario describes no agentic tool execution and no autonomous writes back into the CRM, and a human reads each suggestion, so an argument for L exists; H is chosen because the complete absence of tenant visibility leaves the extent of alteration unbounded rather than demonstrably partial. SA Downstream Blast-Radius Impact -- Availability L L agent CONFIRM. If Orbit withdraws, degrades or re-points its orchestration loop — a unilateral product decision it can take for all tenants at once — what stops working downstream is summary generation and next-action suggestions. The CRM system of record, its data and all non-AI sales workflows continue to function, and the questionnaire itself reports only that 'some downstream workloads degrade' and that the capability could be reconstituted with manual migration effort. That is partial, not total, downstream availability loss. S is not warranted: this is consumer-brands sales and account management with no cyber-physical or life-safety coupling, so loss of summarisation cannot cause physical harm or a safety-relevant failure. No corpus source addressed availability of an optional SaaS summarisation add-on, so this is reasoned from the scenario and questionnaire. E Precedent Maturity P X agent · override Override X (questionnaire answered 'Unknown') to P. The rubric defines E:P as 'demonstrated in research/incident reports, not confirmed against this org's own stack', and the corpus README states the mapping explicitly: ATLAS 'Demonstrated / Exercise' case studies -> CASE E:P, 'Incident/Realized' -> E:A. For dimension 4.2 the exposure is a vendor-hosted copilot orchestration loop that selects which threads/notes are assembled, which provider receives them and how the suggestion is rendered. There are multiple published demonstrations of exactly that machinery being manipulated or made to leak at comparable SaaS platforms, but they are all Exercise-type: AML.CS0035 'Data Exfiltration from Slack AI via Indirect Prompt Injection' (PromptArmor, 2024-08-20, Exercise -> E:P) — a SaaS assistant's own internal ingest/retrieve/render loop caused to surface private-channel data and render it as an exfiltration link, the closest analogue to Orbit Insights summarising email threads and call notes; AML.CS0037 'Data Exfiltration via Agent Tools in Copilot Studio' (Exercise), in which the orchestrated agent retrieves all records from the victim's CRM; AML.CS0039 'Living Off AI: Prompt Injection via Jira Service Management' (Exercise), where a vendor-embedded agent loop executes attacker text arriving through ordinary customer-facing content. No corpus source documents a realized incident in which an unreviewed, default-on SaaS copilot's orchestration loop was actually used to alter or divert a customer's data at a comparable organisation, and nothing confirms it against Brightwater/Orbit specifically — Brightwater has no visibility into the loop, so it could not confirm one either. That rules out A. It is clearly more than theoretical, which rules out U. (The one Realized/E:A orchestration entry returned, AML.T0124 Autonomous Attack Orchestration / AML.CS0071, describes adversary-operated multi-agent frameworks, not a vendor's internal copilot pipeline, so it does not support A for this dimension.) Confidence is moderate rather than high because the scenario describes no agentic tool execution and no explicit retrieval/reranking stage, so the demonstrated precedents are adjacent rather than exact matches. CR Confidentiality Criticality (org context) H H questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. IR Integrity Criticality (org context) M M questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. AR Availability Criticality (org context) L L questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. S Regulatory Consequence P P agent Confirmed. Orbit's internal loop is the machinery that selects CRM threads/notes and assembles them into a provider call; the same loop passes every input and output through an unnamed guardrail/filter stage before Brightwater's own logging sees anything. Because the data concerned is contract terms, pricing and personal contact details for customers in forty countries, a loss of control in this layer is by itself an unauthorised-processing/undisclosed-sub-processing event: the controller (Brightwater) had no prior authorisation of, and no ability to object to, the processing chain added on release day, and cannot produce an accurate record of processing or a DPIA for a pipeline it cannot see. That is an independently reportable violation (GDPR Art. 28(2)/(3), Art. 30/32), not merely a contractual grievance. Note: the corpus returned no GDPR text, so this rests on the scenario facts and the rubric definition of S; the retrieved EU AI Act material (Art. 50 transparency) is only weakly applicable because summarisation may fall under the assistive-editing carve-out, which is why confidence is moderate rather than high. AU Silent/Automatic Trigger Y Y agent Confirmed, and this dimension is where the automaticity is most visible: the orchestration loop arrived in a 'routine quarterly release', on by default for all users, with no customer decision anywhere in the path. Orbit's orchestration is a shared, multi-tenant, vendor-hosted control plane (the 4.2 'vendor-hosted internal agent loop' end of the spectrum), so any change to how threads are selected, which provider receives the assembled call, or which filter inspects it propagates to every tenant simultaneously with no case-by-case action. Brightwater's own AI governance gate never fired precisely because no per-customer adoption step exists. R Portability / Exit Recovery U U agent Confirmed as User. The specific orchestration artefacts (selection logic, prompt assembly, routing, guardrail configuration) are wholly vendor-internal and cannot be exported — nothing of this layer is portable. But the rubric asks whether the capability can be reconstituted, and the capability here is thread/note summarisation over CRM records: no proprietary customer-side asset is held hostage (no fine-tuned weights, no vendor-only embedding index is described), and the underlying data remains Brightwater's in the CRM. Rebuilding equivalent orchestration against the CRM API or a different add-on is a manual re-integration and re-contracting exercise, not an impossibility, so U rather than I. V Blast-Radius Concentration D D agent Confirmed as Diffuse, with a caveat. From Brightwater's side the orchestration loop is in the critical path of exactly one AI workload — the Orbit Insights summarise/suggest-next-action feature; the scenario describes no other AI workloads riding on Orbit's orchestration, no agentic tool execution and no explicit retrieval/reranking stage. The genuinely concentrated aspect is the data the loop touches (the whole CRM estate across forty countries) and the fact that it is a shared vendor control plane, but data breadth is already captured by the confidentiality/integrity impact axes and cross-tenant simultaneity by AU; V as defined here keys on how many of the assessed organisation's AI workloads sit behind the dependency. C would be the right call if Brightwater later layers further AI features on the same Orbit platform. RE Exit / Mitigation Effort M M agent Confirmed as Moderate. The immediate kill switch is cheap — the scenario states the feature can be disabled per tenant by an administrator, which alone would argue for L. But durable mitigation of this dimension is not a toggle: Brightwater must obtain contractual change-notice and sub-processor-objection rights, visibility/logging into a loop Orbit does not expose, and a standing control for default-on AI features, all against an eight-year-old global enterprise agreement whose terms expressly permit discretionary feature changes. That is a project — re-contracting and governance work — but it requires no re-architecture of Brightwater's own systems and no infrastructure replacement, so M, not H. U Vendor Notice Posture Amber Red agent · override Override of the questionnaire's Red to Amber on explicit scenario evidence. The rubric distinguishes Red ('never discloses sovereignty-relevant changes before they take effect') from Amber ('discloses concurrently with the change taking effect'). Orbit's observed and contracted behaviour is concurrent, not absent: the updated sub-processor list naming the third-party foundation-model provider was published on the trust site 'the same day the release shipped', and the terms allow feature changes at Orbit's discretion 'with notice at the time of release'. Disclosure therefore exists but carries zero lead time and no contractual advance-notice guarantee (which rules out Green/Clear). The counter-argument for Red is real and is why confidence is only moderate: the changes that matter most for 4.2 — prompt/assembly changes, which provider receives a call, which guardrail inspects inputs and outputs — are intra-loop and were never individually announced; only the sub-processor identity and the feature launch were. If a reviewer judges that intra-loop changes go wholly undisclosed, Red is defensible. Practically, Amber here is barely better than Red, since same-day notice gave Brightwater no opportunity to object before CRM data flowed. - MEDIUM5.6
5 Which humans are actually looking at our stuff?
5.3 Support / debugging access · also 5.1The scenario does not tell us whether people read Orbit Insights content, and Brightwater cannot establish either way. The realistic exposure is routine support and troubleshooting: Orbit's support engineers, and now engineers at the foundation-model provider, can read the logs, traces and message content generated by a brand-new feature under a generic support-access clause in an eight-year-old contract that was never written with AI in mind. Those logs and traces carry contract terms, pricing and personal contact details for customers in forty countries. Nothing in the arrangement limits who may look, requires a documented reason, masks the data, or produces a record Brightwater can inspect afterwards.
Rating MEDIUM. Named individuals at two companies — one of which Brightwater never contracted with — may be able to read customers' pricing and personal data in plain text, and Brightwater would have no record of it.
Evidence: vector, score and 21 metric rationales
Vector SOV:1.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:M/AR:L/S:P/AU:N/R:U/V:D/RE:M/U:Amber Score 5.6 (Medium)
Ask the vendor Does a real person at your company, or a contractor of yours, ever read our conversations or our data? · If a conversation gets flagged, does it go somewhere else to be reviewed or labeled? · When your support engineers debug a problem for us, what can they see?
Metric Value Prior Source Rationale AV Access Path A N agent · override Override N -> A. The questionnaire prior describes the primary dependency (Orbit's own SaaS, reached directly over its API). For dimension 5.3 the live access path is human support/debugging access to the logs and traces of the new Orbit Insights pipeline, and the party whose engineers newly gained that reach is the third-party foundation-model provider that appeared on Orbit's subprocessor list the day the release shipped. Brightwater has no contract with that provider; its staff reach the email-thread and call-note content (contract terms, pricing, personal contact details) only through the Orbit-mediated integration, i.e. subprocessor-mediated access rather than vendor-direct. The rubric reserves A for exactly this mediated case (sovereignty_cvss_rubric_1.json, AV values). Orbit's own support engineers do have a vendor-direct path, so this is a close call; A is chosen because the sovereignty-relevant new exposure in this dimension is the uncontracted subprocessor's debugging reach. AC Compulsion Complexity L L agent Confirm L. Support/debugging access here rests on a generic 'support access' clause in an eight-year-old global enterprise agreement, and Orbit's terms expressly allow feature changes at its discretion. Nothing in the scenario indicates customer-managed keys, tenant-held encryption, data-residency carve-outs, access-transparency/access-approval controls or a support-personnel-location commitment of the kind hyperscalers offer as add-on sovereign controls (google-cloud-sovereign-controls.md: technical support access limited by underlying data access controls, administrative access logged and permitted only under predefined conditions; microsoft-eu-data-boundary.md: system-generated logs routinely contain personal data and require pseudonymisation only where the provider commits to it). Absent such barriers, standard terms suffice — Low. AT Trigger Conditions P P agent Confirm P. Debugging/support access is characteristically exercised on a trigger — a raised support ticket, a defect or latency investigation in the newly shipped feature, an abuse/quality flag, or a security incident — rather than continuously at the provider's whim; reference sovereign-control frameworks model exactly this as justification-bound administrative access permitted 'only under predefined conditions' (google-cloud-sovereign-controls.md). Counter-argument noted: because the feature is brand new and under active stabilisation, triggering events are frequent and Brightwater cannot observe them, so the practical difference from 'at discretion' is small; confidence is therefore moderate. AT is also not a primary exploitability axis for 5.3 (rubric lists PR, AC). PR Position Required N N agent Confirm N. PR is a primary axis for 5.3 (rubric). No elevated standing is needed: any party already inside the subprocessor chain — Orbit's support/SRE engineers and now the foundation-model provider's engineers operating under its own support and abuse-review processes — can read the prompts, traces and logs produced by Orbit Insights. Brightwater never contracted with, approved or even knew about that second party before the release, so its staff obtain standing purely by being in the chain, not by compromising Brightwater credentials or by being the primary contracted vendor. UI Org Action Required N N agent Confirm N. The exposure exists because Orbit unilaterally enabled Orbit Insights on by default for all users in a routine quarterly release and added a new subprocessor the same day, with notice only at release time and no pre-change disclosure. Brightwater took no affirmative action — its AI governance review never triggered precisely because nobody adopted anything — so the content now visible to support/debug personnel was routed there by the vendor alone. The rubric's N definition explicitly covers a 'silently added AI feature'. (A Passive reading is arguable, since logs only fill as sales users keep working in the CRM, but the decisive act was the vendor's.) VC Primary Dependency Impact -- Confidentiality H N agent · override Override of the questionnaire's 'None'. The questionnaire answer describes the primary dependency (the model API call path), where Brightwater judged no sensitive data to be exposed at the node itself. This category's node is different: 5.3 support/debugging access, i.e. Orbit support engineers and now the newly listed foundation-model provider's engineers reading logs, traces and prompt/response payloads to debug a feature that shipped the same day the subprocessor appeared. The rubric defines vulnerable-system impact as CIA loss AT the dependency named by the taxonomy node (sovereignty_cvss_rubric_1.json, vulnerable_system_impact), and lists VC as the primary impact axis for the Human-in-the-Loop nodes. At this node the asset IS the raw payload: Orbit Insights summarises customer email threads and call notes for all users (on by default, tenant-wide), so debug telemetry spans contract terms, pricing and personal contact details for customers in forty countries. A human being able to read that in cleartext is a confidentiality loss that bypasses every technical control, and it is not a narrow sample — the feature ran for the whole tenant until a sales manager noticed. Access is governed by a generic 'support access' clause ('nothing beyond standard terms of service'), exercisable unilaterally by 'any party already in the subprocessor chain', with no pre-notification of subprocessor/hosting changes. Treated as near-total loss (H) within the scope of this dependency rather than L, because nothing in the scenario or contract scopes, minimises, pseudonymises or logs such access; EU AI Act Art. 10(5)/recital 69 treat exactly these safeguards (strict access control and documentation of access, data minimisation, no onward access by other parties) as the thing that keeps such exposure bounded, and none is evidenced here. Confidence held moderate because the scenario is silent on whether support/debug access actually occurred. VI Primary Dependency Impact -- Integrity L N agent · override Partial override, flagged as weakly evidenced. Debug/support access is predominantly read-oriented, which is why the rubric names only VC as the primary impact axis for this node. However, support engineers holding break-glass access to a live tenant typically can also change tenant configuration, feature flags, prompt templates or model routing while troubleshooting, and Brightwater has no visibility into such changes: Orbit's terms allow feature changes at its discretion with notice only at release time, it 'does not disclose [sovereignty-relevant changes] before they take effect', and the organisation only discovered the feature itself by accident. That is a limited, undetected alteration of the dependency's behaviour rather than total control of it, so L rather than H. The logging/record-keeping expectations in EU AI Act Art. 12-13 (deployer must be able to collect, store and interpret logs and interpret outputs) underline that without such change-visibility the deployer cannot rule out alteration. Low confidence: the scenario gives no direct evidence of write-capable support access; a reviewer who insists on evidence-only scoring could justifiably keep N. VA Primary Dependency Impact -- Availability N N agent Confirmed. A support/debugging access path is an observation and maintenance channel; exercising it does not withdraw or degrade the capability. Consistent with the questionnaire ('None: we could keep operating this component'), and with the scenario: the feature is tenant-controllable (an administrator can disable it) and the CRM of record continues to function regardless of who reads the debug traces. No availability loss at this node. SC Downstream Blast-Radius Impact -- Confidentiality L H agent · override Override H -> L. For dimension 5.3 the rubric itself records "subsequent_impact_relevant": false (sovereignty_cvss_rubric_1.json, entry id 5.3 'Support / debugging access', primary impact axis VC only), so the dominant loss for this node sits at the dependency, not downstream. There is still a non-zero subsequent-confidentiality path, consistent with the rubric's note on 2.1 that prompts reaching human eyes in Category 5 'become Subsequent Confidentiality impact': Orbit support engineers and now the foundation-model provider's engineers can pull logs/traces of Orbit Insights under a generic support clause, so raw email-thread and call-note content containing contract terms, pricing and contact details for customers in 40 countries can land in the ticketing/debug tooling of a party Brightwater never contracted with (questionnaire: 'sensitive data becomes readable by a party we never contracted with'; subprocessor added the day the release shipped, no pre-notice). The magnitude is partial rather than near-total because support/debug access is incident-driven and sampled - it exposes whatever traces a given ticket touches for one narrow workload, not a bulk copy of the CRM record set. Hence L. Third-party-risk guidance treats exactly this (whether the third party may 'permit access to customer data ... to other entities') as a contract control that was never negotiated here (interagency-third-party-risk-guidance-2023.md). SI Downstream Blast-Radius Impact -- Integrity N H agent · override Override H -> N. The questionnaire's 'downstream systems act on altered outputs without detection' describes the primary dependency (a silent model/feature change by Orbit or the model provider), not this category's access path. Support/debugging access is a read-and-diagnose path: an engineer inspecting logs and traces does not change the summaries or next-action suggestions that Brightwater's sales users consume, and the scenario gives no evidence that the support clause carries write/config privileges over tenant behaviour. The rubric marks 5.3 as not subsequent-impact-relevant and assigns it no integrity axis at all (primary_impact_axis: ['VC']), while integrity-driven dimensions are handled elsewhere (e.g. 1.3 model update/versioning, 6.4 configuration and policy management). Assigned N rather than L because any integrity story here would be speculation on top of an already low-confidence category inference. SA Downstream Blast-Radius Impact -- Availability N L agent · override Override L -> N. Nothing about support or debugging access withdraws or degrades a capability downstream: the exercising party here is reading telemetry, not switching a service off, and the questionnaire itself records that the capability could not be withdrawn at this dependency ('we could keep operating this component'). Availability-propagating dimensions in the rubric are the control-plane ones (6.1 admin console, 6.3 API gateway - 'a gateway outage takes down access to the underlying service'), not 5.3, which the rubric flags subsequent_impact_relevant: false. S (safety) is excluded: Orbit Insights produces CRM summaries and next-action suggestions for sales staff, with no physical-harm or safety-relevant failure mode; the real consequence of exposure here is regulatory (GDPR-type processor/subprocessor and disclosure obligations), which the model routes through the supplemental safety-to-regulatory hook rather than SA. E Precedent Maturity P X agent · override Override of the questionnaire's X (and of its 'Unknown' answer to the precedent question): the corpus does provide generic, documentary grounds short of org-specific confirmation, which is exactly the rubric's definition of P -- 'demonstrated in research/incident reports, not confirmed against this org's own stack' (sovereignty_cvss_rubric_1.json, threat group). For dimension 5.3 the control in question is vendor/subprocessor support and debugging access to logs, traces and prompt/output payloads. Major providers document in their own primary material that this access path is real and routinely used: Microsoft's EU Data Boundary paper states that system-generated logs 'contain personal data', that logging is 'essential' to debug operational problems, and that access is limited 'solely for purposes related to service operations' -- i.e. provider personnel do reach this data (microsoft-eu-data-boundary.md); Google's Sovereign Controls page documents 'Sovereign Controls support' and 'Access transparency and access approval', features that exist precisely because technical-support and administrative access to customer data occurs and has to be logged and justified (google-cloud-sovereign-controls.md). That establishes the mechanism as attested and exercised in comparable enterprise SaaS/AI settings, but none of it is a documented case of Orbit's support engineers or the newly listed foundation-model subprocessor's engineers reading Brightwater's CRM-derived summaries, call notes, contract terms or pricing in logs/traces -- the scenario is explicit that Brightwater had no visibility into the feature at all and the questionnaire records precedent as 'Unknown'. E:A would overstate that; E:U would understate it, since the access clause is generic, the subprocessor was added the same day the feature shipped, and the vendor does not disclose sovereignty-relevant changes before they take effect, so debugging a brand-new feature is the single most likely occasion for such access. Confidence is held at moderate because this category is itself a low-confidence inference (no statement that humans review Orbit Insights content) and because the corpus returned no incident report specific to AI-feature support access, only vendor transparency documentation and ATLAS material about adversarial (not support) access paths. CR Confidentiality Criticality (org context) H H questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. IR Integrity Criticality (org context) M M questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. AR Availability Criticality (org context) L L questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. S Regulatory Consequence P P agent Confirmed. Support/debug access to Orbit Insights logs and traces means Orbit engineers — and now engineers of a foundation-model provider that Brightwater never contracted with and never assessed — can read content derived from CRM records containing contract terms, pricing and personal contact details for data subjects in forty countries. Microsoft's EU Data Boundary documentation establishes that system-generated logs and traces necessarily contain fields that identify or can identify specific persons (s3://.../microsoft-eu-data-boundary.md), so this is personal-data processing, not just telemetry. Processing by an undisclosed-at-the-time subprocessor without the controller's prior authorisation and without documented instructions is an independent GDPR Art. 28(2)/(3) breach for Brightwater as controller, reportable irrespective of any other failure in the chain. The rubric's own example set for S=Present names GDPR Art. 28 explicitly. AU Silent/Automatic Trigger N Y agent · override Overridden. The questionnaire's Y correctly describes the PRIMARY dependency — the silent, tenant-wide feature enablement, which the rubric flags as the extreme form of node 7.2 (UI=None, all customers at once). But this category's own loss event is a human at Orbit or at the model provider opening a trace or log to debug a ticket. That is a discrete, case-by-case act tied to a specific incident, tenant and engineer, which is precisely why the rubric assigns 5.3 the exploitability pair PR/AC rather than the AU supplemental hook it gives to 5.2 (annotation/labeling, where content flows into the pipeline automatically for everyone). Google's Sovereign Controls material describes support access as per-request and justification-bearing, reinforcing that it is an individuated action. Confidence is moderate because the underlying log-routing pipeline that makes the data reachable was itself switched on for all tenants simultaneously; if the assessor treats pipeline exposure rather than human viewing as the loss event, Y would follow. R Portability / Exit Recovery U U agent Confirmed. R measures whether the capability can be reconstituted, not whether a disclosure can be undone. The summarisation capability is a commodity foundation-model function: Brightwater could obtain equivalent next-action summarisation from another provider or an in-house deployment, but only with manual re-integration into the CRM workflow, re-embedding/re-prompting and re-contracting — the questionnaire's own answer. Nothing here is vendor-unique (no bespoke weights, no proprietary corpus), so I is not warranted; equally it is not a frictionless swap, so A is not warranted. Note separately that the confidentiality loss from an engineer having already read a trace is irreversible, but that is captured on the impact axes (VC), not here. V Blast-Radius Concentration D D agent Confirmed, with a caveat. The rubric scopes V to whether the dependency sits in the critical path for many/all AI workloads (shared control plane) versus one narrow workload. Orbit Insights is Brightwater's only AI workload in this scenario, and the debug/support path at issue is scoped to that feature's logs and traces, so D. The caveat a reviewer should weigh: the support-access clause itself derives from an eight-year global enterprise agreement over the whole CRM, so the human access channel is not AI-specific and in aggregate reaches records for forty countries. If Brightwater later adopts further Orbit AI features, this same generic support clause becomes a shared access plane and V should be revisited to C — the rubric makes an analogous 'diffuse per-event, concentrated in aggregate' note for node 3.5 telemetry logs. RE Exit / Mitigation Effort M M agent Confirmed. Two mitigations exist and together land on Moderate. The cheap one is immediate: the scenario states the feature can be disabled per tenant by an administrator, which stops new AI-feature traces being generated and shipped to the model provider — that alone is near-trivial. The durable one is a project: constraining what Orbit and its model-provider subprocessor may do with logs requires amending the DPA/support clause, obtaining access-transparency and access-approval style commitments (the control set Google documents for Sovereign Controls), and flowing them down the subprocessor chain — for which the rubric records no existing standard at 5.3 and a High gap severity. That is re-contracting and negotiation, but no re-architecture of Brightwater's own systems and no infrastructure replacement, so H overstates it. Confidence is moderate because the H band explicitly lists 're-contracting', and an assessor who weights the contractual remedy over the admin toggle could justifiably choose H. U Vendor Notice Posture Amber Red agent · override Overridden. Red requires that the vendor never discloses sovereignty-relevant changes before they take effect in any form; the scenario shows disclosure occurring, just with zero lead time: the updated subprocessor 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'. That is the textbook definition of Amber — disclosure concurrent with the change taking effect. The practical effect on Brightwater was the same as no notice (its governance gate never fired and it learned of the feature from a sales manager's question), but the metric asks about posture, not outcome. Reviewer caveat specific to 5.3: Orbit is not shown to notify per-access events at all — there is no evidence of an Access Transparency/Access Approval equivalent of the kind Google documents — so notice of individual support-engineer data access is effectively absent; U as defined in this rubric covers change notification (model versions, subprocessors, hosting, terms), which is Amber. - HIGH7.9
6 Who's holding the steering wheel?
6.4 Configuration and policy management · also 6.1The event that caused all of this was a settings decision Brightwater did not make: Orbit shipped the feature switched on for every user in its tenant, in a routine quarterly release, with notice only at the moment it went live. The only control available to Brightwater is an administrator switch to turn the feature off, and Brightwater did not know that switch mattered until a sales manager asked why summaries were appearing. Brightwater's mandatory pre-adoption AI review never ran, because from Brightwater's side nothing was adopted. Orbit's terms let it make the same kind of change again, to this and every other customer at once, at any time.
Rating HIGH. Brightwater cannot hold its own configuration and policy position against this vendor — the vendor can change what Brightwater's systems do, for everyone, without asking.
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:N/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?
Metric Value Prior Source Rationale AV Access Path N N agent Confirms the prior. The configuration and policy surface at issue — Orbit's tenant feature flags, release pipeline and subprocessor routing — resides entirely in Orbit's own multi-tenant SaaS cloud, which Brightwater reaches only over Orbit's API and web admin console. Orbit itself reaches and mutates that configuration directly, with no intermediary standing between it and the setting (rubric AV N: 'Network -- vendor-direct API access, no intermediary'). Nothing in this dimension is resident in a Brightwater-managed environment (ruling out L) and there is no air-gap or customer-held administrative gate on the change (ruling out P). Although a subprocessor sits downstream of the feature, the configuration change path itself is not subprocessor-mediated, so A is inapt. ATLAS AML.T0006.001 corroborates that SaaS provider control-planes expose tenant configuration directly to the platform operator. AC Compulsion Complexity L L agent Confirms the prior. The scenario states plainly that 'Orbit's terms allow feature changes at its discretion with notice at the time of release.' The standard enterprise ToS is therefore itself the enabling instrument — Orbit had to overcome nothing to change Brightwater's effective configuration and add a new subprocessor to the processing path. There are no customer-managed keys, no data-residency carve-outs, and no change-approval or pre-notification clause in the eight-year global agreement that would have functioned as a barrier; the interagency third-party risk guidance treats precisely such notice/termination provisions as the contractual controls that must be negotiated in, and they are absent here. That is rubric AC L: 'a standard ToS clause or routine legal process suffices.' AT Trigger Conditions N P agent · override OVERRIDE of the questionnaire prior (P). The questionnaire's own answer lists 'product decision' alongside sanctions designation, litigation hold and security incident, but under the rubric's definitions a product decision is not a triggering event — it is the paradigm case of vendor discretion. Rubric AT P requires 'a specific triggering event (sanctions designation, litigation hold, incident)'; AT N is 'control can be exercised at vendor discretion at any time.' Here the configuration change arrived in a 'routine quarterly release', under terms that 'allow feature changes at its discretion', with no external condition precedent of any kind. The questionnaire further confirms the event 'could happen to all of the vendor's customers at once, with no case-by-case decision', which is incompatible with a per-customer trigger. For dimension 6.4 specifically, Orbit can flip, re-default or re-route tenant configuration in any release cycle; no event need occur first. AT = N. PR Position Required L N agent · override OVERRIDE of the questionnaire prior (N). The prior ('any party already in the subprocessor chain has sufficient standing') is correct for the Category 7 data-exposure headline, but this dimension asks who can change the configuration. Only the operator of the control plane — Orbit, the primary contracted vendor — can ship a release that sets Orbit Insights on-by-default for every tenant and expose the per-tenant disable toggle. The downstream foundation-model provider, though it receives the data, has no standing to alter Orbit's feature, routing or policy settings; it consumes the configuration rather than sets it. That is rubric PR L: 'requires being the primary contracted vendor.' H is wrong because Orbit needed no Brightwater administrative credentials — indeed Brightwater's administrators were unaware the toggle existed. PR is one of the two primary exploitability metrics the rubric assigns to 6.4, so the distinction is load-bearing; ATLAS AML.T0081 (the corpus's named anchor for 6.4) likewise frames the actor as whoever holds write access to the shared configuration. UI Org Action Required N N agent Confirms the prior, and this is the decisive metric for 6.4. The rubric's UI N definition names this exact fact pattern: 'vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature).' Brightwater took no action whatsoever — the feature 'was on by default for all users', the subprocessor list was updated 'the same day the release shipped', and the AI governance review 'never triggered because no one in the organisation adopted anything'. The exposure was complete at release, before any user touched a summary, so P (routine use triggers it) understates the mechanism, and A is plainly excluded since there was no opt-in to accept. Discovery came only reactively, when a sales manager asked why summaries were appearing. ATLAS AML.T0081 describes the same property: a configuration change 'affects any agents that share the configuration' without per-user action. VC Primary Dependency Impact -- Confidentiality N N agent Confirmed. The asset under assessment in 6.4 is the tenant configuration and policy surface (feature flags, routing and subprocessor-affecting settings) in Orbit's admin console. Nothing confidential about that surface was disclosed: the settings themselves are not sensitive, and no party gained visibility into Brightwater's configuration that it did not already have as the platform operator. The real confidentiality loss — CRM contract terms, pricing and personal contact data for customers in forty countries becoming readable by a foundation-model provider Brightwater never contracted with — occurs beyond this dependency and is captured in the subsequent-impact group (questionnaire: 'Beyond this dependency ... Full: sensitive data becomes readable by a party we never contracted with'). The rubric lists no VC axis for 6.4. VI Primary Dependency Impact -- Integrity H N agent · override Override from N to H. The decisive event in this scenario is a configuration change Brightwater neither made nor authorised: Orbit enabled Orbit Insights on-by-default for every user in the tenant, changing which data is processed and to which third-party model provider it is routed, with notice only at the moment of release and no pre-change signal in the admin console. Brightwater's configuration state therefore no longer expressed its own policy, and the integrity of its governance control was total rather than partial: the AI-adoption review gate 'never triggered because no one adopted anything', and the altered state went undetected until a sales manager asked about the summaries. Orbit's terms permit feature changes at its discretion, so there is no bound on how much of the policy surface can be rewritten unilaterally, and the questionnaire confirms the change can be made with no action by Brightwater ('the vendor or subprocessor can act unilaterally') and simultaneously for all customers ('Could the loss event happen to all of the vendor's customers at once ... Yes'). This is exactly the harm pattern ATLAS AML.T0081 — the corpus technique anchored to CASE 6.4 — describes: configuration modified so that data is redirected to additional services and human-oversight/approval controls are bypassed, persisting across everything sharing the configuration, with change approval and configuration integrity monitoring named as the missing mitigations. Treating it as a substantial in-place modification of an already-deployed system is consistent with EU AI Act Art. 25 reasoning. Rated H rather than L because the loss is of the organisation's entire ability to hold a configuration state against the vendor, it was silent, and it is reportable on its own (questionnaire: regulatory violation = Yes). Note this overrides the questionnaire's 'behaviour or outputs altered: None' answer, which was given about the primary CRM dependency's outputs, not about the configuration and policy layer assessed here. VA Primary Dependency Impact -- Availability N N agent Confirmed. No capability at the configuration/control-plane layer was withdrawn or degraded: the per-tenant administrator toggle existed and remained usable, so once Brightwater became aware it could disable the feature itself, and the CRM and its admin console continued to operate throughout (questionnaire: 'None: we could keep operating this component'). The failure was that Brightwater did not know the control existed and could not act before the change took effect — an integrity/notice failure captured in VI and in the vendor-notice metric, not a loss of availability. The rubric assigns no availability axis to 6.4; availability concerns in the Control Plane category sit with 6.1/6.3 (console or gateway outage) and are not what happened here. SC Downstream Blast-Radius Impact -- Confidentiality H H agent CONFIRMED. The configuration state itself holds no sensitive data, but flipping it is precisely what moved the data: because Orbit Insights shipped on-by-default tenant-wide, CRM content — contract terms, pricing and personal contact details for customers in forty countries — began flowing to a third-party foundation-model provider that appeared on the subprocessor list only on release day, a party Brightwater never contracted with, assessed or knew about. The rubric defines dimension 6.4 as subsequent-impact-relevant and describes the SC/SI/SA group as built to express exactly this compounding, multi-hop propagation beyond the named vendor; ATLAS AML.T0081, the corpus's named anchor for 6.4, likewise notes that a configuration change 'affects any agents that share the configuration' and can redirect outputs to unintended services. The questionnaire's own answer ('Full: sensitive data becomes readable by a party we never contracted with') matches the H definition of total or near-total loss on this axis, and the breadth (all users, all records, 40 jurisdictions, no case-by-case decision) leaves no basis for a partial rating. SI Downstream Blast-Radius Impact -- Integrity H H agent CONFIRMED, with the counter-argument noted. The rubric gives 6.4 VI as its primary impact axis, and the downstream expression of that is the integrity of what the altered policy state produces. Three facts drive H: (1) the summaries and 'suggested next actions' are written into the CRM — the commercial system of record for forty countries — and acted on by sales staff who had no idea an AI produced them, with no provenance marking; EU AI Act recital 133 treats unmarked synthetic content that is indistinguishable from human-authored content as a material harm to 'the integrity and trust in the information ecosystem', and Art. 14(4)(b) names automation bias as the specific failure mode when staff over-rely on recommendations. (2) Brightwater's AI governance review never triggered, so no accuracy validation, human-oversight measure or output monitoring was ever applied — there is no detection point at which altered or wrong outputs would surface. (3) Orbit's terms permit feature and model changes at its discretion with notice only at release and no pre-change disclosure, so the generating model or subprocessor can be substituted silently, meaning the integrity of the output stream is not under Brightwater's control at all. That matches the questionnaire's 'downstream systems act on altered outputs without detection'. Confidence is moderated because the underlying authoritative records (original email threads, call notes, contract and pricing fields) are not overwritten by the feature and remain verifiable against source, and the retrieved EU AI Act recital on systems that add 'only an additional layer to a human activity' would argue for L; a reviewer preferring that reading should substitute L. SA Downstream Blast-Radius Impact -- Availability L L agent CONFIRMED as L. Availability loss downstream of the configuration surface is real but partial in both directions: Orbit can withdraw or degrade the feature unilaterally at any time, and conversely Brightwater's only remediation — the per-tenant administrator toggle — itself removes a capability that sales users across forty countries have already begun relying on. Either way the CRM and the underlying customer records keep working; the questionnaire records 'None: we could keep operating this component' at the dependency and only 'some downstream workloads degrade' beyond it, and the dependency supports one narrow workload that is reconstitutable with manual migration effort. That is limited loss, not total, so L rather than H, and not N because the degradation is genuine. S is not applicable: this is consumer-brands CRM summarisation with no actuation path to physical processes, so no availability loss here could cause physical harm or a safety-relevant failure. Note the regulatory consequence (the questionnaire reports a reportable violation) belongs to the supplemental S metric in the rubric, not to SA. E Precedent Maturity A X agent · override Override of the questionnaire prior (X / 'Unknown'). The rubric defines E:A as documented real-world cases of this control being exercised against comparable orgs, and E:P as merely demonstrated in research or incident reports and 'not confirmed against this org's own stack' (sovereignty_cvss_rubric_1.json, threat.E). For dimension 6.4 the control in question is the vendor's ability to change feature/routing/policy configuration unilaterally — and in this scenario it was not hypothetical: Orbit shipped Orbit Insights on-by-default to every tenant in a routine quarterly release, the change took effect in Brightwater's own tenant (summaries were visibly appearing to a sales manager before anyone knew the feature existed), and the per-tenant disable toggle was the only after-the-fact remedy. The exercise is therefore confirmed against this organisation's own stack and, because the rollout was fleet-wide with no case-by-case decision (questionnaire: 'Could the loss event happen to all of the vendor's customers at once... Yes'), simultaneously against all comparable Orbit customers. The CASE/ATLAS mapping note states 'Realized / Incident → E:A' (atlas/README.md), which is the correct bucket for an already-realized configuration change. Caveat lowering confidence: the ATLAS technique the taxonomy anchors to 6.4, AML.T0081 'Modify AI Agent Configuration', is itself rated Demonstrated → E:P, i.e. the adversarial variant of unauthorised configuration change is only proof-of-concept; the E:A rating here rests on the legitimate-vendor-discretion variant actually having been exercised in this case rather than on an adversarial precedent, and the questionnaire respondent did not independently know of comparable cases. CR Confidentiality Criticality (org context) H H questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. IR Integrity Criticality (org context) M M questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. AR Availability Criticality (org context) L L questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. S Regulatory Consequence P P agent Confirmed. A configuration default flipped by the processor caused personal data (contract terms, pricing, contact details) for data subjects in forty countries to be disclosed to a new foundation-model subprocessor that Brightwater, as controller, never authorised — the subprocessor list was updated the same day the release shipped, so there was no prior general or specific written authorisation and no opportunity to object (GDPR Art. 28(2)/(3)(d)), and the processor acted beyond documented controller instructions (Art. 29). Independently, the configuration change introduced an AI system that summarises and 'suggests next actions' on customer communications without the deployer's knowledge: the AI Act makes substantial modification / change of intended purpose a trigger that shifts provider obligations onto the party making the change, and imposes transparency and output-marking duties that nobody at Brightwater was in a position to discharge because nobody knew the feature existed. Brightwater's own mandatory pre-adoption AI review was bypassed, so no DPIA or Art. 26 deployer assessment exists. The regulatory violation flows from the config/policy act itself, not only from the downstream disclosure, so 'Present' is correct for this category on its own. AU Silent/Automatic Trigger Y Y agent Confirmed, and this is the clearest fact in the scenario for 6.4. The mechanism was a shipped default in a routine quarterly release: 'on by default for all users', across the whole tenant and, by construction of a SaaS release train, across Orbit's entire customer base at once. No per-tenant, per-user or per-record decision was taken; no Brightwater action was required (questionnaire: 'None: the vendor or subprocessor can act unilaterally'). The rubric's 6.4 exploitability hooks (UI, PR) describe exactly this: no user interaction and no customer-side privilege were needed to change the policy state. This is the defining property of a configuration-plane sovereignty event — one setting change propagates simultaneously to every consumer. R Portability / Exit Recovery U U agent Confirmed as 'User'. Two readings both land here. (a) Immediate recovery of the policy state is manual but available: an administrator can disable Orbit Insights per tenant — the control exists, it just has to be found and exercised by a human, and it had to be discovered by accident. (b) Recovery of the underlying capability (the CRM and the configuration surface that governs it) is not vendor-locked in the rubric's 'Irrecoverable' sense — the questionnaire confirms re-constitution is possible 'with manual migration effort (re-embedding, re-integration, re-contracting)' — but after eight years under a global enterprise agreement that migration is substantial, which rules out 'Automatic'. Not 'I', because nothing about the configuration or the records can only be reproduced by Orbit. Confidence is moderate because what cannot be reconstituted elsewhere is governance *of Orbit's own* control plane; that residual lock-in is captured by RE rather than R. V Blast-Radius Concentration C D agent · override OVERRIDE D -> C. The questionnaire's 'one narrow workload' correctly describes the primary dependency (the Insights summarisation feature). This category's asset is different: it is the tenant configuration and policy surface, and the admin console that is, per the classifier, 'the single place Brightwater can see or disable this'. The rubric makes the concentration point explicitly for the sibling control-plane dimension 6.1, whose supplemental_hook is 'V (Value Density -- Concentrated)' with the note that it 'affects every downstream AI workload the org runs', and it marks 6.4 as subsequent_impact_relevant. Empirically the surface is shared, not narrow: a single unilateral default flip reached all users, all customer records and data subjects in forty countries at once, and the same release-and-default mechanism can enable any future AI feature over the same corpus without Brightwater's involvement. ATLAS AML.T0081 likewise treats a configuration/approval-setting change as a durable, system-wide control compromise rather than a scoped one. A policy plane that gates every current and future AI behaviour over the system of record sits in the critical path and is therefore Concentrated. RE Exit / Mitigation Effort M M agent Confirmed 'Moderate'. The tactical fix is trivial (flip the per-tenant toggle), which argues for L, but RE must cover mitigating the exposure rather than suppressing one symptom: the durable fix is contractual and procedural, because Orbit's terms expressly permit feature changes at its discretion with notice only at release. Brightwater must re-negotiate change-control and sub-processor pre-notification terms with a dominant incumbent, stand up continuous monitoring of the trust-site subprocessor list and tenant config drift, extend its AI governance gate to cover features it never adopted, and retrospectively complete the DPIA/transparency work. That is a project across procurement, privacy and IT, but it needs no re-architecture, no physical infrastructure replacement and no CRM replacement — the rubric's definition of Moderate. 'H' would only apply if exiting Orbit were the sole remedy, which it is not given the administrator toggle. U Vendor Notice Posture Amber Red agent · override OVERRIDE Red -> Amber. The questionnaire answer ('does not disclose them before they take effect') is accurate but under-specifies: the scenario records that Orbit's terms provide 'notice at the time of release' and that the updated subprocessor list naming the foundation-model provider was 'published on Orbit's trust site the same day the release shipped'. Disclosure therefore occurred, but concurrently with the change taking effect, which is the rubric's definition of Amber; Red is reserved for a vendor that never discloses before the change is in force in any form. Amber is nonetheless at the pessimistic edge of its band and is the operative finding for 6.4: concurrent, passive, pull-model publication on a trust site gives an enterprise no pre-change signal and no window to object, which is precisely why Brightwater's governance gate never fired and why the feature was discovered only when a sales manager asked about the summaries. Green/Clear are excluded outright — there is no advance notice, let alone a contractual guarantee of it, since the terms reserve feature changes to Orbit's discretion. - HIGH8.2
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.1This is the central finding. Brightwater procured Orbit CRM eight years ago as a non-AI system, and an AI capability built on an unreviewed third-party model provider was added into it by the vendor, so Brightwater's AI governance gate never engaged and no review, impact assessment or data-transfer analysis was ever performed. Regulated personal, pricing and contract data for customers in forty countries became readable by a company Brightwater has no contract, data-processing agreement or transfer instrument with, and AI-generated content entered the CRM as fact. The chain beneath Orbit — the model provider and whatever infrastructure sits under it — was disclosed only by a trust-site list updated on release day and remains unreviewed. This was not a theoretical risk: it has already happened in Brightwater's own tenant, and the same change reached every Orbit customer simultaneously.
Rating HIGH. Brightwater has become an AI deployer, and arguably in breach of its data-protection obligations, without a single decision or approval on its own side.
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:H/SA:L/E:A/CR:H/IR:M/AR:L/S:P/AU:Y/R:U/V:C/RE:M/U:Amber Score 8.2 (High)
Ask the vendor List every company standing between us and the raw computer running this AI. How long is that list, really? · Did we ever affirmatively choose to adopt AI here, or did it just arrive?
Metric Value Prior Source Rationale AV Access Path A N agent · override OVERRIDE (N -> A). The questionnaire prior describes the procured product: Orbit CRM runs in Orbit's own cloud and is reached over its API, with no intermediary. But the dependency named by category 7.2 is the third-party foundation-model provider embedded inside that product. That provider reaches Brightwater's contract terms, pricing and personal contact data for forty countries only via Orbit's Insights integration -- it has no direct relationship, contract or access path to Brightwater at all. The rubric defines A as 'Adjacent -- subprocessor-mediated access', which is exactly this topology and is what distinguishes 7.2 (model provider behind a procured product) from 7.3 (infrastructure beneath the AI vendor, where AV is the carrying metric). Moderate confidence: a reviewer who scopes the exercising party as Orbit itself -- which did hold direct, unmediated access to the data when it enabled the feature -- would legitimately retain N. Note AV is not a carrying metric for this dimension (rubric: primary_exploitability = UI, AT), and this choice does not understate severity because AC, AT, PR and UI all sit at their most permissive values. AC Compulsion Complexity L L agent CONFIRM. Orbit's terms 'allow feature changes at its discretion with notice at the time of release', so a standard ToS clause was sufficient -- the rubric's definition of L. There were no technical or contractual barriers to overcome: no customer-managed encryption keys, no data-residency carve-out, no per-tenant opt-in gate stood between the CRM record store and the new subprocessor. The fact that an administrator can disable Insights per tenant is a post-hoc remediation available only once the org discovers the feature (Brightwater found out when a sales manager asked about the summaries); it is not a precondition the vendor had to defeat, so it does not raise complexity to H. AT Trigger Conditions N P agent · override OVERRIDE (P -> N). The questionnaire selected 'only upon a specific event', but the enumerated options were 'sanctions designation, litigation hold, security incident, product decision' -- and the event that actually occurred was the last of these. A product decision is not an external triggering condition; it is precisely the exercise of vendor discretion that the rubric's N value describes ('control can be exercised at vendor discretion at any time'). The scenario is unambiguous: the exposure arrived in a 'routine quarterly release' under terms permitting feature changes at Orbit's discretion, and the new subprocessor was listed on the trust site the same day the release shipped. No sanctions action, litigation or incident was required. AT is one of the two carrying metrics the rubric assigns to 7.2, so this correction is material to the dimension's severity. PR Position Required N N agent CONFIRM. The party that gained readable access to regulated personal, pricing and contract data -- the foundation-model provider -- needed no standing beyond appearing on Orbit's subprocessor list. It is not the primary contracted vendor (that is Orbit, so L does not fit the beneficiary of the access) and it did not need to compromise any Brightwater administrative credential (ruling out H). This matches the rubric's N: 'any party already in the subprocessor chain has sufficient standing'. Secondary 7.1 reinforces the point -- the chain beneath Orbit was disclosed only by a same-day trust-site update, so chain membership was conferred unilaterally and was never reviewed by Brightwater. UI Org Action Required N N agent CONFIRM, and this is the metric that defines the dimension. Orbit acted wholly unilaterally: Insights was enabled by default for all users in a routine release, and Brightwater's AI governance process -- which mandates review before any AI service is adopted -- never triggered because nobody adopted anything. The org took no affirmative step (ruling out A) and the exposure did not merely follow from ordinary use (ruling out P): the data flow to the new subprocessor was established by the vendor's act of switching the feature on, before any user touched a summary. The rubric lists 'silently added AI feature' as a worked example of N and notes that in 7.2 'the org's own governance never touches the primary system at all' -- UI=None in its most extreme form. This is why the full confidentiality and integrity loss is Subsequent relative to what Brightwater believed it had procured. VC Primary Dependency Impact -- Confidentiality N N agent Confirmed. The rubric's own entry for 7.2 sets primary_impact_axis to the empty list and subsequent_impact_relevant=true, with the explicit note that in this dimension 'the org's own governance never touches the primary system at all, so every impact is Subsequent relative to what the org believes it procured' (sovereignty_cvss_rubric_1.json). Brightwater procured Orbit CRM as a non-AI SaaS platform eight years ago under a global enterprise agreement; at that named dependency itself nothing new is disclosed — the loss of confidentiality arises because CRM content (contract terms, pricing, personal contact details for 40 countries) is now routed to an uncontracted third-party foundation-model provider, which is a party beyond the primary dependency and therefore scored under SC. The questionnaire mirrors this: 'None: no sensitive data is exposed here' at the dependency, versus 'Full: sensitive data becomes readable by a party we never contracted with' beyond it. Assigning H here would double-count the same loss already captured as subsequent impact. VI Primary Dependency Impact -- Integrity N N agent Confirmed. The integrity failure in this scenario is that AI-generated summaries and 'suggested next actions' of unreviewed provenance are injected into sales workflows and acted upon — i.e. downstream decisions are altered without detection (questionnaire: 'Full: downstream systems act on altered outputs without detection'). The CRM records themselves are not rewritten or corrupted by the feature, and the questionnaire reports no alteration of the dependency's own behaviour or outputs. Consistent with the rubric's 7.2 entry (primary_impact_axis empty, subsequent impact relevant), the integrity loss belongs to SI, not VI. VA Primary Dependency Impact -- Availability N N agent Confirmed. Orbit Insights can be switched off per tenant by an administrator and the underlying CRM continues to function regardless; the questionnaire states 'None: we could keep operating this component', and exit is characterised as a moderate manual migration project rather than a service loss. Only 'some downstream workloads degrade', which is an SA (subsequent) consideration. Nothing in the scenario indicates withdrawal or degradation of the procured CRM capability itself, so no availability loss at the primary dependency. SC Downstream Blast-Radius Impact -- Confidentiality H H agent Confirmed. The primary dependency itself was answered "no sensitive data exposed here" (VC=N), so the entire confidentiality loss lands downstream, exactly as the rubric predicts for 7.2 ("every impact is Subsequent relative to what the org believes it procured"). What propagates is not a sample but the substance of the CRM: customer email threads and call notes, plus records containing contract terms, pricing and personal contact details for customers in forty countries, now readable by a foundation-model provider that appeared on Orbit's trust site only on the day the release shipped and with which Brightwater has no contract, no DPA and no transfer instrument. The questionnaire states the downstream confidentiality loss is "Full: sensitive data becomes readable by a party we never contracted with," that it alone triggers a reportable regulatory violation, and that it can occur "to all of the vendor's customers at once, with no case-by-case decision." The EU AI Act value-chain provisions presuppose a written agreement granting the integrating party the necessary information and technical access; Brightwater has none, so it cannot bound, audit or retrieve what was disclosed. Total loss on this axis: H. SI Downstream Blast-Radius Impact -- Integrity H H agent Confirmed, with the counterargument noted. VI was answered "None" at the dependency, so again the integrity loss is wholly subsequent. Model-generated summaries and suggested next actions are written into the CRM — the organisation's record of truth about customer relationships — and were consumed by sales staff before Brightwater knew the feature existed (discovered only when a manager asked why summaries were appearing). Orbit's terms permit feature changes at its discretion with notice only at the time of release, and the questionnaire confirms the vendor "does not disclose [sovereignty-relevant changes] before they take effect," so the underlying model can be swapped, re-tuned or re-prompted silently. With no AI governance review ever performed, no pre-change notification and no provenance marking, there is no detection path: Brightwater cannot assure the integrity of any AI-derived content or recommendation in its CRM for forty countries — matching the questionnaire's "Full: downstream systems act on altered outputs without detection." The counterweight considered is the EU AI Act's narrow-procedural-task/assistive-editing framing (recital 53 and the Art. 50 carve-out for systems that "do not substantially alter the input data ... or the semantics thereof"): summarisation is advisory and the authoritative contract and pricing fields are not themselves rewritten by the model. Because the feature goes beyond summarisation to "suggests next actions" — i.e. it materially influences commercial decision-making — and because undetectability is total, H is retained rather than L, but confidence is moderate. SA Downstream Blast-Radius Impact -- Availability L L agent Confirmed as Low, and explicitly not S. Availability is the weakest axis of this dimension: the questionnaire reports VA=None ("we could keep operating this component"), only "some downstream workloads degrade" beyond it, a single narrow workload depends on the component, and the capability is reconstitutable "with manual migration effort" through a moderate project with no re-architecture. Withdrawal or degradation of Orbit Insights — whether by Orbit's product decision, the model provider, or Brightwater's own per-tenant disable switch — would remove summaries and next-action suggestions but would not stop the eight-year-old CRM itself, which is the system of record. That is partial, not total, loss: L. Safety (S) is excluded because the affected workload is consumer-brands sales and customer-relationship administration; no physical process, safety function or life-critical decision depends on the summaries, so no availability loss here could cause physical harm. E Precedent Maturity A X agent · override Override of the X prior (and of the questionnaire's 'Unknown' answer to the precedent question). The CASE E scale asks whether this control has actually been exercised; in this scenario it already has been, against Brightwater itself and, per the questionnaire ('Could the loss event happen to all of the vendor's customers at once, with no case-by-case decision? Yes'), against every Orbit tenant simultaneously. Orbit shipped Orbit Insights in a routine quarterly release, on by default for all users, with the new foundation-model subprocessor published on the trust site the same day and notice only at release time under terms that permit feature changes at Orbit's discretion. That is an exercised, not theoretical, vendor-side control: regulated contract, pricing and personal data for 40 countries is already being sent to an uncontracted model provider, discovered only when a sales manager noticed the summaries. E:P ('demonstrated in research/incident reports, not confirmed against this org's own stack') understates it because it is confirmed on this org's own stack; E:U is excluded outright. The closest corpus anchor supports the same direction: ATLAS AML.T0047 'AI-Enabled Product or Service' — indirect access to an underlying model through a product that uses AI under the hood — carries maturity 'Realized', which the ATLAS-to-CASE mapping converts to Precedent Maturity E:A. Caveat lowering confidence: the corpus returned no sovereignty-framed case study of silent AI feature addition in procured SaaS specifically (the rubric itself records 7.2 as gap_severity High with 'None identified -- highest-yield gap'), so the E:A judgement rests on the realized event in the scenario plus the ATLAS Realized-maturity analogue rather than on a catalogued comparable-org case. CR Confidentiality Criticality (org context) H H questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. IR Integrity Criticality (org context) M M questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. AR Availability Criticality (org context) L L questionnaire Organization-profile answer (ADR-0005 §5 rule 1); never agent-assigned. S Regulatory Consequence P P agent CONFIRM. Orbit routed contract terms, pricing and personal contact details for customers in forty countries to a foundation-model provider that appeared on the subprocessor list the day the release shipped. For Brightwater as controller this is an undisclosed, unauthorised sub-processor engagement (GDPR Art. 28(2)/(3)(h) — no prior authorisation, no objection window, no flow-down DPA), with no Art. 35 DPIA and no Art. 30 record covering the new processing; EU AI Act transparency/deployer duties (Art. 50, Art. 26) likewise could not be met because Brightwater did not know it had become a deployer. The compromise therefore independently triggers a reportable regulatory violation irrespective of any further harm, which is exactly the P condition. AU Silent/Automatic Trigger Y Y agent CONFIRM. Orbit Insights arrived in a routine quarterly release, on by default for all users, with no tenant opt-in and no per-customer decision; the same release shipped to the whole Orbit customer base simultaneously. The rubric's own note for 7.2 describes precisely this (org action required = None in its most extreme form, simultaneous exposure across all tenants), and ATLAS AML.T0047 records the general pattern of model access acquired through a procured product rather than a deliberate adoption. Y. R Portability / Exit Recovery U U agent CONFIRM. The capability at risk is the CRM system of record itself (eight years of data under a global enterprise agreement), not the summarisation feature, which Brightwater never wanted and an administrator can disable per tenant. Competing CRM platforms exist, so the capability is not irrecoverable without Orbit, but reconstituting it means data export, re-integration of surrounding systems, re-contracting and migration across forty countries — the transition-planning factors the interagency guidance enumerates (alternate providers, capabilities/resources/time frame, data retention and destruction, termination costs). That is manual migration effort: U, not A and not I. V Blast-Radius Concentration C D agent · override OVERRIDE (D -> C). The questionnaire's 'one narrow workload' counts AI workloads, and by that count Insights is one feature. But the rubric defines V as Blast-Radius Concentration — whether the dependency sits in the critical path of the org's estate (shared control plane) — and the dependency here is Orbit CRM, Brightwater's single global system of record. Insights was enabled for all users and reads the whole corpus of email threads, call notes, contract terms, pricing and personal data for forty countries, so the uncontracted model provider's reach is the entire customer data estate, not a scoped workload. The same vendor control plane can attach any future model provider to the same records at its discretion. That is a concentrated, value-rich dependency; D would understate the blast radius the 7.2 classifier rationale describes. Confidence is moderate because the literal wording of D ('one narrow workload') can be read as supporting the prior. RE Exit / Mitigation Effort M M agent CONFIRM. Immediate suppression is cheap (an admin can disable the feature per tenant), so RE is not H — nothing requires re-architecture or infrastructure replacement. But a durable fix is a project rather than a trivial switch: due diligence on a foundation-model provider Brightwater never reviewed, retrospective DPIA and breach-notification assessment across forty jurisdictions, and re-contracting the eight-year enterprise agreement to add the subprocessor-notification, consent, prohibition and termination rights the interagency guidance recommends for exactly this failure mode. Moderate. U Vendor Notice Posture Amber Red agent · override OVERRIDE (Red -> Amber). The questionnaire answer ('does not disclose before they take effect') is true but does not discriminate between the rubric's Red and Amber: Red is reserved for a vendor that never discloses sovereignty-relevant changes, whereas Amber is disclosure concurrent with the change taking effect. Orbit did disclose — its terms permit 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 was therefore concurrent, matching Amber exactly. The practical effect was close to Red (pull-based trust-site publication with zero advance notice; Brightwater learned of it from a sales manager, not from Orbit), and the remediation implication is the same as the interagency guidance's subcontractor-notification clause, but the rubric's definitions place this at Amber.
What Brightwater Consumer Brands should do next
Written by the narrative agent from the findings and mitigations
- Brightwater should decide immediately whether to disable Orbit Insights at the tenant level while the position is assessed, and record that decision and its date as evidence of prompt action.
- Brightwater should notify its privacy and legal functions now and assess reportability, given that regulated personal data for forty countries reached an undisclosed processor without prior authorisation, a documented transfer basis, a record of the processing activity or a data-protection impact assessment.
- Brightwater should demand in writing from Orbit the identity and hosting jurisdiction of the foundation-model provider, the retention and human-review practices for all inputs and generated summaries, whether support staff can read this content, and the full subprocessor chain beneath the feature.
- Brightwater should establish what content has already been sent and what AI-generated summaries and suggested actions now sit in its CRM, mark that content so staff can tell it apart from human-authored records, and require human verification before it is relied on for customer-facing or contractual decisions.
- Brightwater should renegotiate the Orbit enterprise agreement to require advance notice and a right to object before any new AI feature, model provider, subprocessor or hosting change takes effect, with new AI capabilities defaulting to off, plus data-residency and support-access commitments and a flow-down data-processing agreement.
- Brightwater should require that inputs and outputs be screened for personal data, pricing and contract terms before they leave its tenant and before generated content is written back into the CRM, and that this screening sits outside the vendor's AI pipeline where Brightwater can evidence it.
- Brightwater should insist on access to logs showing what data the feature read, what it produced, which model version served each request and which personnel accessed that content, so that future changes are detectable rather than discovered by accident.
- Brightwater should extend its AI governance process so it is triggered by vendor-side change — a standing review of subprocessor and trust-site notices across all major SaaS contracts — rather than only by an internal adoption decision, and then re-run that review across its other long-standing SaaS platforms for the same silent-feature exposure.
Ranked mitigations
Retrieved from the mitigation library for the adverse metrics
10
| Relevance | Mitigation | Targets |
|---|---|---|
| 0.94 | ATLAS AML.M0020 — Generative AI Guardrails: apply layered guardrails at input handling, prompt construction, retrieval, tool execution, model output review and post-deployment monitoring. Specific implementations: input moderation (prompt injection/jailbreak/sensitive-data screening); output moderation (scan responses for harmful content, PII, secrets, policy violations, unsupported claims, unsafe code via scanners, classifiers or a reviewer model); system prompt and policy enforcement; tool and action guardrails that validate tool calls, arguments, permissions and tool outputs before execution or before results return to the model; human approval for high-impact, irreversible, privileged or externally visible actions; retrieval guardrails filtering untrusted/malicious retrieved documents; 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); structured output validation enforcing schemas, type checks, allowed values and safe formats before outputs are consumed by downstream systems. Guardrails must be continuously evaluated, red-teamed and updated; decisions logged.The single most directly applicable control for 3.3 Model outputs: output moderation, secret/PII redaction and schema validation before downstream consumption simultaneously cut confidentiality leakage through completions and the integrity blast radius of unvalidated outputs flowing into dependent systems. | VCVISCSIACATAU |
| 0.91 | ATLAS AML.M0033 — Input and Output Validation for AI Agent Components: implement validation on inputs and outputs for the tools and data sources used by AI agents, including enforcing a common data format, schema validation, checks for sensitive or prohibited information leakage, and data sanitization to remove potential injections or unsafe code. Validation should be performed external to the AI agent. Input and output validation helps prevent compromises from spreading in AI-enabled systems and secures the workflow when multiple components are chained together. Mitigates LLM prompt injection (direct, indirect, triggered), AI agent tool invocation abuse, and exfiltration via agent tool invocation.Validation enforced external to the agent is the primary structural brake on cross-component propagation in the 4.2 orchestration layer, directly reducing downstream integrity and confidentiality blast radius and raising the complexity of compelled or injected behaviour. | VISISCACV |
| 0.90 | ATLAS AML.M0029 — Human In-the-Loop for AI Agent Actions: require the user or another human stakeholder to approve AI agent actions before the agent takes them. The human approver may be technical staff or business-unit SMEs depending on the use case. Separate tools such as dedicated audit agents may assist, but final adjudication should be conducted by a human decision-maker. Human-in-the-loop policies should scale with the degree of consequence of the task: minor repetitive tasks with basic tools may need minimal oversight, while high-consequence systems may require approval from multiple stakeholders diversified across multiple organizations. Requiring user confirmation of agent tool invocations prevents automatic execution of tools by an adversary, including exfiltration and data destruction via tool invocation.Consequence-scaled human approval directly attacks the Silent/Automatic Trigger and no-Org-Action-Required conditions by inserting a mandatory human decision point before high-impact agent actions can execute. | AUUIACSISCS |
| 0.87 | ATLAS AML.M0030 — Restrict AI Agent Tool Invocation on Untrusted Data: untrusted data can contain prompt injections that invoke an AI agent's tools, causing confidentiality, integrity or availability violations. Restrict or limit tool invocation when untrusted data enters the LLM's context. The degree of restriction may depend on the potential consequences of the action. Consider blocking the automatic invocation of tools, or requiring user confirmation, once untrusted data enters the LLM's context; for high-consequence actions, consider always requiring user confirmation.Blocking automatic tool invocation once untrusted content enters context closes the low-complexity, network-reachable, no-precondition trigger path that drives the AV/AC/AT/AU profile of the orchestration dimension. | AVACATAUVISI |
| 0.85 | ATLAS AML.M0024 — AI Telemetry Logging: implement logging of inputs and outputs of deployed AI models. When deploying AI agents, log the intermediate steps of agentic actions and decisions, data access and tool use, installation commands, and the identity of the agent. Monitoring logs helps detect security threats and mitigate impacts, and enabled logging discourages adversaries who want to remain undetected. Telemetry logging helps identify whether sensitive data has been exfiltrated via inference APIs, audit API usage of the model, identify whether sensitive model information has been sent to an attacker via an AI-enabled product or service, detect unsafe prompts, log agent tool invocations to detect malicious calls, log requests to AI services and RAG databases, and detect AI service web-interface and URL-fetch activity used to relay data.Logging model I/O, agent intermediate steps and requests to AI services is the detection capability that converts silent/automatic provider and agent behaviour into observable, auditable events and supplies the evidentiary record needed for regulatory consequence. | AUVCSCSIES |
| 0.83 | ATLAS AML.M0037 — Authority Expansion Controls: treat newly discovered targets, resources, authorities, identities, execution environments, tools, communication paths and trust relationships as outside the authorized boundary unless explicitly approved. Propagate a parent agent's authority constraints to any sub-agents so orchestration cannot create or direct executors with broader targets, permissions or permitted actions than the originating agent. Attempted changes in scope should be accompanied by Human In-the-Loop for AI Agent Actions (AML.M0029). Log new resource discovery, denials, exceptions, approvals and scope changes using AI Telemetry Logging (AML.M0024).Constraining authority expansion and forcing sub-agents to inherit parent constraints caps how far a low-privilege foothold in the orchestration framework can reach, directly reducing Position Required leverage and blast-radius concentration. | PRAUSCSIV |
| 0.79 | ATLAS AML.M0038 — AI Agent Scope Drift Detection: continuously evaluate whether an agent's planned actions remain consistent with its current authorized objective throughout execution. Implementation may use runtime policy engines, planning monitors, orchestration frameworks or supervisory agents. Indicators to monitor include significant changes in planned objectives or task hierarchy, generation of new long-term goals unrelated to the assigned objective, tool usage inconsistent with the original mission, attempts to access systems or resources outside authorized scope, repeated adaptation toward objectives requiring progressively broader authority, and planning sequences that introduce persistence, privilege escalation or unrelated lateral movement. When scope drift is detected, pause execution, restrict tool access, require external approval, return the agent to a known authorized plan, or terminate the task.Runtime drift detection with pause/terminate responses is the detective counterpart to authority controls in 4.2 and 6.4, catching silent deviations in agent behaviour and policy configuration before they propagate downstream. | VISIAUVPR |
| 0.76 | ATLAS AML.M0023 — AI Bill of Materials: maintain an AI BOM recording the components of AI systems, including dataset provenance, i.e. a detailed history of datasets used for AI applications covering the dataset source and a complete record of any modifications. An AI BOM helps users identify untrustworthy components of their AI supply chain, untrustworthy binaries, untrustworthy model artifacts and untrustworthy software dependencies, mitigating AI supply chain compromise and user execution of unsafe AI artifacts or malicious packages.An enforced AI BOM over procured products is the closest retrieved control to detecting silent AI feature additions and embedded third-party model providers in dimension 7.2, since it makes undeclared components and model substitutions visible rather than automatic. | AUEVSVC |
| 0.72 | ATLAS AML.M0008 — Validate AI Model: validate that AI models perform as intended by testing for backdoor triggers, potential for data leakage, or adversarial influence. Monitor the AI model for concept drift and training data drift, which may indicate data tampering and poisoning. Ensures acquired models do not respond to potential backdoor triggers or adversarial influence, increases confidence that a model has not been manipulated or poisoned, and robust evaluation can detect privacy concerns, data leakage and potential for revealing sensitive information (AML.T0057 LLM Data Leakage).Acceptance validation and drift monitoring of acquired or vendor-updated models gives an organization its own evidence of output integrity and leakage behaviour when a provider silently changes the model behind a procured product. | VIVCSIE |
| 0.70 | ATLAS AML.M0028 — AI Agent Tool Access Controls (with AML.M0026/AML.M0027): configure AI agent tools with access controls inherited from the user or the agent invoking the tool, implemented either in the MCP servers connecting agents to tools or directly in the tool configuration files. Apply least privilege and delegated access so an agent acting for a user is never granted permissions the user would not hold; manage agent identity, access protocols and decommissioning across its lifecycle. These controls limit an adversary's ability to abuse tool invocations, access sensitive data from AI services and RAG databases, exfiltrate data via tool invocation, and destroy data via tool invocation if the agent is compromised.Inherited least-privilege tool permissions configured at the MCP/tool-config layer bound what a compromised orchestration component can read or alter, lowering the confidentiality and integrity blast radius and the value of a low-privilege position. | PRVCSCSIV |
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
- 314a6973-a395-4aeb-bfd7-a021f77b86f2