Assessment run

dev · us-east-1
Runs / d5716ec8-1c99-4dec-b609-ad5abb24cd02Live assessmentCompleted 2026-10-28 23:43 UTC

Agentic procurement assistant logs ERP tool calls at the vendor

Organization
Northwind Consumer Goods
Vendor / dependency
Nimbus Agents (enterprise AI agent platform)
Industry
Fortune 500 enterprise
Run time
64 min 47 s · 38 agent calls
Headline · class 2
7.3HIGH
SOV:1.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:L/VA:N/SC:H/SI:H/SA:L/E:A/CR:H/IR:H/AR:M/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

ClassCarried byScoreRatingLoad-bearing metrics
1 Whose AI brain is this, really?1.3 Model update / versioning control7.1HIGHAVACATUIVISISAUV
2 What are we feeding it? ◆2.4 Tool-call parameters and results (agentic-specific)7.3HIGHAVACATVCSCSIESAUV
3 What does it create from our data: and where does THAT go?3.6 Cached / derived artifacts5.7MEDIUMAVACATVCSAURVRE
4 Who's deciding what the AI sees and does?4.3 Tool/plugin execution environment7.3HIGHAVACATVCSCSIEAUV
5 Which humans are actually looking at our stuff?5.3 Support / debugging access5.3MEDIUMAVACATVCEV
6 Who's holding the steering wheel?6.1 Centralized control plane / admin console8.3HIGHAVACATUISCSIEAUVRE
7 How many companies are really in this chain: and did we agree to it?7.1 Downstream subprocessors5.8MEDIUMACATSCSAUV

Findings

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

  1. 1 Whose AI brain is this, really?

    1.3 Model update / versioning control · also 1.2
    HIGH7.1

    Northwind Consumer Goods does not host, hold or test the AI model behind its procurement assistant: the whole runtime sits inside Nimbus's cloud and is reached over Nimbus's interface. Nimbus can change how that platform behaves — including what it records and how long it keeps it — under its standard terms, and it tells customers by publishing release notes at the moment the change takes effect. Northwind therefore has no window in which to review, test or object to a behaviour change before its buyers and its ERP start relying on the changed behaviour, and it performs no validation of the runtime itself. Because the same platform is the standard runtime for finance and supply-chain agents too, any such change lands across all of those workloads at the same time.

    Rating HIGH. In practice this means Northwind cannot demonstrate to an auditor that it knows when the system it relies on last changed, or that anyone checked the new behaviour before business decisions were made on it.

    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:N/SC:L/SI:H/SA:L/E:P/CR:H/IR:H/AR:M/S:P/AU:Y/R:U/V:C/RE:M/U:Amber Score 7.1 (High)

    Ask the vendor Whose AI model is actually answering our questions, yours, or one you're renting from someone else? · If we stopped paying you tomorrow, could we take this AI capability somewhere else, or does it just disappear? · Can the AI's behavior change overnight without you telling us?

    MetricValuePriorSourceRationale
    AV Access PathNNagentConfirmed. Nimbus Agents is a vendor-hosted enterprise platform reached directly over its API; the model/runtime version that Northwind consumes sits entirely in the vendor's cloud with no intermediary and no customer-side artifact. This matches the rubric's AV:N 'Network -- vendor-direct API access, no intermediary'. Northwind has no weight custody, so no Local/Physical variant applies.
    AC Compulsion ComplexityLLagentConfirmed. Platform and model version changes are governed by Nimbus's standard terms and documentation: the scenario states Nimbus publishes behaviour-relevant changes (logging, retention) in release notes at the time they take effect, i.e. unilaterally under existing terms. No customer-managed keys, pinned-version commitment, residency carve-out or change-approval gate is described that the vendor would have to overcome first. Rubric AC:L = 'a standard ToS clause or routine legal process suffices'.
    AT Trigger ConditionsNNagentConfirmed, and this is one of the two exploitability metrics the rubric designates as primary for dimension 1.3. A platform/model version or behaviour change is an ordinary vendor release action requiring no triggering event (no sanctions designation, litigation hold or incident). The release-note-at-effect practice demonstrates changes land at vendor discretion on the vendor's own release cadence. Rubric AT:N = 'control can be exercised at vendor discretion at any time'.
    PR Position RequiredLLagentConfirmed. Pushing a new model/runtime version or altering platform behaviour requires standing as the primary contracted vendor operating the Nimbus control plane -- Nimbus is Northwind's standard agent runtime and the publisher of the release notes. No subprocessor is described as able to change the served version, and no compromise of Northwind's own admin credentials is needed. Rubric PR:L = 'requires being the primary contracted vendor'.
    UI Org Action RequiredNPagent · overrideOverride of the questionnaire's P. The prior reflects the primary dependency (tool-call data exposure triggered by ordinary use), but for dimension 1.3 the exposure is the change event itself, which Nimbus effects unilaterally: release notes are published 'at the time they take effect', so Northwind neither opts in nor accepts the update and cannot even review it beforehand. The rubric's UI:N value text names precisely this case -- 'vendor/subprocessor can act unilaterally (silent model swap, ToS change, silently added AI feature)' -- and the 1.3 note states every downstream consumer inherits an un-notified behaviour change. Vendor notice posture is Amber ('discloses concurrently with the change taking effect'), i.e. no pre-change org action exists to gate the exposure. Confidence is held at 0.85 rather than higher because the scenario evidences unilateral change to platform behaviour (logging/retention) rather than an explicitly stated model-version swap.
    VC Primary Dependency Impact -- ConfidentialityLHagent · overrideOVERRIDE H -> L. The questionnaire's 'full confidentiality loss' answer describes the primary dependency's log-access exposure (Nimbus retains tool-call parameters and results for 30 days, readable by support staff) -- that is the Data Input / Data Derivatives mechanism, not the change-control mechanism this dimension scores. The rubric assigns dimension 1.3 a primary impact axis of VI only, with no VC component (sovereignty_cvss_rubric_1.json). VC is not N, however: the scenario states explicitly that Nimbus publishes changes to *logging and retention* in release notes at the time they take effect, so an un-notified change can broaden what sensitive ERP/contract state is captured and for how long, before Northwind can react -- and Northwind's data-classification policy has no category for agent tool-call parameters, so the change would not be caught by internal control either. That is a partial, indirect confidentiality loss attributable to the versioning/change-control failure, i.e. Low.
    VI Primary Dependency Impact -- IntegrityHLagent · overrideOVERRIDE L -> H. The prior ('partial: limited or detectable alteration') was answered against the primary vendor-access scenario; assessed on its own, this dimension's integrity exposure is near-total. The rubric names VI as the sole primary impact axis for 1.3 and characterises an un-notified behaviour change as the textbook integrity failure. Northwind holds no weight custody, performs no evaluation or red-teaming of the runtime, and the vendor holds a standing contractual right to change the platform at its discretion at any time; notification arrives concurrently with the change ('Amber' on the rubric's Vendor Notice Posture scale), so there is no window in which Northwind can validate behaviour before buyers rely on it. FRB SR 11-7 treats knowledge of when a model was last changed, plus pre-reliance validation, as foundational model-risk controls -- Northwind can exercise neither, so its assurance over the runtime's behaviour is effectively total loss rather than partial. Confidence is held at moderate because the scenario only states that platform behaviour (logging, retention) changes this way and never confirms the model version itself is swapped, and because release notes do provide post-hoc traceability.
    VA Primary Dependency Impact -- AvailabilityNNagentCONFIRM N. The rubric gives 1.3 no VA axis (unlike 1.2 Model weight custody, where VA is listed), and the questionnaire confirms the component would keep operating ('None: we could keep operating this component'). An un-notified update changes how the agent behaves, not whether it is reachable -- the Nimbus runtime and connectors remain available. Residual uncertainty: if a future release retired a version Northwind depends on, availability of that specific capability could degrade, but nothing in the scenario describes version retirement or forced migration, so N rather than L.
    SC Downstream Blast-Radius Impact -- ConfidentialityLHagent · overrideOverride H -> L. The questionnaire's 'full downstream confidentiality loss' answer describes the primary dependency (tool-call parameters/results retained in Nimbus interaction logs and readable by support staff), which the rubric scores under 2.4 Tool-call parameters and 3.x Data Derivatives, where VC/SC are the named impact axes. For dimension 1.3 the rubric's primary impact axis is VI only, and the change-control exposure here is that Nimbus 'publishes changes to logging and retention in release notes at the time they take effect'. An un-notified change can widen what tool-call payloads (supplier pricing, rebates, approval-chain identities) are captured, how long they persist, or which support/subprocessor parties can read them -- a real but partial, incremental enlargement of an already-disclosed retention posture rather than a total new confidentiality loss at systems Northwind never contracted with. Scenario never states a subprocessor or new data-export path is added, so L (partial/limited) is the defensible value.
    SI Downstream Blast-Radius Impact -- IntegrityHHagentConfirm H. This is the rubric's textbook case for 1.3: 'Every downstream consumer of the model inherits an un-notified behavior change -- textbook Subsequent Integrity impact.' Northwind's agent does not just answer questions, it compares quotes, judges contract compliance and raises purchase requisitions into ERP and contract management via Nimbus connectors (cf. 4.3 tool/plugin execution: 'real-world action taken outside the model itself is Subsequent System impact almost by definition'). A behaviour-affecting platform or model-version change delivered only at the moment it takes effect means buyers and the ERP act on altered comparisons and requisitions with no prior notice and no evaluation gate (Northwind has no evaluation role), and the same runtime/connectors serve finance and supply-chain agents, so the altered behaviour propagates across many workloads undetected. SR 11-7's expectation that vendors conduct ongoing performance monitoring with client disclosure and that users validate their own use of vendor models is unmet here, removing the control that would otherwise detect the drift.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentConfirm L. A concurrent-notice change to platform behaviour (logging/retention, connector or model version) can break prompts, schemas or connector contracts and degrade the procurement, finance and supply-chain agents that share this standard runtime -- consistent with the questionnaire's 'some downstream workloads degrade' and concentrated blast radius -- but capability is not withdrawn (the questionnaire reports no availability loss at the dependency itself and reconstitution is possible with migration effort). Not S: the affected downstream systems are procurement/ERP/contract workflows with human buyers raising requisitions; nothing in the scenario indicates a physical or safety-relevant failure mode.
    E Precedent MaturityPPagentConfirming the questionnaire prior of P. The rubric defines E:P as 'demonstrated in research/incident reports, not confirmed against this org's own stack', and the ATLAS corpus README fixes the mapping rule: 'Realized / Incident -> E:A, Demonstrated / Exercise -> E:P'. The closest precedents in the corpus for an un-notified change to the model/artifact behind a consumed endpoint are all Exercise-type demonstrations, not confirmed incidents against comparable enterprise orgs: AML.CS0065 (Model Namespace Reuse, Unit 42, 2025) shows unpinned model references in Vertex AI and Azure AI Foundry silently resolving to a substituted artifact, and AML.CS0019 (PoisonGPT) shows a behaviour-altered model substituted under a near-identical identifier with a 0.1% benchmark delta, i.e. an inherited behaviour change that downstream consumers cannot detect. Both are explicitly tagged 'Exercise -> CASE Precedent Maturity E:P'. For this scenario specifically, the exercisable control is Nimbus's standing ability to change behaviour-relevant platform properties (logging, retention) with disclosure only 'at the time the change takes effect' - a documented contractual posture, but the scenario never states that such a change (or a model-version swap) has actually been exercised against Northwind or against comparable customers, and the classifier itself notes the model is never said to change. That rules out E:A, while the published release-note practice plus the research precedent clearly exceeds 'theoretical only', ruling out E:U. Confidence is moderate rather than high because no corpus source documents a realized, un-notified vendor-side version change at an enterprise agent platform; a reviewer with such an Incident-type source could reasonably escalate to A.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePXagent · overrideOverride of the questionnaire's 'Unknown' (X). The change-control object here is not neutral plumbing: the behaviour Nimbus can alter concurrently-with-notice is *logging and retention* of tool-call payloads that include approval-chain identities (personal data) and supplier commercial terms, held 30 days and accessible to vendor support staff. Under a GDPR Art. 28 processor arrangement, a unilateral vendor change to retention period, log scope or support access takes processing outside the controller's documented instructions and authorised sub-processing before Northwind can object — an independently reportable processor/controller failure, aggravated by the fact that Northwind's data-classification policy has no category for agent tool-call data, so it cannot evidence that the processing is covered by its records or DPIA. The EU AI Act framing retrieved (Art. 25: a substantial modification to an already-deployed system re-opens obligations, and Art. 25(4)/Art. 26 require the provider to furnish deployers the information needed to meet their own duties) reinforces that un-notified vendor-side modification is a compliance event, not just an operational one. Confidence is only moderate: the scenario never states which jurisdictions' data subjects are in scope, the assistant is not an Annex III high-risk use case, and the questionnaire respondent genuinely did not know — so P is an inference from the data types and the processor relationship rather than a stated fact.
    AU Silent/Automatic TriggerYNagent · overrideOverride of the prior N. The prior was answered against the *primary* dependency — targeted vendor/legal access to Northwind's interaction logs, which indeed needs a discrete action against Northwind specifically. Dimension 1.3's loss event is a different one: a platform-side version/behaviour change. Nimbus is a vendor-hosted multi-tenant enterprise platform reached over its API, and it 'publishes changes to logging and retention in release notes at the time they take effect' — release-note-driven changes are fleet-wide rollouts applied to every tenant at once with no per-customer decision and no customer opt-in. Northwind's ordinary use of the service is enough to inherit the new behaviour (consistent with the questionnaire's 'ordinary use of the service is enough to trigger it'). The rubric names AU as 1.3's supplemental hook precisely because an update propagates simultaneously to all consumers, so this is the metric that carries the finding. Residual uncertainty: the scenario describes platform-behaviour changes rather than an explicit model-version swap.
    R Portability / Exit RecoveryUUagentConfirms the prior. Northwind holds no weights and runs no evaluation, but the capability it depends on is an agent runtime plus vendor-supplied ERP/contract-management connectors — reconstitutable on another runtime at the cost of rebuilding connectors, re-integrating ERP auth, re-testing agent behaviour and re-contracting. The questionnaire states directly: 'Yes, with manual migration effort (re-embedding, re-integration, re-contracting).' Nothing in the scenario is unique to Nimbus (no proprietary fine-tune, no custodial weights), so I = Irrecoverable is not supported; equally, the connector and runtime coupling rules out A = Automatic.
    V Blast-Radius ConcentrationCCagentConfirms the prior, and the scenario states it explicitly for this dimension: 'Nimbus is Northwind's standard agent runtime and the same connectors are used by finance and supply-chain agents.' That is the rubric's own example of a Concentrated dependency — a shared control plane in the critical path of many/all AI workloads. For 1.3 specifically, concentration is what converts a single un-notified platform change into simultaneous behaviour drift across procurement, finance and supply-chain agents, which is the Subsequent Integrity pathway the rubric flags for this dimension.
    RE Exit / Mitigation EffortMMagentConfirms the prior. The mitigation that actually addresses 1.3 does not require re-architecture: negotiate a change-notification/version-pinning addendum (advance notice for behaviour-affecting changes, as the third-party risk guidance treats notification time frames as a bargainable contractual term), subscribe to and triage release notes, and stand up regression tests so behaviour drift in the shared runtime is detected. That is a definable project across contracting, security and the agent-platform team — Moderate. It is not Low, because the questionnaire records that the vendor operates on 'standard terms of service', so better notice terms must be extracted from a major vendor rather than toggled. I stopped short of H: full exit from the runtime and its connectors across three agent families would plausibly reach H, but mitigating this dimension's exposure does not require that, so H would overstate it. Moderate confidence given the judgement call between M and H.
    U Vendor Notice PostureAmberAmberagentConfirms the prior, directly on the scenario text: 'Nimbus publishes changes to logging and retention in release notes at the time they take effect.' That is the rubric's definition of Amber — 'Vendor discloses concurrently with the change taking effect'. Not Red, because disclosure demonstrably occurs. Not Green or Clear, because there is no advance window and no contractual guarantee of one (the questionnaire confirms the relationship runs on the vendor's standard terms, with a standing right to act at its discretion at any time). Operationally this means Northwind learns of a sovereignty-relevant change only after its agents have already begun operating under it — the exact 'notification may come after rather than before a behaviour-affecting update' concern the classifier identified for 1.3.
  2. 2 What are we feeding it?Headline

    2.4 Tool-call parameters and results (agentic-specific) · also 2.1
    HIGH7.3

    This is the headline finding. Every time a buyer asks the assistant to compare quotes, check a contract or raise a requisition, the assistant pulls live information out of Northwind's ERP and contract-management systems — supplier pricing, negotiated rebates, open purchase orders and the names of people in the approval chain — and that information travels through Nimbus as part of the request and the reply. Nimbus's own documentation says these requests and replies are kept in its interaction logs for thirty days and can be read by Nimbus support staff on request, which requires nothing more than the standard contract. Northwind's data-classification policy covers documents and databases and has no category at all for information that exists only as part of an agent's tool calls, so none of Northwind's usual handling, masking or retention rules apply to it. The same assistant also writes back into production systems, so if these requests or replies were altered, the ERP would act on them as legitimate, correctly-authorised transactions. Comparable exposures through enterprise agent connectors have already occurred in the real world, not only in research.

    Rating HIGH. For thirty days at a time, Northwind's complete procurement negotiating position and the identities of its approvers sit readable in a supplier's system, outside every control Northwind has written down.

    Evidence: vector, score and 21 metric rationales

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

    Ask the vendor What do our employees actually type into this thing, and does it include customer or confidential information? · Did we upload or connect any of our own internal documents for it to search? · Can this AI take real actions, look things up, change things, or does it only talk?

    MetricValuePriorSourceRationale
    AV Access PathNNagentConfirms prior. Nimbus Agents is an enterprise platform running in the major vendor's own cloud; Northwind's agent reaches ERP and contract-management systems through Nimbus-provided connectors, and tool-call parameters/results land in Nimbus's interaction logs retained 30 days and accessible to Nimbus support staff. The access path is therefore vendor-direct over the platform's API with no subprocessor intermediary and nothing resident in a customer-managed environment — the rubric's N = 'Network -- vendor-direct API access, no intermediary'. ATLAS AML.T0085/AML.T0047 confirm that AI-service tool access and service-side logs/metadata are a directly reachable collection surface for the party operating the service.
    AC Compulsion ComplexityLLagentConfirms prior. The retention and support-access behaviour is documented platform behaviour ('per the platform's documentation ... accessible to Nimbus support staff on request'), i.e. it follows from standard terms rather than requiring any barrier to be overcome. The scenario names no customer-managed encryption keys, no data-residency carve-out and no contractual restriction on the log store; Northwind's data-classification policy has no category for tool-call parameters and results at all, so there is not even a policy control to defeat. That matches the rubric's AC:L ('a standard ToS clause or routine legal process suffices'), and the rubric itself records dimension 2.4 as having no existing standard or non-AI analog to impose such barriers.
    AT Trigger ConditionsNNagentConfirms prior. The 30-day retention of tool-call parameters and results is continuous and unconditional, and support-staff access is 'on request' for abuse detection and debugging — a standing, discretionary right under the documented terms rather than something gated on a sanctions designation, litigation hold or security incident. The vendor also changes logging and retention unilaterally via release notes effective immediately, reinforcing that no external triggering event is needed. Rubric AT:N = 'control can be exercised at vendor discretion at any time'.
    PR Position RequiredLLagentConfirms prior. The parties positioned to read the tool-call traffic are the Nimbus platform operator and its support staff — i.e. the primary contracted vendor. The scenario identifies no subprocessor in the connector or logging path who would already have standing (which would be PR:N), and no compromise of Northwind's own administrative credentials is needed (PR:H), since the agent's connectors already hold legitimate ERP/contract-system access on Northwind's behalf — the same pattern ATLAS AML.T0085 describes, where the agent reaches data sources users cannot reach directly. Rubric PR:L = 'requires being the primary contracted vendor'.
    UI Org Action RequiredPPagentConfirms prior. No affirmative act by Northwind creates the exposure: every ordinary buyer request — compare quotes, check contract compliance, raise a requisition — causes live supplier pricing, negotiated rebates, open POs and approval-chain identities to be passed as tool-call parameters and returned as results, which are then logged for 30 days. Nimbus is the standard agent runtime and the same connectors serve finance and supply-chain agents, so routine use continuously feeds the exposure. This is rubric UI:P ('routine, ordinary use of the service triggers the exposure'). UI:N was considered because Nimbus can change logging/retention unilaterally (release notes at the time changes take effect), but that unilateral-change capability is a separate transparency weakness; the exposure of tool-call data itself is use-driven, so P is the correct value for this dimension.
    VC Primary Dependency Impact -- ConfidentialityHHagentConfirmed. The rubric defines the vulnerable-system group as CIA loss AT the dependency named by the taxonomy node — here the tool-call parameter/result channel on Nimbus (dimension 2.4, primary impact axes VC/VI per sovereignty_cvss_rubric_1.json). Every call carries live system state: supplier pricing, negotiated rebates, open POs and approval-chain identities. That payload is retained for 30 days in Nimbus interaction logs and is accessible to Nimbus support staff on request, under standard ToS with no additional barrier (AV:N, UI:P, PR:L per the questionnaire). The exercising party can therefore read the sensitive data outright in plaintext — total loss on this axis, matching the questionnaire's 'Full: can read the sensitive data outright'. Aggravating: Northwind's data-classification policy has no category for data existing only as tool-call parameters and results, so no compensating control (minimisation, masking, retention limits) applies — exactly the gap the rubric flags for 2.4 ('gap_severity: High, existing_standard: None identified -- no non-AI analog'). MITRE ATLAS AML.T0085/AML.T0085.001 (Data from AI Services / AI Agent Tools, maturity Demonstrated) confirms that agent tool invocations are a recognised collection surface for data the requester could not otherwise reach.
    VI Primary Dependency Impact -- IntegrityLLagentConfirmed as Low. Integrity at the dependency itself concerns alteration of the tool-call parameters/results as they transit the Nimbus connectors. The platform is positioned to modify or mis-render connector payloads (ATLAS AML.T0086 describes redirecting/abusing legitimate tool invocations, and AML.M0024/M0028/M0029 exist precisely because tool invocations are alterable), so this is not None. But it is not total: the authoritative records remain in Northwind's own ERP and contract-management systems, and procurement actions pass through requisition and approval-chain workflows that leave independent records, so large-scale or sustained alteration of quotes, rebates or requisitions would be limited and at least partly detectable by reconciliation against ERP. This matches the questionnaire's 'Partial: limited or detectable alteration'. Note the severe integrity exposure here is downstream, not primary: altered agent outputs acted on by ERP/finance/supply-chain agents belongs to SI, which the rubric explicitly flags for 2.4 ('a tool call can act on a live production system, so impact literally lands on a system subsequent to the AI dependency itself').
    VA Primary Dependency Impact -- AvailabilityNNagentConfirmed as None. The sovereignty event characterised for this dimension is vendor-side visibility into, and retention of, tool-call traffic — a confidentiality/integrity event, not a withdrawal of capability. Nothing in the scenario indicates the logging/retention control removes or degrades the tool-call channel itself; Northwind's ERP and contract systems remain directly usable and the questionnaire states 'None: we could keep operating this component'. Exit/portability concerns (Nimbus is the standard runtime, shared connectors, R:U moderate migration effort) are captured by the supplemental R/V/RE metrics and the downstream SA finding ('some downstream workloads degrade'), not by primary availability at this dependency.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentCONFIRM prior H. The data at issue is not a document but live ERP/contract state surfaced only as tool-call parameters and results: supplier pricing, negotiated rebates, open purchase orders and approval-chain identities. Per the platform documentation these results are retained for thirty days in Nimbus's interaction logs and are accessible to Nimbus support staff on request — a system and a population subsequent to the AI dependency itself, and one Northwind's data-classification policy does not cover at all. The questionnaire's own answer ('Full: sensitive data becomes readable by a party we never contracted with') matches: support staff and any subprocessor or legal-process recipient of those logs read the commercially sensitive payload outright, unredacted and in business-identifiable form (named suppliers, named approvers). Corpus support: the rubric marks 2.4 subsequent-impact-relevant with the note that tool calls act on live production systems; ATLAS AML.T0085 establishes agent tool access as a collection surface for data users cannot reach directly; the Microsoft EU Data Boundary text confirms provider interaction/system logs capture transaction content and are routinely accessed by provider staff; 18 U.S.C. §2713 confirms those provider-held copies are compellable regardless of location. Because the whole procurement negotiating position is legible from a single retained log window, loss on this axis is near-total rather than partial.
    SI Downstream Blast-Radius Impact -- IntegrityHHagentCONFIRM prior H. Note the deliberate asymmetry with the primary axis: at the dependency itself integrity loss was judged partial/detectable (VI), but downstream it is total, because the agent does not merely read — it raises purchase requisitions and renders contract-compliance verdicts, so altered tool-call parameters are executed as writes against production ERP and contract-management systems. A manipulated quantity, price, supplier or approval-chain identity enters the ERP as a legitimate, correctly-authenticated transaction and is acted upon with no independent record to reconcile against, since the tool-call traffic sits outside every existing classification and control regime. Blast radius compounds: Nimbus is the standard agent runtime and the same connectors serve finance and supply-chain agents, so corrupted connector behaviour lands on multiple production systems at once. Corpus support: ATLAS AML.CS0053 (postmark-mcp) is the realized precedent for a trusted connector silently altering the real-world action while the workflow looks normal (AML.T0011.002 poisoned tool, AML.T0086 exfiltration via tool invocation); AML.T0112.000 establishes that control of an agent confers the agent's full write permissions on downstream systems; AML.T0081 shows approval/human-in-the-loop settings are themselves alterable. EU AI Act Art. 15(5) and recital 76 treat such output alteration as propagating into erroneous downstream decisions. This matches the questionnaire's 'Full: downstream systems act on altered outputs without detection.'
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentCONFIRM prior L, and explicitly reject S. If the Nimbus connector path is withdrawn or degraded, the ERP and contract-management systems remain fully operable and buyers revert to manual quote comparison and requisition entry; what degrades is the agent-mediated throughput of procurement, finance and supply-chain workflows that share these connectors — partial, not total, downstream availability loss, consistent with the questionnaire's 'some downstream workloads degrade' and with the stated ability to reconstitute the capability through manual migration. Availability loss is wider than at the dependency itself (where VA was assessed None) precisely because the shared connector fabric fans out to several agent workloads, which justifies L rather than N. S is not warranted: procurement requisitioning in consumer goods is a commercial-decision pathway with human buyers in the loop, and the corpus provides no basis for a physical-harm or safety-relevant failure mode here — the EU AI Act fail-safe/safety discussion applies to systems whose interruption bears on persons or physical processes, which an unavailable procurement assistant does not.
    E Precedent MaturityAPagent · overrideOVERRIDE of the questionnaire prior P. The prior rests on the respondent's framing 'demonstrated in research or incident reports, not confirmed against our stack'. That framing conflates two different tests: the rubric's E:P hinges on 'not confirmed against this org's own stack', but E:A hinges only on 'documented real-world cases of this control being exercised against COMPARABLE ORGS'. Northwind never needs to have been hit for E:A to hold. Two independent corpus lines clear the comparable-orgs bar for this dimension. (1) Rubric-level: the ATLAS bridge document fixes the CASE anchors for dimension 2.4 and the maturity mapping 'Realized / Incident -> E:A'. Of the two 2.4 anchors, AML.T0086 'Exfiltration via AI Agent Tool Invocation' is rated 'Maturity: Realized -> CASE Precedent Maturity E:A' and is tagged as the 2.4 anchor; its description is Northwind's mechanism verbatim (sensitive data carried in tool input parameters, transmitted as part of a seemingly legitimate action). The second anchor, AML.T0053, is only Demonstrated (E:P), so the dimension is mixed — but the rubric's own highest-rated anchor for 2.4 is Realized, and per ADR practice the finding takes the documented maturity of the realized anchor. (2) Case-level: beyond the researcher exercises against directly comparable enterprise connector stacks (CS0037 full CRM exfiltration via Copilot Studio agent tools; CS0039 Jira/Atlassian MCP; CS0045 Cursor MCP; CS0066 ZombieAgent), the corpus carries Incident-type — not Exercise-type — campaigns in which live system state was collected through agent tool invocation against real organisations: CS0069 GTG-1002 (Incident, 2025-09) and CS0071 (Incident, 2026-07), both employing AML.T0126, whose targeted material expressly includes 'conversation histories, retrieval databases, deployment information, logs and other operational data' — i.e. exactly the Nimbus interaction-log class holding Northwind's supplier pricing, rebates and approval-chain identities. (3) On the sovereignty actor the rubric actually cares about here (the vendor, a subprocessor, or a compelling legal authority — not a hacker), the realized precedent is even stronger: the DOJ CLOUD Act white paper documents compelled production of provider-held data 'stored remotely on behalf of a user' as routine, standing practice, and the EU AI Act (Arts. 12, 19, 26) codifies provider retention of automatically generated logs plus competent-authority access to them. Nimbus's documented 30-day retention of tool-call results, readable by support staff on request, is the same control surface, reachable 'at its discretion, at any time' under standard terms per the questionnaire. Confidence is held at 0.72 rather than higher because the two 2.4 anchors disagree (T0053 Demonstrated vs T0086 Realized), the closest connector-level demonstrations are researcher exercises rather than confirmed breaches, and no corpus source documents an exercise against Nimbus itself — the one point on which the questionnaire's self-assessment stands.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePXagent · overrideOverride of the questionnaire's 'Unknown' (X). X is only permissible where there is genuinely no evidence; here the scenario supplies enough. Tool-call parameters and results explicitly include 'approval-chain identities' — personal data of Northwind staff (and, via supplier quotes/rebates, supplier contacts) — which are retained for thirty days in Nimbus's interaction logs and are 'accessible to Nimbus support staff on request'. Under a GDPR processor relationship that constitutes processing by the provider for its own purposes (abuse detection, debugging) with standing staff access; because Northwind's data-classification policy has no category for this data, there is no documented instruction, no scoping and no access-control baseline covering it, so an exercise of that access is an independently reportable personal-data breach / Art. 28 processor-scope failure rather than merely a commercial issue. Note the limit of this finding: the retrieved EU AI Act material shows a procurement assistant is not an Annex III high-risk system, so the Title III limb does not apply and the trigger rests on data-protection law alone — hence moderate rather than high confidence.
    AU Silent/Automatic TriggerYNagent · overrideOverride of the prior N. The respondent answered N by reference to support-staff access ('a discrete action against us specifically'), which is correct for that one sub-event. But the sovereignty-loss event at dimension 2.4 is the capture and retention of live tool-call state outside Northwind's control, and that is automatic: 'per the platform's documentation, retained in Nimbus's interaction logs for thirty days' is a platform default that applies to every tenant by ordinary use, with no per-customer decision — consistent with the questionnaire's own answer that 'ordinary use of the service is enough to trigger it'. The same holds for changes in scope: Nimbus 'publishes changes to logging and retention in release notes at the time they take effect', i.e. a unilateral change to what tool-call data is logged lands on all customers simultaneously. ATLAS AML.T0085 documents this as a systemic property of agent/tool data flows rather than a targeted one. Confidence is moderate because the read-out step (support access) genuinely is case-by-case.
    R Portability / Exit RecoveryUUagentConfirms the prior. The underlying systems of record — ERP and contract management — remain Northwind's own; what is vendor-specific is the Nimbus agent runtime and its connectors. Reconstituting the capability on another runtime is possible but requires rebuilding/re-certifying the ERP and contract connectors, re-integrating the procurement agent and re-contracting, i.e. manual migration effort rather than automatic reconstitution (questionnaire: 'Yes, with manual migration effort'). Not I, because no irreplaceable vendor-held artefact (e.g. custody of model weights, the rubric's primary hook for R) is involved; not A, because the connector/integration layer does not port over unchanged. R measures reconstitution of the capability — the tool-call data already sitting in Nimbus's thirty-day logs is not recoverable, but that is scored on the confidentiality axes, not here.
    V Blast-Radius ConcentrationCCagentConfirms the prior, and this is the metric the rubric expects to carry the finding for 2.4 (supplemental_hook: 'V (Value Density)'). The scenario is explicit: 'Nimbus is Northwind's standard agent runtime and the same connectors are used by finance and supply-chain agents.' A single vendor-side logging and retention behaviour therefore sits in the critical path of procurement, finance and supply-chain agent workloads at once, and the connector layer is a shared control plane concentrating ERP and contract-system state — the textbook Concentrated case, matching the questionnaire's 'Many or all: shared control plane'.
    RE Exit / Mitigation EffortMMagentConfirms the prior. The exposure can be mitigated without re-architecture: negotiate a zero-/short-retention or no-support-access term for interaction logs, restrict connector payloads to the minimum fields needed, and extend the data-classification policy to cover tool-call parameters and results (the gap the scenario names). Each is a project — contractual plus configuration work across the shared connectors — rather than a trivial swap (so not L) and does not require replacing the runtime or physical infrastructure (so not H). The H boundary is close, however: because Nimbus is the standard runtime for three agent families (see V), if the vendor refuses the contractual fix the only remaining mitigation is to proxy all tool calls through a Northwind-controlled redacting gateway, which would be re-architecture. Confidence is moderate for that reason.
    U Vendor Notice PostureAmberAmberagentConfirms the prior, directly on the scenario text: 'Nimbus publishes changes to logging and retention in release notes at the time they take effect.' That is disclosure concurrent with the change, not advance notice — so Amber, not Green or Clear. It is not Red because the sovereignty-relevant parameters (logging scope, retention period) are in fact published and documented; but concurrent-only notice gives Northwind no window to assess or object before new categories of tool-call state begin being retained.
  3. 3 What does it create from our data: and where does THAT go?

    3.6 Cached / derived artifacts · also 3.5, 3.3
    MEDIUM5.7

    The information the assistant handles does not simply pass through and disappear: the thirty-day interaction logs are a rolling copy of live pricing, rebate, purchase-order and approver data drawn from across procurement, finance and supply chain, held in Nimbus's own environment. This copy does not appear in any data flow Northwind has reviewed and is not covered by its classification policy, so no retention limit, minimisation or deletion control of Northwind's own applies to it. Northwind has no way to purge these records, export them or verify their deletion; it can only wait for the vendor's retention period or ask the vendor. The retention period and the scope of what is captured are set by Nimbus and can be widened for all customers at once by a release note.

    Rating MEDIUM. Northwind has a shadow copy of its commercial crown jewels that it cannot see into, cannot delete and did not plan for — moderate today only because the vendor currently caps it at thirty days.

    Evidence: vector, score and 21 metric rationales

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

    Ask the vendor Does this turn our documents into some kind of derived file (an “embedding”) so it can search them faster? · If so, who stores that derived file, you, or a completely different company? · Do you keep a copy of everything the AI said back to us, a log of how we used it, or a record of when we said the answer was wrong?

    MetricValuePriorSourceRationale
    AV Access PathNNagentThe derived artifacts (30-day interaction logs of tool-call parameters and results) live in Nimbus's own cloud, not in any Northwind-managed store, and are reached by the vendor directly through its own platform/support tooling with no intermediary. That is the rubric's definition of Access Path = Network ('vendor-direct API access, no intermediary'). Northwind holds no copy of these traces in a customer-controlled environment, so L and P are excluded; the scenario names no subprocessor as the holder of the logs, so A is excluded. Confirms the questionnaire prior.
    AC Compulsion ComplexityLLagentNothing has to be overcome: retention of tool-call content for thirty days and support-staff access 'on request' are stated in the platform's own documentation, i.e. the standard terms of service. There are no customer-managed keys, data-residency carve-outs or contractual exclusions for agent traces — indeed Northwind's data-classification policy has no category for tool-call parameters and results at all, so no compensating control exists to raise complexity. Rubric AC=L ('a standard ToS clause or routine legal process suffices'). Confirms the prior.
    AT Trigger ConditionsNNagentAT is the metric the rubric flags as primary for node 3.6, so it is assessed carefully. Creation and retention of the derived artifact is unconditional: every tool call's live ERP/contract state is written to the interaction log by default for thirty days, with no triggering event required — ATLAS (AML.T0085.001, AML.M0024) describes such tool-invocation logging as standard platform behaviour. Access by Nimbus support staff is nominally scoped to 'abuse detection and debugging', but that is a stated purpose in vendor documentation, not a technical or contractual gate; the vendor can invoke it at its own discretion at any time, and it can also change logging and retention unilaterally via release notes effective immediately. A purpose statement the vendor both defines and interprets does not amount to the rubric's 'specific triggering event (sanctions designation, litigation hold, incident)'. Hence AT=N, confirming the prior; confidence is moderated because a reviewer could read the debugging purpose-limitation as a soft trigger (P).
    PR Position RequiredLLagentThe retained traces sit inside the Nimbus platform and the scenario names only 'Nimbus support staff' as able to read them on request. Exercising this control therefore requires being the primary contracted vendor (rubric PR=L), not merely standing somewhere in the subprocessor chain (N); and it requires no compromise of Northwind's own administrative credentials (H). Residual uncertainty: the vendor's underlying cloud/infrastructure subprocessors could in principle reach log storage, which would argue for N, but neither the scenario nor the questionnaire evidences a subprocessor with access. Confirms the prior.
    UI Org Action RequiredPPagentNo affirmative act by Northwind is needed and none can prevent it: simply letting buyers use the procurement assistant causes every tool call's live system state to be materialised into the vendor's interaction logs. That is the rubric's Passive case ('routine, ordinary use of the service triggers the exposure'), which fits 3.6 precisely because the artifact is a by-product of normal operation and appears in no reviewed data-flow diagram. UI=N was considered, since Nimbus can change logging/retention unilaterally in release notes at the moment they take effect, but that unilateral-change capability is a change-notification/automation concern captured by other metrics, whereas the exposure of this dimension is generated by ordinary use. Confirms the prior.
    VC Primary Dependency Impact -- ConfidentialityHHagentCONFIRM H. The derived artifact in scope is Nimbus's 30-day interaction log, which per the platform's own documentation retains the parameters and results of every tool call and is accessible to Nimbus support staff on request. That content is not metadata: it is live supplier pricing, negotiated rebates, open purchase orders and approval-chain identities — effectively a rolling 30-day shadow copy of the sensitive state of Northwind's ERP and contract-management systems, concentrated across finance, supply-chain and procurement agents that share the same connectors. Confidentiality loss on this artifact is therefore total or near-total, not partial: a party exercising access reads the sensitive payload outright (questionnaire: 'Full: the exercising party can read the sensitive data outright', access needing 'nothing beyond its standard terms of service or routine legal process'). Microsoft's EU Data Boundary material corroborates that vendor-side system-generated logs reflecting user/system interactions must contain the substantive event content and identifying fields to serve their purpose, and that access limitation rests on vendor-internal controls rather than customer control. Aggravating and specific to 3.6: Northwind's data-classification policy has no category for data existing only as tool-call parameters and results, so no classification-driven handling or minimisation control is applied to this copy at all.
    VI Primary Dependency Impact -- IntegrityLLagentCONFIRM L. The rubric lists VI as a primary axis for 3.6, so N would understate the exposure: the retained artifact is wholly under vendor control, Northwind has no read-back, verification or correction path into Nimbus's interaction logs, and the vendor can change logging/retention behaviour unilaterally — disclosed only in release notes 'at the time they take effect', so alteration of what is captured or kept is possible without prior knowledge. However, the impact is partial rather than total because these logs are declared to be for abuse detection and debugging; they are not re-fed into the agent's reasoning as cached retrieval results, and the authoritative state remains in Northwind's own ERP and contract-management systems. Tampering with or silent mutation of the log copy therefore corrupts a secondary record (evidential/forensic value, dispute reconstruction on pricing and approval chains) rather than the operative data, and the questionnaire's own reading of alteration at the dependency is 'Partial: limited or detectable alteration'. L is the right calibration.
    VA Primary Dependency Impact -- AvailabilityNNagentCONFIRM N. Availability impact is assessed on this category's own artifact, and Northwind's procurement workflow has no operational dependency on Nimbus's retained interaction logs: they exist for the vendor's abuse-detection and debugging purposes. If the logs were withdrawn, purged early, or made inaccessible, the agent, the connectors and the ERP/contract systems continue to function unaffected (questionnaire: 'None: we could keep operating this component'). The rubric for 3.6 does not list VA as a primary impact axis, and the real sovereignty problem with this artifact is the opposite of unavailability — it is non-purgeability and persistence beyond Northwind's control, which is captured by the supplemental Recovery metric rather than VA.
    SC Downstream Blast-Radius Impact -- ConfidentialityLHagent · overrideOverride of prior H, but not to N. The rubric marks 3.6 'subsequent_impact_relevant: false', and its definition of a true SC finding is data reaching a party that was never the org's contracted vendor (as in 3.1: 'the embedding vendor was never the org's contracted AI vendor'). Here the derived artifact -- 30 days of tool-call parameters and results containing supplier pricing, negotiated rebates, open POs and approval-chain identities -- is held by Nimbus, the contracted vendor, and read by Nimbus support staff on request: that is primary-dependency confidentiality (VC), not subsequent. A residual L is justified by two genuine onward channels the questionnaire supports: the vendor can be reached by 'routine legal process' (a legal authority Northwind never contracted with), and Nimbus's subprocessor/support-staffing chain is not disclosed to Northwind (changes only appear in release notes 'at the time they take effect'). Statutory log-retention regimes likewise place agent logs under the provider's control for extended periods (EU AI Act Art. 19 provider log-keeping), reinforcing that the artifact persists where Northwind cannot purge it. The onward loss is bounded -- a rolling 30-day window of commercial state, not the live ERP or contract repository -- hence partial rather than total.
    SI Downstream Blast-Radius Impact -- IntegrityNHagent · overrideOverride of prior H. The prior ('downstream systems act on altered outputs without detection') describes the agent's live outputs and connector actions -- the rubric assigns that to 3.3 (model outputs) and 4.3 (tool/plugin execution, 'real-world action taken outside the model itself is Subsequent System impact almost by definition'), both marked subsequent_impact_relevant: true. The artifact assessed here is different: Nimbus's retention log is a write-only by-product kept for abuse detection and debugging. Nothing in the scenario gives it a read path back into Northwind's ERP, contract-management system, or the finance and supply-chain agents; no downstream system consumes the log to make a decision. Alteration or fabrication of log content is therefore an integrity loss at the artifact itself (VI, which the rubric names as a primary axis for 3.6) with no propagation, so SC/SI separation argues for N here. Residual caveat a reviewer should note: if Northwind ever relies on these traces as evidentiary records for procurement audit or supplier dispute, SI would rise to L.
    SA Downstream Blast-Radius Impact -- AvailabilityNLagent · overrideOverride of prior L (which, with 'some downstream workloads degrade', reflects the shared Nimbus runtime/connector plane on which many or all Northwind AI workloads depend -- a primary-dependency and Category 4 concern). Availability of a 30-day vendor-side log has no bearing on Northwind's operations: the questionnaire itself records that the capability cannot be withdrawn at this dependency ('None: we could keep operating this component'), and deletion, truncation or shortened retention of the logs would stop no procurement, finance or supply-chain workload. Procurement decision support is not a safety-relevant function, so S does not apply. The real sovereignty cost of this dimension is non-purgeability, which the rubric routes to the supplemental hook 'R (Recovery -> purgeability)' rather than to SA.
    E Precedent MaturityPPagentConfirming the questionnaire prior of P for dimension 3.6 (cached/derived artifacts: Nimbus's 30-day interaction logs holding tool-call parameters and results, readable by vendor support staff on request). The corpus gives abundant *demonstration-grade* precedent for sensitive content ending up in, and being extracted from, AI-platform side artifacts: ATLAS AML.T0085.001 'AI Agent Tools' (Demonstrated -> E:P) covers agents invoking tools that pull data from internal APIs/services; AML.T0057 LLM Data Leakage (Demonstrated -> E:P) and AML.CS0035 (Slack AI exfiltration via indirect prompt injection, Exercise -> E:P) show retained/retrievable agent-side content being reached in research exercises rather than in confirmed attacks on comparable procurement deployments. Two sources pull toward A but do not, on their own, carry it for this specific artifact class: (a) ATLAS AML.T0035 AI Artifact Collection is rated Realized (E:A) and explicitly includes 'telemetry data produced when interacting with a model', but it is framed as adversary collection on victim-controlled systems, not the vendor-side support/legal access path that dimension 3.6 describes; (b) 18 U.S.C. 2713 and the DOJ CLOUD Act white paper establish that a provider must 'preserve, backup, or disclose ... any record or other information pertaining to a customer' in its possession regardless of location, and that routine legal process against providers is actually used - a real, exercised mechanism, but the documented practice concerns stored customer content generally, with DOJ guidance even steering prosecutors to the enterprise first, so there is no documented case of agent tool-call traces at a comparable enterprise being handed over or support-mined. Net: precedent is demonstrated and the legal/operational path is real and routinely available, but not confirmed against this class of artifact at comparable organizations - E:P, at the upper end of that band. Moderate confidence because of the acknowledged 3.6/3.5/3.3 overlap and the adjacency of the E:A-rated AML.T0035.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePXagent · overrideOverride of the questionnaire's 'Unknown'. The retained artifact is not neutral metadata: tool-call parameters and results carry approval-chain identities (identifiable buyers/approvers) plus negotiated supplier pricing and rebates, persisted for 30 days in a processor's logs and readable by Nimbus support staff on request. Northwind's data-classification policy has no category for this content, so there is no documented instruction, retention basis or records-of-processing entry covering it — a processor-governance gap of the GDPR Art. 28/30/32 type, and any support-staff access outside documented instructions would be a reportable personal-data breach. The EU AI Act treats automatically generated logs that contain input data and the identities of persons involved as regulated, personal-data-bearing records (Art. 12, Art. 19, Art. 26(6)), and Microsoft's EU Data Boundary documentation is explicit that provider system-generated logs of this kind retain content and are only pseudonymised, i.e. still personal data. Confidence is moderate because the regulatory trigger depends on Northwind's EU establishment/data-subject footprint, which the scenario implies (global company, EU-style vendor terms) but does not state.
    AU Silent/Automatic TriggerYNagent · overrideOverride. The questionnaire's 'No — requires a discrete action against us specifically' describes targeted vendor action against the primary dependency (e.g. a support-staff pull of Northwind's logs). For this category the sovereignty-loss event is the capture and retention of tool-call content itself, which is platform default behaviour documented for the product and triggered by ordinary use — no per-customer decision is involved. Critically, the scenario states Nimbus publishes changes to logging and retention in release notes at the time they take effect, so a widening of what is logged or how long it is kept lands on every tenant simultaneously. Microsoft's EU Data Boundary material shows the same pattern: system-generated-log retention and access policy is set provider-side and applied uniformly across customers.
    R Portability / Exit RecoveryIUagent · overrideOverride, and this is the metric that carries the category. The rubric defines the supplemental hook for 3.6 as 'R (Recovery -> purgeability)', i.e. for derived artifacts R measures whether the organisation can get the artifact back under its own control. Northwind cannot: the 30-day interaction logs live in Nimbus's estate, retention is set by the vendor's policy, support access is granted by the vendor, and there is no described customer-side purge, export or deletion-verification mechanism. Exiting Nimbus would let Northwind rebuild the agent and connectors elsewhere (which is what the questionnaire's 'U' answers, for the runtime), but it would not undo or purge the derived record of ERP pricing, rebates and approver identities already captured — that residue is recoverable only through the original vendor. The EU Data Boundary precedent reinforces this: providers deliberately decline to anonymise system-generated logs and keep retention under their own control. Confidence is tempered because retention is documented and time-bounded at 30 days, which an alternative reading could score as 'U' (wait out or request deletion through the vendor).
    V Blast-Radius ConcentrationCCagentConfirmed. Nimbus is Northwind's standard agent runtime and the same vendor-supplied connectors are used by the procurement, finance and supply-chain agents, so a single log store aggregates derived content from many or all AI workloads. Concentration is worse than for the live dependency: the artifact accumulates 30 days of cross-domain ERP and contract state in one vendor-controlled location, which is precisely the aggregate-concentration effect the rubric flags for the Data Derivatives dimensions, and the collection value ATLAS attributes to agent tool-invocation telemetry.
    RE Exit / Mitigation EffortHMagent · overrideOverride. For the runtime dependency a migration project ('Moderate') is a fair estimate, but mitigating this derived-artifact exposure specifically has no cheap path: logging of tool-call parameters and results is documented platform behaviour, not a tenant setting, so the available fixes are (i) re-contracting for a zero/reduced-retention or no-support-access commitment with a major vendor, or (ii) re-architecting the shared connector layer to minimise, tokenise or redact sensitive fields before they cross into Nimbus — which affects the finance and supply-chain agents too — plus extending the data-classification policy to cover a data class it does not currently recognise. Both options fall squarely in the rubric's 'requires re-architecture or re-contracting' band. The EU Data Boundary documentation shows providers resist altering system-generated-log content precisely because it degrades their operational purpose, so a simple contractual carve-out should not be assumed trivial.
    U Vendor Notice PostureAmberAmberagentConfirmed directly from the scenario: 'Nimbus publishes changes to logging and retention in release notes at the time they take effect' — disclosure is concurrent with the change, with no advance window and no contractual notice guarantee, which is the rubric's definition of Amber. Note this is the posture for exactly the artifact class at issue here (logging and retention), so the prior applies to this category on its own terms rather than by inheritance.
  4. 4 Who's deciding what the AI sees and does?

    4.3 Tool/plugin execution environment · also 4.2
    HIGH7.3

    The connectors that reach into Northwind's ERP and contract-management systems are supplied and operated by Nimbus and run inside Nimbus's environment, holding standing access into Northwind's production systems. The assistant does not only read and advise — it raises purchase requisitions and issues contract-compliance judgements, so a wrong or manipulated instruction becomes a real transaction in a system of record. Supplier quotes and contract text that the assistant reads are outside Northwind's control and are a recognised route for hostile instructions to reach an agent and trigger action; published incidents show vendor-supplied agent connectors being altered so that the agent quietly did something other than what the workflow appeared to show. The same connectors are shared by the finance and supply-chain agents, so a problem in that layer reaches several production systems at once, and Northwind has no independent record of tool activity to reconcile against.

    Rating HIGH. If anything goes wrong in the vendor's connector layer, it lands as authorised purchase activity in Northwind's live ERP across several business areas before anyone at Northwind would notice.

    Evidence: vector, score and 21 metric rationales

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

    Ask the vendor Who decides which of our documents actually get shown to the AI when it answers a question? · Who runs the safety filter that sees every question and answer, and can we see its rules? · If the AI takes an action on our behalf, where does that action actually happen, in your systems, ours, or a third location?

    MetricValuePriorSourceRationale
    AV Access PathNNagentConfirm N (Network — vendor-direct API access, no intermediary). The connectors are not customer-deployed agents inside Northwind's estate; they are 'connectors Nimbus provides' executing in Nimbus's own cloud and reached directly over its API, matching the questionnaire ('In the vendor's own cloud, reached directly over its API'). Tool-call parameters and results therefore transit and rest (30-day logs) on vendor-controlled network infrastructure with no subprocessor hop described (so not A), and nothing resides in a customer-managed runtime (so not L or P). ATLAS AML.T0017.002 explicitly characterises such connectors/remote APIs as model-callable interfaces hosted away from the data owner, and AML.T0010 notes agents can be connected to remotely-hosted tools, which is the configuration here.
    AC Compulsion ComplexityLLagentConfirm L (Low — standard ToS clause or routine legal process suffices). Access to tool-call parameters and results is granted by the platform's own published documentation: retention for 30 days 'for abuse detection and debugging, accessible to Nimbus support staff on request'. No customer-managed keys, data-residency carve-out, or connector-side encryption/tokenisation is described that an exercising party would first have to overcome; Northwind's data-classification policy has no category for tool-call data at all, so no compensating contractual barrier exists either. Nothing beyond ordinary terms or routine legal process is needed, which is the rubric's definition of Low.
    AT Trigger ConditionsNNagentConfirm N (None — exercisable at vendor discretion at any time). Support-staff access to interaction logs is 'on request', not gated on an incident, litigation hold or designation; and Nimbus can change logging/retention behaviour unilaterally, publishing it in release notes only at the time it takes effect. Because the connectors run in the vendor's environment, the vendor also has standing capability over the tool layer itself (ATLAS AML.T0110 shows that control of a tool's definition or runtime responses is sufficient to alter agent behaviour and introduce hidden side effects — no external trigger required). No specific triggering event is therefore a precondition, so P is not warranted.
    PR Position RequiredLLagentConfirm L (Low — requires being the primary contracted vendor). The scenario names only Nimbus as supplier and operator of the connectors and of the interaction logs; the position needed to read tool-call state or alter connector behaviour is that of the platform vendor (or its support organisation acting under it). No subprocessor is described as sitting in the connector execution path, so N (any party in the subprocessor chain) overstates the standing available. Equally, no compromise of Northwind's own administrative credentials is needed — the vendor already holds the connector-side execution position and the credentials used to reach ERP/CLM (cf. ATLAS AML.T0083/T0098 on agent-tool configuration credentials granting access to systems outside the agent) — so H is too strong.
    UI Org Action RequiredPPagentConfirm P (Passive — routine, ordinary use triggers the exposure). Northwind need take no affirmative step: every buyer asking the assistant to compare quotes, check compliance or raise a requisition causes connector tool calls that push live ERP/CLM state into the vendor-run execution environment and into 30-day logs. Ordinary use is literally the trigger, matching the questionnaire. N was considered because Nimbus can also change logging/retention unilaterally (release notes at effect time), but that unilateral capability is scored under AT and the supplemental notice/automatable metrics; the exposure at this dimension is realised through normal operation of the agent rather than a silent vendor-side change alone, and it is certainly not A since no opt-in or update acceptance is required.
    VC Primary Dependency Impact -- ConfidentialityHHagentConfirmed. The vulnerable system for 4.3 is the Nimbus-run tool/connector execution environment. Every tool call to Northwind's ERP and contract-management systems carries live production state as parameters and results (supplier pricing, negotiated rebates, open POs, approval-chain identities), and per platform documentation the full request/response payloads are retained for 30 days in Nimbus interaction logs accessible to Nimbus support staff on request. The questionnaire records full confidentiality loss at the dependency ('the exercising party can read the sensitive data outright'), reachable through ordinary use with nothing beyond standard ToS or routine legal process to overcome. Northwind's data-classification policy has no category for tool-call parameters/results, so no compensating control narrows the exposure. The rubric explicitly flags this agentic data class (2.4 'Tool-call parameters and results') as impacting VC with no existing non-AI analog, which supports total loss on this axis for the execution environment that handles those payloads.
    VI Primary Dependency Impact -- IntegrityLLagentConfirmed as partial at the dependency itself. The vendor runs the connector code and the agent loop, so tool selection and arguments could be altered (ATLAS AML.T0110 tool poisoning, AML.T0053 tool invocation abuse, AML.T0051 prompt injection driving unintended tool calls). However, at the execution-environment layer the alteration is bounded and at least partly detectable: calls land on Northwind's own ERP/contract systems, which retain their own records, approval chains and identities, and the questionnaire records 'Partial: limited or detectable alteration' at this dependency. The severe, undetected integrity consequence in this scenario is the real-world action downstream (requisitions raised, 'downstream systems act on altered outputs without detection'), which per the 4.3 rubric note belongs on the Subsequent System integrity axis rather than on VI.
    VA Primary Dependency Impact -- AvailabilityLNagent · overrideOverridden from N to L for this category specifically. The questionnaire's 'None' answer is about the primary dependency (the platform as a whole, which Northwind believes it could keep operating), but dimension 4.3's vulnerable system is the vendor-supplied connector/tool-execution layer: it runs in Nimbus's cloud, is reached only over the vendor's API, the vendor holds a standing discretionary right under the contract, and changes to logging/retention (and by extension connector behaviour) take effect at the moment they are published in release notes. Throttling, deprecating or restricting a connector therefore degrades the agent's ability to act on ERP and contract management at the vendor's discretion, and exit is a moderate project with manual re-integration. The loss is partial rather than total because buyers and the ERP/contract systems themselves remain directly operable without the agent, and the questionnaire's own downstream reading is only 'some downstream workloads degrade'. Low confidence: no corpus source speaks directly to connector-availability withdrawal, so this is reasoned from the scenario and contract terms.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentCONFIRM H. The subsequent systems are Northwind's ERP and contract-management platforms, and every tool call executes through Nimbus-supplied, Nimbus-run connectors, so live production state — supplier pricing, negotiated rebates, open purchase orders and approval-chain identities — is carried out of those systems and into the vendor's environment as a matter of ordinary use ('Ordinary use of the service is enough to trigger it'). It is then retained for thirty days in Nimbus interaction logs 'accessible to Nimbus support staff on request', i.e. readable outright by a party Northwind never contracted with for data custody — matching the questionnaire's 'Full: sensitive data becomes readable by a party we never contracted with'. Northwind's data-classification policy has no category for tool-call parameters and results, so no compensating control narrows the loss. The rubric's 2.4/4.3 entries treat precisely this as the archetypal SC case, and ATLAS AML.T0086 (Exfiltration via AI Agent Tool Invocation, with realized/demonstrated case studies CS0037, CS0045, CS0054) shows a manipulated agent can be made to pull and exfiltrate arbitrary connector-reachable data. Because the same connectors serve finance and supply-chain agents, the readable surface is effectively the full procurement/contract data estate, not a subset — near-total loss on this axis.
    SI Downstream Blast-Radius Impact -- IntegrityHHagentCONFIRM H. This is the metric the dimension exists for. The agent does not merely advise — it 'raise[s] purchase requisitions' and 'check[s] contract compliance', i.e. it performs mutative, real-world action against Northwind's production ERP and contract-management systems. The rubric's 4.3 note states that 'real-world action taken outside the model itself is Subsequent System impact almost by definition', and the questionnaire records the corresponding outcome as 'Full: downstream systems act on altered outputs without detection'. Two independent integrity paths exist and both are vendor-side: (a) the connectors and the agent loop are supplied and executed by Nimbus, so altered tool definitions or poisoned runtime responses (ATLAS AML.T0110 Tool Poisoning, AML.T0010 Poisoned AI Agent Tools) change what gets written without Northwind observing it; (b) indirect prompt injection via supplier quotes and contract text escalates to tool invocation (AML.T0051.001/.002, AML.T0053; case studies CS0026, CS0039, CS0062), which is the excessive-agency pattern. Detection is weak: Nimbus discloses logging/retention changes only 'in release notes at the time they take effect', and falsified requisitions, rebate terms or approval-chain identities are financially consequential and hard to distinguish from legitimate buyer activity. Shared use of the same connectors by finance and supply-chain agents means corrupted writes propagate across many or all AI workloads. Total/near-total loss on this axis.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentCONFIRM L, and explicitly reject S. The questionnaire's downstream availability answer is 'Some downstream workloads degrade' — partial, not total — and at the dependency itself availability loss is 'None: we could keep operating this component', with exit assessed as 'moderate: a project, but no re-architecture'. The documented tool scope is read-oriented plus requisition creation; ATLAS AML.T0101 (Data Destruction via AI Agent Tool Invocation, the stated CASE anchor for 4.3, Realized maturity, cases CS0046/CS0047) establishes that mutative tool access can be turned to destructive availability impact, which is why this is not N — a compromised agent could flood or corrupt requisition and PO records enough to disrupt procurement throughput, and the shared connectors mean finance and supply-chain agents degrade with it. But nothing in the scenario grants the agent administrative, bulk-delete or infrastructure control over ERP, and the ERP and contract-management systems remain Northwind-operated and reachable without Nimbus, so core business availability is not destroyed. S is not warranted: this is consumer-goods procurement and contract compliance; no physical process, device or safety-relevant function is in the action path, and inferring physical harm from supply-chain slowdown would be speculative on this evidence. Partial/limited loss on this axis.
    E Precedent MaturityAPagent · overrideOverride P → A. The corpus's own mapping rule is explicit: 'ATLAS technique maturity and case-study type map onto CASE's E metric: Realized / Incident → E:A (Attacked), Demonstrated / Exercise → E:P ... A metric agent citing an ATLAS *Incident* case study has documentary grounds for E:A' (atlas/README.md), and that same file anchors dimension 4.3 to 'AI Agent Tool Invocation', 'Data Destruction via AI Agent Tool Invocation' and 'AI Agent Tool Poisoning'. For those exact anchors the corpus contains non-exercise Incidents, not merely research PoCs: AML.CS0047 'Code to Deploy Destructive AI Agent Discovered in Amazon Q VS Code Extension' (Incident, 2025-07-13) under AML.T0101 — a vendor-distributed agent tool environment carrying code to make an agent destroy data; AML.CS0053 'Poisoned Postmark MCP Server Email Exfiltration' (Incident, 2025-09-01) under AML.T0086; and AML.T0010 states plainly that 'Adversaries have successfully used a poisoned MCP server to exfiltrate private user data'. AML.T0017.002 'AI Agent Tools' (connectors, plugins, execution brokers, remote APIs) is rated 'Realized → E:A'. AML.T0051 further notes indirect prompt injections 'have been observed in the wild, with potential impact ranging from ... data exfiltration, and destructive actions'. Scenario fit: Northwind's connectors are vendor-supplied, vendor-run, hold standing credentials into production ERP and contract management, and the agent takes real-world action (raising requisitions) — precisely the configuration exercised in those incidents, and the same connector set is reused by finance and supply-chain agents, widening the attacked surface. I note the questionnaire answered 'demonstrated in research or incident reports, not confirmed against our stack'; under CVSS/CASE semantics E:A asks whether the control class has been exercised against comparable orgs in the wild, not whether Northwind's own stack was hit, so 'not confirmed against our stack' is compatible with A. Residual uncertainty (hence 0.7 rather than higher): the narrower sovereignty-flavoured variant of this dimension present in the scenario — Nimbus support staff reading 30-day tool-call parameter logs under routine terms — is documented mainly as disclosed vendor capability rather than as an observed exercised incident, so the A rests on the manipulation/excessive-agency precedent rather than the support-access precedent.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequenceNXagent · overrideQuestionnaire answered 'Unknown' (prior X); resolving to N on the evidence rather than leaving undefined. A compromise of the tool-execution environment at this dimension produces commercial and integrity harm first: rogue or altered purchase requisitions, manipulated supplier pricing and rebate data, and unauthorized reads of ERP state (ATLAS AML.T0086, AML.T0110). An agentic procurement assistant is not an Annex III high-risk use, so the EU AI Act Art. 12/Art. 26 logging, monitoring and serious-incident duties do not independently bite here. The GDPR Art. 28 / Art. 33 exposure in this scenario arises from the thirty-day retention of tool-call parameters containing approval-chain identities in Nimbus's logs accessible to support staff (vendor logs characteristically carry identifying fields - microsoft-eu-data-boundary), which is the logging/data-classification dimension's finding, not an independent trigger of the execution environment. Confidence is moderate: if exfiltrated ERP/contract content includes supplier and employee personal data, a breach-notification duty could follow, but that is derivative rather than independent.
    AU Silent/Automatic TriggerYNagent · overrideOVERRIDE of the prior N. The prior reflects the attacker's path to the primary dependency (a discrete prompt-injection or legal-process action aimed at Northwind). At this dimension the sovereignty-loss event is a change to a vendor-supplied, vendor-run connector and tool-execution layer: Nimbus owns the connector code, the tool definitions the model sees, and the capture of tool-call parameters into interaction logs. A platform-side change to connector behaviour, tool schemas or logging scope lands on every tenant at once with no case-by-case decision - the scenario confirms this delivery model ('Nimbus publishes changes to logging and retention in release notes at the time they take effect'). ATLAS AML.T0010/AML.T0110 note that the model-visible definition and runtime responses of a remotely hosted tool can be altered centrally and silently, changing how tools are invoked and introducing hidden side effects for all consumers. Within Northwind the same connectors are the shared substrate for procurement, finance and supply-chain agents, so one change propagates without any per-workload step.
    R Portability / Exit RecoveryUUagentCONFIRM. Not Irrecoverable: the systems of record (ERP, contract management) are Northwind's own and expose their own APIs, so the capability - an agent that reads quotes and raises requisitions - can be reconstituted on another runtime. Not Automatic: Nimbus supplies the connectors, so exit means rebuilding tool definitions, schemas, authentication and permission handling against a different execution broker and re-testing agent behaviour (the connector/integration surface described in ATLAS AML.T0017.002). That is manual migration and re-integration effort, exactly the questionnaire's 'Yes, with manual migration effort'.
    V Blast-Radius ConcentrationCCagentCONFIRM. The scenario states Nimbus is Northwind's standard agent runtime and that the same connectors are used by finance and supply-chain agents, so the tool-execution environment is a shared control plane sitting in the critical path of many or all AI workloads - the questionnaire's 'Many or all: shared control plane'. ATLAS AML.T0010 captures why this concentrates risk: compromising the agent/tool layer 'can provide them with broad access and permissions on the victim's system via the agent's other tools'. A single manipulation of the connector layer reaches procurement, finance and supply-chain simultaneously, and reaches live ERP state (pricing, rebates, open POs, approval-chain identities) rather than one narrow dataset.
    RE Exit / Mitigation EffortMMagentCONFIRM. Mitigation short of exit is available at configuration level and does not require re-architecture: ATLAS mitigations M0026 (privileged agent permission configuration), M0027/M0028 (permissions inherited from user or agent), M0029 (human-in-the-loop confirmation of agent actions - directly applicable to requisition raising) and M0030 (restrict tool invocation when untrusted data is present) can be applied to scope the blast radius of the existing connectors. Full exit is a project rather than trivial, because connectors must be rebuilt for a different runtime and the change touches three agent families (procurement, finance, supply chain) plus re-contracting - but the systems of record and network paths are unchanged, so no physical infrastructure replacement or re-architecture is implied. Moderate is the correct middle value; not L, because a contractual fix alone would not remove vendor-side execution of the tool calls.
    U Vendor Notice PostureAmberAmberagentCONFIRM. The scenario is explicit: 'Nimbus publishes changes to logging and retention in release notes at the time they take effect', matching the questionnaire's 'Disclosed at the time the change takes effect' and the rubric's Amber definition (discloses concurrently with the change taking effect). Not Green or Clear: there is no advance window and no contractually guaranteed notice period, so Northwind cannot assess a connector, logging or tool-definition change before it is already executing against its production ERP. Not Red: disclosure does occur and is published.
  5. 5 Which humans are actually looking at our stuff?

    5.3 Support / debugging access · also 5.1
    MEDIUM5.3

    Nimbus's documentation states plainly that its support staff can access Northwind's interaction logs on request, for abuse detection and debugging. Those logs contain thirty days of live supplier pricing, rebates, open purchase orders and approval-chain identities drawn from procurement, finance and supply chain. There is no customer approval step, no notification to Northwind when such access happens, and no record Northwind can inspect afterwards; the request is made and granted entirely inside the vendor. This is the most routinely used access route at enterprise cloud and AI vendors — it is how support works — and it is covered by a generic support clause rather than having ever been assessed by Northwind as an access path to sensitive commercial data.

    Rating MEDIUM. Named vendor employees Northwind has never vetted can read its live negotiating position whenever a support ticket gives them a reason, and Northwind would never know it happened.

    Evidence: vector, score and 21 metric rationales

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

    Ask the vendor Does a real person at your company, or a contractor of yours, ever read our conversations or our data? · If a conversation gets flagged, does it go somewhere else to be reviewed or labeled? · When your support engineers debug a problem for us, what can they see?

    MetricValuePriorSourceRationale
    AV Access PathNNagentConfirms prior. The interaction logs containing tool-call parameters and results (supplier pricing, rebates, open POs, approval-chain identities) are retained inside Nimbus's own platform, reached by Nimbus support staff directly with no intermediary party. The rubric defines N as 'vendor-direct API access, no intermediary' (sovereignty_cvss_rubric_1.json). Nothing in the scenario indicates a subprocessor mediates support access (which would be A), and the logs are emphatically not resident in a Northwind-managed environment (L/P) — they are a vendor-side artefact generated as a by-product of connector traffic.
    AC Compulsion ComplexityLLagentConfirms prior. Access is granted by the platform's own documented terms — logs are 'accessible to Nimbus support staff on request' — i.e. exactly the 'generic support access clause in vendor terms' pattern of dimension 5.3. There are no countervailing technical or contractual barriers: no customer-managed encryption keys over the log store, no residency carve-out, and Northwind's data-classification policy has no category for agent tool-call parameters/results, so the data is not even contractually flagged as sensitive. The EU AI Act framing of provider-held automatically generated logs (Art. 12, and provider duty to surface them on reasoned request) reinforces that provider-side log access is the default, unobstructed state rather than something that must be overcome. H would require a barrier that must first be defeated; none exists.
    AT Trigger ConditionsNNagentConfirms prior, with the caveat noted. The phrase 'on request' could be read as needing a debugging incident (which would argue for P), but the request is internal to Nimbus and wholly within the vendor's own control, which is the test for AT: P requires a condition outside the exercising party's control (sanctions designation, litigation hold, externally triggered incident). Here logging is on by default, retention runs continuously for thirty days, and one stated purpose — abuse detection — is an ongoing vendor-initiated activity requiring no Northwind event at all. The access right is therefore standing and discretionary (questionnaire: 'At its discretion, at any time'). Confidence is reduced because a reviewer could defensibly score P if Nimbus's support terms in fact gate log retrieval on an open customer ticket.
    PR Position RequiredLLagentConfirms prior. The parties named with log access are 'Nimbus support staff' — employees of the primary contracted vendor — which matches L, 'requires being the primary contracted vendor'. N would require that any party already in the subprocessor chain has standing; the scenario names no support subprocessor or outsourced tier-1 desk, so N is not evidenced (though it would be the correct value if Nimbus's support function were found to be outsourced or offshored, a common pattern worth verifying). H is clearly wrong: no compromise of Northwind's own admin credentials is needed — the access path runs entirely through Nimbus's internal support process.
    UI Org Action RequiredPPagentConfirms prior. Northwind takes no affirmative action to create this exposure: every ordinary buyer request ('compare these quotes', 'raise this requisition') causes the agent to call the ERP and contract-management connectors, and the live system state carried in those calls is written into Nimbus's interaction logs automatically. That is the rubric's P — 'routine, ordinary use of the service triggers the exposure'. A is excluded because no opt-in or update acceptance is involved; logging and 30-day retention are platform defaults. N was considered (Nimbus can unilaterally change logging and retention, publishing it in release notes only at the time the change takes effect) but N describes exposure arising from a unilateral vendor act with no org involvement, whereas the confidentiality loss here is produced by Northwind's own routine agent traffic. The release-note-at-effect disclosure practice is better reflected in the threat/supplemental metrics than in UI.
    VC Primary Dependency Impact -- ConfidentialityHHagentConfirms the prior and matches the rubric's designated primary impact axis for 5.3 (VC). Nimbus support staff can, on request alone, read 30 days of interaction logs that contain live tool-call parameters and results: supplier pricing, negotiated rebates, open purchase orders and approval-chain identities — effectively a rolling window onto Northwind's commercially sensitive procurement position across ERP and contract management. No compensating control narrows this: there is no customer approval gate, access-transparency log, pseudonymization or redaction of the kind Google Cloud Sovereign Controls and the Microsoft EU Data Boundary describe, and Northwind's classification policy has no category for tool-call data so nothing is marked for restriction. Because the same connectors serve finance and supply-chain agents, the readable set is near-total for the data flowing through this runtime, which is a total rather than partial loss on the confidentiality axis.
    VI Primary Dependency Impact -- IntegrityNLagent · overrideOverride of the questionnaire's L, which describes the primary dependency (the Nimbus runtime itself, whose behaviour/outputs the vendor could partially alter). This category's exposure is the support/debugging read path into retained logs. The rubric assigns 5.3 a primary impact axis of VC only and explicitly excludes subsequent impact, in contrast to dimensions where integrity is in scope (2.4, 5.2 list VI). The scenario grants support staff access to logs 'on request' for abuse detection and debugging; nothing in it describes support staff injecting into, replaying or modifying tool calls, agent configuration or returned results, so there is no evidenced loss of integrity attributable to this access path. Confidence is moderate rather than high because a debugging role could in principle be broader than documented — if Northwind learns that support access includes write/configuration capability, this should be revisited to L.
    VA Primary Dependency Impact -- AvailabilityNNagentConfirms the prior. Support staff reading retained interaction logs neither withdraws nor degrades the procurement assistant: the agent, connectors and ERP/contract systems keep operating unaffected, consistent with the questionnaire answer that the component could keep running. The rubric likewise treats 5.3 as a confidentiality-only dimension, with no availability axis.
    SC Downstream Blast-Radius Impact -- ConfidentialityLHagent · overrideOverride H → L. The questionnaire's 'full downstream confidentiality loss' answer describes the primary dependency (the connector / tool-call path, rubric dimension 2.4, where live ERP and contract state transits the platform). For dimension 5.3 the access path being scored is Nimbus support staff reading retained interaction logs on request. There IS a genuine downstream confidentiality component: the logs contain third-party data — supplier quotes, negotiated rebates and approval-chain identities — so parties that never contracted with Nimbus (Northwind's suppliers, and the identities of its approvers) have their confidential commercial terms exposed, and the same connectors are shared by finance and supply-chain agents, widening whose data lands in the log store. But the loss is partial rather than total: support access reaches only the 30-day rolling window of tool-call parameters and results that happened to transit the agent, not the ERP or contract-management systems themselves, and it is read-only retrospective access rather than a live query capability. The rubric classifies 5.3 as 'subsequent_impact_relevant: false' (sovereignty_cvss_rubric_1.json), which argues against H; Google's sovereign-controls material likewise treats technical support access as a bounded, justification-and-logging-constrained path rather than general data access — a control Northwind has no evidence of here, which is why the value is L rather than N.
    SI Downstream Blast-Radius Impact -- IntegrityNHagent · overrideOverride H → N. The prior ('downstream systems act on altered outputs without detection') is a property of the tool-calling/orchestration path, not of support/debugging access. Nothing in the scenario gives Nimbus support staff a write path: the documented capability is that interaction logs are 'accessible to Nimbus support staff on request' for abuse detection and debugging. Reading a retained log cannot alter supplier comparisons, requisitions already raised in the ERP, or contract-compliance decisions downstream. The rubric assigns 5.3 primary impact axis VC only and marks subsequent impact not relevant, consistent with a read/observe capability rather than an alter capability. An indirect integrity path (leaked approval-chain identities enabling later fraud against the ERP) is speculative and not described in the scenario, so it does not support even an L here; confidence is reduced accordingly rather than the value raised.
    SA Downstream Blast-Radius Impact -- AvailabilityNLagent · overrideOverride L → N. Support/debugging access to retained logs withdraws or degrades nothing: the questionnaire itself records that no capability is lost at the dependency ('None: we could keep operating this component'), and log inspection by vendor staff does not stop the ERP, contract-management systems or the finance and supply-chain agents from functioning. The 'some downstream workloads degrade' answer relates to concentration of the shared Nimbus runtime/connectors (a platform-withdrawal scenario, i.e. category 6/7 dimensions), not to the support-access path that carries 5.3. S is not applicable: the workload is procurement decision support — no physical process, no safety-relevant actuation — so no availability loss here could cause physical harm.
    E Precedent MaturityAPagent · overrideOverride of the questionnaire's 'P'. For dimension 5.3 the control in question is vendor support/engineering staff reading interaction logs and traces to debug a customer issue — and that is not a theoretical or research-only path, it is routine documented operational practice at major enterprise AI/cloud vendors. Google Cloud's sovereign-controls documentation exists precisely because administrative and technical-support access to customer data happens often enough to need per-request justifications, Access Transparency logging and Access Approval gating ('Technical support access is limited by underlying data access controls...'; 'Administrative access to customer data and workloads is logged, audited, and permitted only under predefined conditions') — controls that are only meaningful because comparable enterprise customers see such accesses occur against their tenants (s3://.../google-cloud-sovereign-controls.md). Microsoft's EU Data Boundary documentation likewise confirms that provider-side system-generated logs capture user-initiated interaction events, contain identifying fields, and are processed by the provider for operational problem detection, policy violation and fraud investigation — i.e. accessed by vendor personnel in the normal course (s3://.../microsoft-eu-data-boundary.md). The rubric's own characterisation of 5.3 treats support/debugging access as 'one of the most common real access paths', covered by generic support clauses and almost never assessed (s3://.../sovereignty_cvss_rubric_1.json, item 5.3). Northwind's situation matches that pattern exactly: Nimbus documents 30-day retention of tool-call parameters and results (supplier pricing, rebates, open POs, approval-chain identities) 'accessible to Nimbus support staff on request', with no customer approval gate, no access-transparency commitment, and no data-classification category covering this data — so the access needs only ordinary use of the service plus a support ticket. The residual uncertainty (hence confidence 0.62 rather than higher) is that the corpus documents the general practice and the control surface at comparable vendors, not a named incident of Nimbus support staff reading Northwind's procurement traces; if the assessor requires org-stack-specific confirmation, 'P' would be defensible, but the prior understates a control that is exercised as designed, routinely, against comparable organisations.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequenceNXagent · overrideOverride of the 'Unknown' prior to Negligible. The tool-call payloads visible to Nimbus support are predominantly commercial-confidential (supplier pricing, negotiated rebates, open POs) rather than regulated personal data; the only personal element is 'approval-chain identities', i.e. business-role identifiers of Northwind staff. Crucially, the retention and the support-access path are *disclosed in platform documentation* and exercised 'per standard terms of service', so they sit inside the processor instruction/DPA envelope rather than breaching it — support access of this kind is treated in vendor sovereignty documentation as a governed, logged operational function (Google: support access 'limited by underlying data access controls and routed to persons meeting specific criteria'; Microsoft: logs pseudonymized, minimum retention, 'usage solely for purposes related to service operations'), not as an unlawful disclosure per se. The procurement assistant is also not an Annex III high-risk use, so no EU AI Act Title III logging/record obligation is independently triggered. Residual GDPR Art. 28(3)/32 exposure exists if access exceeds documented instructions or is unlogged, but nothing in the scenario establishes that, so the metric does not reach Present. Confidence held at moderate because Northwind's own classification gap means it cannot evidence what categories of data actually land in the logs.
    AU Silent/Automatic TriggerNNagentConfirmed. At dimension 5.3 the sovereignty-loss event is a human support engineer reading Northwind's interaction logs, which the scenario states happens 'on request' — a discrete, per-ticket, per-customer action, matching the questionnaire's 'requires a discrete action against us specifically'. Vendor sovereignty controls describe exactly this granularity: every support/administrative access request carries an individual justification and is logged and approved case-by-case. Noted counter-pressure that the *log capture and 30-day retention* underlying the access is automatic and platform-wide for all Nimbus customers, and that a retention/logging policy change would take effect for everyone at once; that automatic-capture aspect is scored at the Data Derivatives dimensions (3.5 carries AU as its hook), not at 5.3, where the access decision itself is the event.
    R Portability / Exit RecoveryUUagentConfirmed as User (manual migration effort). Nimbus is Northwind's standard agent runtime and supplies the ERP and contract-management connectors, so exiting to remove vendor support-staff visibility into tool-call logs means rebuilding connectors, re-integrating the procurement/finance/supply-chain agents and re-contracting — substantial manual work, but the capability is reconstitutable: the authoritative data stays in Northwind's own ERP and CMS, and nothing is custodially locked in the vendor (no vendor-held weights or irreplaceable derived store at this dimension). Not Irrecoverable. Caveat for the reviewer: R scores reconstitution of the *capability*; the confidentiality already disclosed to support staff during the 30-day window is of course not recoverable by any exit, and that is reflected in the VC impact axis rather than here.
    V Blast-Radius ConcentrationCCagentConfirmed Concentrated. The scenario states Nimbus 'is Northwind's standard agent runtime and the same connectors are used by finance and supply-chain agents', so a single support-access path reaches the interaction logs of many/all of Northwind's AI workloads — the shared-control-plane pattern the rubric gives as the canonical Concentrated example. The rubric's note on telemetry/interaction logs is directly on point: such logs are 'diffuse per-event, concentrated in aggregate', and a 30-day rolling window of tool-call parameters and results across procurement, finance and supply chain is precisely the aggregate case. A support engineer granted log access is not scoped to one narrow workload.
    RE Exit / Mitigation EffortMMagentConfirmed Moderate. Mitigation does not require re-architecture or new infrastructure: the remedies for support/debugging access are productised and contractual — access-transparency/access-approval style controls with per-request justification and programmatic blocking, support routing restricted to qualified personnel, log pseudonymization, and minimum-necessary retention are all offered as vendor tiers or DPA/addendum terms. But it is also not trivially Low: Northwind must re-contract for those controls, extend its data-classification policy to cover data that 'exists only as parameters and results of an agent's tool calls' (a category it currently lacks), and likely add redaction/minimisation at the connector layer so sensitive rebate and approval-identity fields never enter the logged payload. That is a project across procurement, legal and platform engineering — Moderate.
    U Vendor Notice PostureAmberAmberagentConfirmed Amber, directly on the scenario text: 'Nimbus publishes changes to logging and retention in release notes at the time they take effect' — disclosure concurrent with the change, which is the rubric's definition of Amber. This is the sovereignty-relevant change class for this dimension (retention window, log scope, who may access), so the posture is assessed on exactly the right notice channel. Not Green or Clear: there is no advance window and no contractual guarantee of one, whereas third-party risk guidance treats advance notification of significant operational and subcontractor changes as a provision the customer must secure contractually. Not Red, because disclosure does occur and is published rather than withheld.
  6. 6 Who's holding the steering wheel?

    6.1 Centralized control plane / admin console · also 6.4
    HIGH8.3

    Nimbus is Northwind's standard agent runtime, and the settings that matter — what is logged, how long it is kept, who may read it, what the connectors are allowed to do and what guardrails apply — are held and changed on the vendor's side. Northwind learns of those changes through release notes issued at the moment they take effect, so it has no opportunity to assess or reject them. Because the procurement, finance and supply-chain agents all sit on the same runtime and the same connectors, a single change or a single compromise at that level reaches every AI workload Northwind runs rather than one. Attacks against the administrative layer of comparable enterprise AI platforms, including checking whether prompt logging was switched on and abusing guardrail settings, have already happened to real customers.

    Rating HIGH. One set of controls Northwind does not hold governs every AI workload it runs, and a change or compromise there is a company-wide event rather than a procurement one.

    Evidence: vector, score and 21 metric rationales

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

    Ask the vendor Where does the screen we'd use to configure or turn off this AI feature actually live? · Is our employee login system, or our credentials to other systems, now tied into a system this vendor controls? · Can settings change on us without anyone telling us?

    MetricValuePriorSourceRationale
    AV Access PathNNagentConfirms the prior. Nimbus Agents is an enterprise platform run in the vendor's own cloud and reached directly over its API; Northwind's agents, connectors and the interaction-log store all live vendor-side with no intermediary. The rubric defines AV:N as 'Network -- vendor-direct API access, no intermediary', and lists AV as the primary exploitability metric for 6.1 (centralized control plane / admin console). Nothing in the scenario indicates a customer-managed or air-gapped deployment of the runtime or its administrative surface.
    AC Compulsion ComplexityLLagentConfirms the prior. The control-plane exposures described are exercised under the platform's own published terms: logs are retained for thirty days 'per the platform's documentation' and are 'accessible to Nimbus support staff on request', and logging/retention policy is changed by the vendor via release notes. No customer-managed keys, data-residency carve-out or other technical/contractual barrier is described that a vendor or legal authority would have to overcome first, which is what the rubric requires for AC:H. Comparable vendor log-handling regimes (Microsoft EU Data Boundary) likewise treat operational log access as governed by standard service terms and internal policy rather than customer-held controls.
    AT Trigger ConditionsNNagentConfirms the prior. Support access to interaction logs is available 'on request' with no stated triggering event, and the vendor changes logging and retention policy at its own discretion, publishing the change in release notes only at the moment it takes effect. That matches AT:N, 'control can be exercised at vendor discretion at any time'; no sanctions designation, litigation hold or incident is a precondition. The questionnaire's note that a loss event 'requires a discrete action against us specifically' speaks to scope of a multi-tenant event, not to any trigger condition, so it does not push this to AT:P.
    PR Position RequiredLLagentConfirms the prior. The control plane and its administrative surface are operated by the primary contracted vendor: Nimbus provides the runtime, the connectors and the log store, and it is Nimbus support staff who can read interaction logs. No subprocessor is named in the scenario that would already hold sufficient standing (which would warrant PR:N), and the exposure does not depend on compromising Northwind's own administrative credentials (PR:H) — the vendor holds the privileged position by construction. Moderate confidence because, as the classifier notes, the scenario does not describe the console itself or its subprocessor chain.
    UI Org Action RequiredNPagent · overrideOverrides the prior of P. The questionnaire's 'ordinary use is enough' answer describes the primary data-in-tool-calls dependency, but this category's own exposure is the control plane: Northwind 'publishes changes to logging and retention in release notes at the time they take effect', i.e. retention windows, guardrail configuration and support-access policy are set and altered vendor-side with no affirmative act by Northwind and no prior notice. The rubric defines UI:N as the vendor/subprocessor acting unilaterally, expressly including a 'ToS change', which is the lower requirement and therefore governs where unilateral action is possible. ATLAS AML.T0081 documents that modifying or disabling control-plane configuration (security settings, approval requirements, oversight) is a recognised technique whose effect persists across every workload on the runtime — here finance and supply-chain agents as well as procurement — without the customer doing anything. Moderate confidence: ordinary use is also sufficient to expose tool-call data, so P is a defensible reading, but the unilateral vendor-side change path dominates for 6.1/6.4.
    VC Primary Dependency Impact -- ConfidentialityLHagent · overrideOVERRIDE H -> L. The prior's 'full read of sensitive data' describes the primary dependency as a data/log surface (tool-call parameters, ERP state in Nimbus interaction logs readable by support staff) — that belongs to the data-layer/support-access primary and, for this category, to the subsequent scope. Assessing 6.1's own exposure: the rubric gives 6.1 an empty primary_impact_axis and calls it 'pure Subsequent scope', so the heavy confidentiality loss is scored downstream, not on the console. A non-zero partial loss remains at the plane itself because the control plane holds the connector configuration, guardrail/access policy and retention settings, and (per AML.CS0048) consoles typically also hold credentials and conversation metadata that are readable by the operator — limited rather than total loss of the control plane's own secrets. The scenario does not describe the console directly, hence moderate confidence.
    VI Primary Dependency Impact -- IntegrityLLagentCONFIRM L. Nimbus can change logging, retention and policy configuration at its discretion under standing contractual right, with notice only in release notes at the time the change takes effect — so the control plane's own behaviour can be altered without Northwind's prior knowledge. This matches ATLAS AML.T0081, where configuration changes to a shared agent runtime affect every agent sharing that configuration. The alteration is partial and ultimately detectable (release notes are published, and the questionnaire records 'limited or detectable alteration'), not a total loss of integrity of the plane, so L rather than H. The undetected full-integrity effect reported in the questionnaire ('downstream systems act on altered outputs without detection') is a subsequent-scope effect and is not scored here.
    VA Primary Dependency Impact -- AvailabilityNNagentCONFIRM N. The questionnaire states the capability cannot be withdrawn or degraded at this dependency ('None: we could keep operating this component'), the loss event requires a discrete action against Northwind specifically rather than a fleet-wide shutdown, and the capability is reconstitutable with manual migration effort. The rubric assigns 6.1 no primary impact axis and routes console outage effects to the subsequent scope ('a console compromise or outage affects every downstream AI workload'), which is where the reported 'some downstream workloads degrade' belongs. No availability loss is therefore recorded at the control plane as the vulnerable system.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentConfirmed. Rubric dimension 6.1 states a control-plane compromise 'affects every downstream AI workload the org runs -- pure Subsequent scope', and the scenario matches it: Nimbus is Northwind's standard agent runtime and the *same connectors* serve the procurement, finance and supply-chain agents. Every tool call carries live ERP/contract state (supplier pricing, negotiated rebates, open POs, approval-chain identities), and this content is retained vendor-side for 30 days and is 'accessible to Nimbus support staff on request'. Because retention and access policy is set and changed vendor-side with notice only in release notes at the time of effect (6.4 as material secondary), the readable corpus can be widened to parties Northwind never contracted with, consistent with the questionnaire's 'Full: sensitive data becomes readable by a party we never contracted with'. Northwind's data-classification policy has no category for tool-call parameters/results, so no compensating detective or scoping control exists. ATLAS documents the exfiltration pathway at the agent/tool layer (AML.T0085.001, AML.T0086; case AML.CS0039). Near-total loss across the shared workload estate -> H.
    SI Downstream Blast-Radius Impact -- IntegrityHHagentConfirmed. The control plane is where connector definitions, guardrail configuration and access policy live, and changes there propagate silently to every agent built on the runtime. The procurement agent does not merely read: it raises purchase requisitions through the ERP connector, so altered agent behaviour becomes altered state in systems of record, and the same connectors carry that effect into finance and supply-chain agents. ATLAS treats exactly this as a high-propagation integrity vector: Modify AI Agent Configuration (AML.T0081), AI Agent Tool Poisoning (AML.T0110 - definition/instruction, implementation and runtime-response poisoning, which can 'alter the inputs or destinations of other tools' and 'conceal actions from users'), and the realized postmark-mcp rug-pull case (AML.CS0053) where a vendor-side version change silently changed tool behaviour for all adopters. Detection is weak here: changes are disclosed only at the time they take effect, and tool-call data falls outside Northwind's classification/monitoring scope, supporting the questionnaire's 'downstream systems act on altered outputs without detection' -> H.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentConfirmed as L (partial), not raised to H. A Nimbus outage would stop the agentic layer for many or all workloads, which is the strongest argument for H under 6.1/6.3 ('a gateway outage takes down access to the underlying service -- Subsequent Availability'). But the downstream systems of record - ERP and contract management - are Northwind's own and keep running; buyers can compare quotes and raise requisitions manually, and the questionnaire reports availability loss at the dependency itself as 'None: we could keep operating this component' with downstream effect limited to 'some downstream workloads degrade'. Exit is a moderate project (manual re-integration/re-contracting), not an unrecoverable loss. S (Safety) is rejected: the affected processes are procurement, finance and supply-chain decision support with human requisition/approval chains; the scenario describes no physical-process control or safety-relevant failure mode, so no plausible path to physical harm. Confidence is moderate because the scenario does not describe the console or its resilience/SLA posture directly.
    E Precedent MaturityAPagent · overrideOverride of the questionnaire prior (P) for this category. The prior was answered about the primary dependency (vendor-side log access / retention change at Nimbus), where the respondent saw only research-and-report-level precedent. For dimension 6.1 the question is whether control over a *centralized AI control plane* shared by many workloads has actually been exercised against comparable organizations, and the corpus contains ATLAS case studies typed as real-world *Incidents*, not exercises: AML.CS0030 'LLM Jacking' (Incident, 2024-05-06, explicitly rendered as 'Type: Incident -> CASE Precedent Maturity E:A'), in which actors used valid credentials to reach cloud-hosted LLM control planes at enterprise customers, enumerated which models were enabled, queried GetModelInvocationLoggingConfiguration to see whether prompt logging was on, and resold access -- i.e. control-plane-level reach that touches every workload behind that platform account; and AML.CS0057 'Storm-2139 Azure OpenAI Guardrail Bypass' (Incident, 2024-12-01), an enterprise AI platform whose guardrail/configuration controls were abused across multiple customers. ATLAS corpus README states the mapping rule directly: 'Realized / Incident -> E:A (Attacked) ... A metric agent citing an ATLAS *Incident* case study has documentary grounds for E:A.' Northwind is a comparable org: Nimbus is a major-vendor enterprise AI platform running in the vendor's cloud, reached over its API, and is Northwind's standard agent runtime shared by procurement, finance and supply-chain agents -- exactly the concentrated control-plane profile (rubric 6.1: 'A console compromise or outage affects every downstream AI workload the org runs'). Confidence is held at moderate rather than high because the scenario does not describe Nimbus's admin console, its tenancy model or its support-access controls, and no incident is documented against Northwind's own stack; the published precedent concerns comparable platforms (Bedrock/Azure OpenAI-class services) rather than Nimbus itself. Related configuration-change precedent (AML.T0081 Modify AI Agent Configuration, the ATLAS anchor for the material secondary dimension 6.4) is only 'Exercise'-grade, which supports P on its own; the E:A finding rests on the control-plane incidents above.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequenceNXagent · overrideThe questionnaire answered 'Unknown', so no prior is carried. Assessed for this category: dimension 6.1 concerns concentration of the shared runtime/console, and a compromise or outage there is in the first instance an availability/integrity event across workloads rather than an independently reportable regulatory violation. The workload (procurement quote comparison, contract compliance, requisition raising) is not an Annex III high-risk use under the EU AI Act, and the Act's provider/deployer reporting duties attach to high-risk systems and GPAI providers, not to a deployer's control-plane concentration (EU AI Act, logging and corrective-action/duty-of-information provisions). The data in flight is predominantly commercial (supplier pricing, rebates, POs) with only incidental personal data (approval-chain identities), so the GDPR Art. 28/33 hook sits with the data-derivative and vendor-support-access dimensions rather than with 6.1 itself. Rated N with low-moderate confidence because the scenario does not describe the console or its tenancy at all.
    AU Silent/Automatic TriggerYNagent · overrideOverride of the questionnaire's N. The prior ('requires a discrete action against us specifically') describes the primary dependency — targeted support-staff retrieval of a specific tenant's interaction logs. For the control plane, the material secondary identified by the classifier (6.4: logging/retention policy set and changed vendor-side) is a platform-wide setting: 'Nimbus publishes changes to logging and retention in release notes at the time they take effect.' A release-note change to what the shared runtime logs, how long it retains it, or who may read it lands on every tenant simultaneously with no per-customer decision, which is exactly the rubric's AU=Y condition ('can occur simultaneously across all customers with no case-by-case decision'). Because Nimbus is Northwind's standard runtime, one such change propagates to the procurement, finance and supply-chain agents at once.
    R Portability / Exit RecoveryUUagentConfirmed. Northwind could reconstitute an agent runtime elsewhere, but it would have to rebuild the Nimbus-provided ERP and contract-management connectors, re-wire approval-chain identity handling and re-onboard multiple agent families — the questionnaire's own answer ('Yes, with manual migration effort: re-embedding, re-integration, re-contracting'). No vendor-held artefact (model weights, irreplaceable store) makes the capability unrecoverable, so not I; and nothing is automatic, so not A.
    V Blast-Radius ConcentrationCCagentConfirmed, and this is the metric that carries the category. The rubric names V (Concentrated) as the supplemental hook for 6.1 and notes that 'a console compromise or outage affects every downstream AI workload the org runs -- pure Subsequent scope'. The scenario matches literally: Nimbus is Northwind's standard agent runtime and 'the same connectors are used by finance and supply-chain agents', and the questionnaire reports 'many or all' workloads depending on the component. The shared runtime plus shared connectors sit in the critical path of multiple business-critical agent fleets.
    RE Exit / Mitigation EffortHMagent · overrideOverride of the questionnaire's M. The prior ('a project, but no re-architecture') is a reasonable estimate for the primary exposure — curbing tool-call logging on one procurement agent. Reducing the 6.1 exposure is a different undertaking: because Nimbus is the organisation-wide standard runtime with vendor-supplied connectors shared by finance and supply-chain agents, mitigation means either standing up a second, independent runtime path for critical workloads (re-architecture of the agent layer and all ERP/contract-system integrations) or obtaining contractual control over platform-wide logging/retention and console access (re-contracting). The rubric puts both 're-architecture' and 're-contracting' in the H band. Confidence is moderate because the scenario does not state how coupled Northwind's agents are to Nimbus-specific connector semantics.
    U Vendor Notice PostureAmberAmberagentConfirmed directly from the scenario text: 'Nimbus publishes changes to logging and retention in release notes at the time they take effect', i.e. disclosure concurrent with effect — the rubric's Amber. Not Green or Clear, since there is no advance window and no contractual notice guarantee; not Red, since changes are in fact published. This is the notice posture that makes the vendor-side 6.4 logging/retention control effectively unreviewable before it bites across all workloads.
  7. 7 How many companies are really in this chain: and did we agree to it?

    7.1 Downstream subprocessors · also 7.3
    MEDIUM5.8

    Nimbus is described as an enterprise platform from a major vendor, which means there is almost certainly a chain beneath it — a model provider, cloud infrastructure and whatever stores the thirty-day interaction logs — but that chain is not disclosed to Northwind. The content flowing into it is not summaries; it is full supplier pricing, rebates, open purchase orders and approver identities, including personal data about Northwind staff. Northwind therefore cannot name the parties handling that data, cannot show that appropriate terms flow down to them, and cannot evidence that the processing is covered by its own records. Nimbus can substitute or add parties beneath it as a platform-wide decision, and Northwind would learn of it the same way it learns of logging changes: in a release note, after the fact. The only access actually evidenced in the scenario is Nimbus's own, which keeps this finding moderate rather than severe.

    Rating MEDIUM. Northwind cannot answer the basic question of which companies hold its procurement data, which is an exposure in its own right if a regulator or a supplier asks.

    Evidence: vector, score and 21 metric rationales

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

    Ask the vendor List every company standing between us and the raw computer running this AI. How long is that list, really? · Did we ever affirmatively choose to adopt AI here, or did it just arrive?

    MetricValuePriorSourceRationale
    AV Access PathANagent · overrideOVERRIDE of prior N. The prior correctly describes the *primary* dependency: Northwind reaches Nimbus directly over its API. But dimension 7.1 asks about downstream subprocessors, and for that path the exposure is not vendor-direct: tool-call state lands in Nimbus's interaction logs, and whatever model provider, cloud infrastructure or log-storage service sits beneath Nimbus reaches that data only *through* Nimbus, as an intermediary. The rubric defines A as 'Adjacent -- subprocessor-mediated access', which is definitionally this dimension (sovereignty_cvss_rubric_1.json). ATLAS AML.T0010 and EU AI Act recitals 88-89 confirm that such intermediated layers normally exist beneath a platform provider even when unnamed. Confidence is moderate because the chain is implied rather than disclosed in the scenario.
    AC Compulsion ComplexityLLagentCONFIRM. No barrier has to be overcome for data to reach the layer beneath Nimbus: retention of tool-call parameters and results for 30 days and support-staff access 'on request' are features of the platform's own published documentation and standard terms. The scenario describes no customer-managed keys, no data-residency carve-out and no contractual restriction on onward processing; Northwind's data-classification policy does not even cover this data class, so no compensating control exists. Rubric L = 'a standard ToS clause or routine legal process suffices'.
    AT Trigger ConditionsNNagentCONFIRM. No triggering event is needed: logging is continuous and automatic for every tool call, and support access is available 'on request' rather than on incident. Nimbus also publishes changes to logging and retention in release notes at the time they take effect, i.e. it can alter the downstream handling of this data at its own discretion with no advance condition. Rubric N = 'control can be exercised at vendor discretion at any time'.
    PR Position RequiredLLagentCONFIRM. The only access actually evidenced in the scenario is by Nimbus itself ('accessible to Nimbus support staff on request'), and the questionnaire states only the primary contracted vendor can exercise this control. Choosing N ('any party already in the subprocessor chain has sufficient standing') would require evidence of a named downstream party with independent standing over the log store, which the scenario does not provide; the chain beneath Nimbus is undisclosed and therefore only inferred. Rubric L = 'requires being the primary contracted vendor'. Kept deliberately at L so this remains the low-severity, low-confidence 7.1 finding it is.
    UI Org Action RequiredPPagentCONFIRM. Northwind takes no affirmative step to create this exposure and none is needed: every ordinary buyer request causes the agent to call ERP and contract-management connectors, and the live system state in those calls is written to Nimbus's 30-day interaction logs by default. Routine use of the service alone propagates the data into the undisclosed chain beneath Nimbus. N was considered (the vendor can unilaterally change logging/retention via release notes effective immediately), but the dominant mechanism for this dimension is passive, use-driven data flow, so P is the better fit per the rubric.
    VC Primary Dependency Impact -- ConfidentialityLHagent · overrideOVERRIDE H -> L. The H prior describes the primary contracted vendor's own read access to tool-call logs (the Category 2.4 / Category 5 finding), not the 7.1 subprocessor concern. The rubric gives dimension 7.1 an empty 'primary_impact_axis' and notes it 'is definitionally what the Subsequent System Impact metric group was built to express', with scoring as MAX(primary, subsequent) - so the compounding chain exposure belongs in SC, and re-asserting H here would double-count the same access. What the undisclosed chain adds *at the Nimbus layer itself* is genuine but partial: the 30-day interaction log of live ERP/contract tool-call parameters and results must rest on some underlying storage, hosting and support tooling that Northwind cannot name. Against that, the questionnaire states only the primary contracted vendor is in a position to exercise the control, and the scenario describes Nimbus only as 'an enterprise AI platform from a major vendor' with no disclosed subprocessors - so the sub-chain's contribution to confidentiality loss at this dependency is limited and inferential, not total. L.
    VI Primary Dependency Impact -- IntegrityLLagentCONFIRM L. An undisclosed sub-layer (model provider, connector implementation, platform components) can shift the agent's behaviour beneath Northwind's visibility, and Nimbus notifies of logging/retention changes only in release notes 'at the time they take effect', so a change is disclosed concurrently rather than reviewably in advance. MITRE ATLAS AML.T0010 (AI Supply Chain Compromise, platforms include Agentic AI, maturity Realized) and case study AML.CS0053 (postmark-mcp rug pull: a legitimate agent tool later replaced by a malicious version) show this alteration class is demonstrated in incident reports - consistent with the questionnaire's 'demonstrated in research or incident reports, not confirmed against our stack'. But nothing in the scenario evidences actual alteration through a subprocessor, and buyers see the agent's comparisons and requisitions before approval, so alteration at this dependency would be limited or detectable rather than total. L, not H.
    VA Primary Dependency Impact -- AvailabilityNNagentCONFIRM N. No disclosed party in the chain beneath Nimbus holds a right to withdraw or degrade the runtime, and the questionnaire answers directly: at this dependency 'None: we could keep operating this component'. The availability harm the organization does report - 'some downstream workloads degrade' - is by definition subsequent-system impact (the finance and supply-chain agents sharing the same connectors) and is captured in SA, not VA; the rubric's MAX(primary, subsequent) construction means recording it here would misattribute it. No corpus source indicates a subprocessor-driven withdrawal right for this scenario, so N on the primary axis.
    SC Downstream Blast-Radius Impact -- ConfidentialityHHagentConfirmed H. For dimension 7.1 the 'subsequent systems' are the parties beneath Nimbus that Northwind never contracted with: the inference/model provider, the cloud infrastructure and whatever stores the 30-day interaction logs. The rubric treats 7.1 as having no primary exploitability or primary impact axis at all ('primary_impact_axis': [], 'subsequent_impact_relevant': true, note: 'definitionally what the Subsequent System Impact metric group was built to express'), so the whole exposure of this dimension lands on SC/SI/SA. What flows into that undisclosed chain is not summaries but full-fidelity tool-call parameters and results: supplier pricing, negotiated rebates, open purchase orders and approval-chain identities, i.e. Northwind's and its suppliers' commercial secrets. Rubric dimension 2.4 flags exactly this content class as the cleanest SC/SI case; 3.5 notes telemetry/usage logs concentrate value in aggregate. Thirty days of retained logs accessible to vendor support staff on request implies at least a log-storage and support-tooling layer handling the same content, and Microsoft's EU Data Boundary paper confirms that system-generated interaction logs necessarily carry the content of transactions and are handled under vendor-internal, not customer, control. Loss on the confidentiality axis at those uncontracted parties is therefore total for the data in scope -> H. Confidence is moderate rather than high because the chain beneath Nimbus is only implied by 'an enterprise AI platform from a major vendor' and is undisclosed, so the identity and number of subprocessors cannot be verified from the scenario.
    SI Downstream Blast-Radius Impact -- IntegrityLHagent · overrideOverride H -> L for this category. The questionnaire's 'full, undetected downstream alteration' answer describes the primary contracted dependency, and it also states that only the primary vendor Northwind contracts with holds a standing right to change the service. Assessed on its own, the 7.1 integrity vector is narrower: an un-notified change deeper in the chain (a model-version or connector-build substitution by the underlying model provider or a poisoned component -- MITRE ATLAS AML.T0010 'AI Supply Chain Compromise' / AML.T0109 rug pull, both rated Realized/Demonstrated) propagating into agent outputs that the ERP then acts on. That effect is real but partial and partly detectable: the agent's write path is purchase requisitions that traverse ERP approval chains and buyer review of quote comparisons, Nimbus does publish logging/retention changes in release notes (late, but published), and no subprocessor in the chain has a disclosed contractual right to alter behaviour. The rubric also rates 7.1 at gap_severity 'Medium' with partial coverage by general TPRM practice, below the High-severity 7.2 silent-AI-addition case -- Northwind knowingly procured an agent platform. 'Partial or limited loss' therefore fits better than near-total loss. A reviewer who learned that the inference model provider is a distinct undisclosed subprocessor could reasonably restore H; note that scoring takes MAX over primary and subsequent impact, so SC=H already carries this group.
    SA Downstream Blast-Radius Impact -- AvailabilityLLagentConfirmed L. Nimbus is Northwind's standard agent runtime and the same connectors serve finance and supply-chain agents, so an outage in an undisclosed layer beneath it (model endpoint, cloud region, gateway -- the rubric's 6.3 'gateway outage takes down access to the underlying service' pattern) degrades several downstream agent workloads at once, matching the questionnaire's 'some downstream workloads degrade'. It is not total: procurement, contract compliance and requisition raising are pre-existing business processes that can be run manually in the ERP and contract-management systems, which Northwind controls, and the questionnaire records that the component itself could keep operating. S is not warranted -- the blast radius is commercial procurement data and purchasing workflow, with no physical process, safety-relevant actuation or human-safety pathway anywhere in the described chain.
    E Precedent MaturityPPagentConfirming the questionnaire prior P for this category, though on category-7.1-specific grounds rather than the primary-dependency grounds the questionnaire used. The 7.1 concern here is the undisclosed chain beneath Nimbus (model provider, cloud infrastructure, the store holding the 30-day interaction logs that contain supplier pricing, rebates, open POs and approval-chain identities). Precedent for sovereignty-relevant exposure propagating through an AI vendor's subprocessor chain exists at research / incident-report level but not as a confirmed exercise against Northwind's own stack: the CASE rubric itself records 7.1 as covered only by 'General TPRM practice (partial)' with no AI-specific standard (sovereignty_cvss_rubric_1.json, dimension 7.1), and the available documented precedents in the corpus are either demonstrations/exercises (ATLAS AML.CS0041, type Exercise -> E:P, supply-chain injection reaching downstream users of an AI assistant) or adversarial supply-chain compromise anchored to dimension 7.4 rather than to subprocessor data access (AML.T0010, Realized). Vendor-side log handling by subprocessors is documented in vendor disclosures (Microsoft EU Data Boundary describes system-generated interaction logs containing identifiable fields and the processing chain around them), which establishes the mechanism is real and reported, not merely hypothetical - so U would understate it. Equally, nothing in the scenario or corpus shows a Nimbus subprocessor actually reading a customer's agent tool-call logs, and the scenario gives no subprocessor identities at all, so A is unsupported. Confidence is moderate rather than high because, as the classifier notes, supply-chain exposure in this scenario is implied rather than disclosed: only the primary contracted vendor is stated to be able to exercise the control, and the precedent evidence is generic to AI platform supply chains rather than specific to Nimbus's chain.
    CR Confidentiality Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    IR Integrity Criticality (org context)HHquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    AR Availability Criticality (org context)MMquestionnaireOrganization-profile answer (ADR-0005 §5 rule 1); never agent-assigned.
    S Regulatory ConsequencePXagent · overrideOverride of the questionnaire's 'Unknown'. Nimbus's interaction logs retain tool-call parameters and results for 30 days, and those payloads include approval-chain identities — i.e. personal data. The Microsoft EU Data Boundary source establishes the general principle that logs generated by user interaction with a cloud service necessarily contain fields that identify specific persons and therefore constitute personal data. For dimension 7.1 the chain beneath Nimbus (model provider, cloud infrastructure, log storage) is undisclosed, so Northwind cannot name or authorise the parties processing that personal data, nor demonstrate flow-down terms to them. The EU AI Act value-chain recitals (88–90) reinforce that such downstream parties are only reachable by written agreement. A compromise at an undisclosed downstream subprocessor would therefore be an independently reportable processing/engagement failure, not merely a commercial problem. Confidence is kept low because the chain is implied by 'an enterprise AI platform from a major vendor' rather than documented, and no GDPR Art. 28 text was returned by the corpus to pin the obligation precisely.
    AU Silent/Automatic TriggerYNagent · overrideOverride. The questionnaire's 'N' answers for the PRIMARY dependency, where the loss event is a discrete support-staff log access aimed at Northwind specifically. Dimension 7.1 is a different event class: substitution or addition of a downstream subprocessor (model provider, cloud region, log-storage operator) is a platform-level decision by Nimbus that lands on every tenant of the shared runtime at once, with no case-by-case determination about Northwind. The scenario itself evidences this mode — Nimbus 'publishes changes to logging and retention in release notes at the time they take effect', i.e. a unilateral, fleet-wide change. The AI Act value-chain recitals describe exactly this structure, where components and processes are swapped in by the provider and the downstream deployer learns of it only through the provider's disclosure.
    R Portability / Exit RecoveryUUagentConfirmed. The capability at stake — an agentic procurement assistant calling ERP and contract-management systems — is reconstitutable: the systems of record remain Northwind's, and only the runtime and connectors are vendor-supplied. Exit therefore means manual re-integration and re-contracting rather than permanent loss, consistent with the questionnaire's 'yes, with manual migration effort'. Note for the reviewer: Northwind cannot exit a single downstream subprocessor in isolation — it has no privity with it — so recovery at 7.1 is only achievable by migrating off Nimbus as a whole. Separately, tool-call payloads already resident in downstream log stores are not recoverable by migration (a purgeability problem the rubric hooks to R elsewhere, e.g. entries 2.3 and 3.6), but that does not make the capability itself irrecoverable, so I = Irrecoverable is not warranted.
    V Blast-Radius ConcentrationCCagentConfirmed, and it is the strongest finding in this group. Nimbus is explicitly 'Northwind's standard agent runtime' and 'the same connectors are used by finance and supply-chain agents', so the platform is a shared control plane. Any downstream subprocessor sits beneath that control plane and is thus in the critical path for many or all of Northwind's AI workloads simultaneously — the compounding effect that defines 7.1. The rubric attaches V as the supplemental hook precisely to tool-call parameters and results (entry 2.4), because a tool call carries live production state — here supplier pricing, negotiated rebates, open POs and approval-chain identities — making each logged record high-density rather than diffuse telemetry.
    RE Exit / Mitigation EffortMMagentConfirmed. The realistic mitigation for 7.1 is contractual and procedural rather than architectural: obtain a subprocessor register with advance-notice and flow-down obligations, and extend Northwind's data-classification policy to cover tool-call parameters and results (the gap the scenario names). The rubric records 7.1's existing standard as 'General TPRM practice (partial)' and its gap severity as only Medium, which indicates the lever is largely available through established third-party-risk tooling, and the AI Act recitals point to model contractual terms as the intended instrument. That is a project but not a re-architecture, so H is not justified; equally, Northwind has no privity with the downstream parties and no technical control over them, so the fix is not trivial and L is excluded.
    U Vendor Notice PostureAmberAmberagentConfirmed on the evidence available. The scenario states Nimbus 'publishes changes to logging and retention in release notes at the time they take effect' — concurrent disclosure, with no advance window and no contractual guarantee, which is the Amber definition. Log retention and storage is the part of the downstream chain most relevant to this dimension, so that practice is the best direct evidence of notice posture here. A reviewer should note a pull toward Red: for subprocessor identity itself the scenario evidences no disclosure mechanism at all (the chain beneath Nimbus is undisclosed), and the AI Act value-chain recitals treat such information as something that must be secured by written agreement rather than assumed. I have not gone to Red because the documented release-note practice shows the vendor does disclose sovereignty-relevant changes, just without lead time.

What Northwind Consumer Goods should do next

Written by the narrative agent from the findings and mitigations

  1. Northwind should immediately add a data-classification category for data that exists only as the parameters and results of an agent's tool calls, and classify supplier pricing, rebates, open purchase orders and approval-chain identities at the same level they carry inside the ERP.
  2. Northwind should require human confirmation before the assistant performs any consequential action — raising or amending a purchase requisition, or issuing a contract-compliance verdict — and should block automatic tool use once untrusted content such as a supplier quote or contract document has entered the conversation.
  3. Northwind should cut what the connectors can reach to the minimum each agent needs, giving the procurement, finance and supply-chain agents separate identities, credentials and permissions rather than sharing one connector set across all three.
  4. Northwind should obtain written commitments from Nimbus on advance notice of behaviour, logging and retention changes, on named support-access approval and notification, and on the retention and deletion of tool-call logs, and should treat the absence of those commitments as a contractual gap to escalate.
  5. Northwind should keep its own log of every tool call its agents make — what was requested, what was returned, which agent and which human was involved — so it has an independent record to reconcile against the ERP and can detect altered or falsified requisitions.
  6. Northwind should require Nimbus to disclose the parties beneath it that process or store interaction logs, together with their locations, and update its processing records and privacy assessments to cover the approval-chain identities held in those logs.
  7. Northwind should ask Nimbus to confirm whether minimisation, masking or a shortened retention period can be applied to tool-call logs, and whether support access can be gated on customer approval with an access record Northwind can inspect.
  8. Northwind should bring the Nimbus runtime into its model-risk and change-management regime, assigning a named owner to review every release note on publication and to test agent behaviour before buyers rely on it again.

Ranked mitigations

Retrieved from the mitigation library for the adverse metrics

10
RelevanceMitigationTargets
0.95Segmentation of AI Agent Components (AML.M0032): Define enforceable security boundaries around AI agent tools, data sources, identities, and execution environments. Mediate access through authenticated APIs, isolate code execution via containers or virtual machines, restrict filesystem and network access, and limit tool invocation rates. Build execution environments from clean base images for each run, and do not carry forward any operational state. When AI agents share infrastructure, isolate each agent's identity, credentials, state, storage, messaging, tools, and network access to prevent undesired agent-to-agent channels or coordination. Run the highest-risk workloads in network-isolated or air-gapped environments.Directly hardens the tool/plugin execution environment (4.3) and caps how far a compromised tool call can reach, cutting both the confidentiality and integrity blast radius and the concentration of a single shared environment.AVACVCVISCSIVRE
0.93Restrict AI Agent Tool Invocation on Untrusted Data (AML.M0030): 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 context, and always requiring user confirmation for high-consequence actions.Removes the low-complexity, no-interaction automatic trigger path by which untrusted content causes tool calls with sensitive parameters to fire silently (2.4, 4.3).ACATAUUIVCSCSI
0.90AI Agent Tools Permissions Configuration (AML.M0028): When deploying tools shared across multiple AI agents, implement robust policies and controls on tool permissions, applying least privilege along with delegated access so tools receive the permissions, identities and restrictions of the AI agent calling them. These configurations may be implemented in the MCP servers connecting agents to tools or directly in the tool configuration files, and they limit abuse of tool invocations, access to sensitive data, exfiltration via tool invocation, and data destruction via tool invocation.Least-privilege and delegated identity on tool calls shrinks what tool parameters and results can expose or alter (2.4, 4.3), lowering downstream confidentiality and integrity impact.AVVCVISCSIV
0.88Human In-the-Loop for AI Agent Actions (AML.M0029): Require user confirmation of AI agent tool invocations to prevent automatic execution of tools by an adversary. Human in-the-loop policies should scale with the degree of consequence of the task: minor, repetitive tasks on basic tools may require minimal oversight, while agents in systems with significant consequences may require approval from multiple stakeholders diversified across multiple organizations.Inserts a mandatory approval gate so consequential agent actions and model/tool changes cannot execute silently and automatically (2.4, 4.3, 6.1).AUUIATVISIS
0.87AI Telemetry Logging (AML.M0024): 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; logging also discourages adversaries who want to remain undetected. Specifically: log AI agent tool invocations to detect malicious calls, log requests to AI services and RAG databases to detect malicious queries for data, and detect exfiltration or data-destruction via tool invocation.Provides the evidence trail needed to detect otherwise silent tool-call and control-plane changes and to demonstrate regulatory accountability, while reducing the effort to scope and exit an incident.AUSERESCSI
0.85Code Signing (AML.M0013): Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing. Adversaries can embed malicious code in AI software or models. Developers should cryptographically sign SBOM and AIBOM components that track model or data provenance. Enforce properly signed drivers, ML software frameworks and model files; prevent execution of ML artifacts that are not properly signed. Code signing guarantees that the model or package has not been manipulated after signing.Signature enforcement on model files and plugin packages prevents unverified or silently substituted versions from being promoted into production (1.3, 4.3).VISIAUATE
0.84Validate AI Model (AML.M0008): 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. Validation against a wide range of adversarial inputs increases confidence that a model has not been manipulated or modified.Pre-promotion validation plus drift monitoring is the detective control that surfaces unannounced vendor model updates and behavioural regressions before they propagate downstream (1.3).VISIAUUIRE
0.80Verify AI Artifacts (AML.M0014): Verify the cryptographic checksum of all AI artifacts to confirm the file was not modified by an attacker. Introduce proper checking of signatures to ensure that unsafe AI models, data and artifacts will not be introduced to, or executed in, the system.Checksum/signature verification at deployment gives a deterministic version-integrity check for each model and tool artifact release (1.3, 4.3).VISIAUAT
0.76Control Access to AI Models and Data at Rest (AML.M0005): Establish access controls on internal model registries and limit internal access to production models; limit access to training data to approved users. Access controls prevent tampering with AI artifacts and unauthorized modification or copying, verify identities before granting access to model registries so newly established accounts cannot automatically access protected AI assets, restrict access to stored system prompts, configuration files, tool definitions and model metadata, and restrict write access to model registries and AI artifact stores.Restricting write access to registries and configuration stores raises the privilege and complexity required to change a deployed version or console configuration (1.3, 6.1).AVACVISIVCSC
0.72Authority Expansion Controls (AML.M0037): Treat newly discovered targets, resources, authorities, identities, execution environments, tools, communication paths and trust relationships as outside the authorized boundary, requiring approval before an agent may act on them. Propagate a parent agent's authority constraints to sub-agents so orchestration cannot create 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, and new resource discovery, denials, exceptions, approvals and scope changes should be logged using AI Telemetry Logging.Bounds the authority an agent or its sub-agents can acquire through tool calls and control-plane privileges, limiting silent scope creep and the concentration of downstream impact (2.4, 6.1).AUATSCSIVUI

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:M AT:N AU:N AV:N CR:H E:P IR:H PR:L R:U RE:M S:X SA:L SC:H SI:H U:Amber UI:P V:C VA:N VC:H VI:L
Job
d5716ec8-1c99-4dec-b609-ad5abb24cd02