Look-through problem

The governance failure that occurs when an organisation assumes a vendor relationship transfers accountability away from the buyer. In regulated AI use, the insurer still owns the outcome and must show how third-party models were tested, monitored, and controlled in production. The contract does not replace the control.

Expanded Definition

The look-through problem describes a governance gap that appears when an organisation treats a third-party service, model, or platform as if it removes the buyer’s own accountability. In practice, the buyer still has to understand what the supplier is doing, how inputs are processed, what controls exist, and what evidence can be produced when regulators or auditors ask questions. This is especially relevant in AI and identity-dependent workflows, where a vendor may host the model, but the customer remains responsible for outcomes, monitoring, and risk acceptance.

In security and AI governance, the issue is not simply vendor risk management. It is the failure to preserve visibility across the full control chain. That means looking through the supplier relationship to assess data handling, model updates, logging, incident response, and human oversight. The concept aligns with the accountability emphasis in the NIST Cybersecurity Framework 2.0, even though no single standard uses the phrase universally. Definitions vary across vendors, but the governance expectation is consistent: contracting out a capability does not contract out responsibility. The most common misapplication is assuming a procurement approval also satisfies control ownership, which occurs when teams confuse supplier assurances with documented operating evidence.

Examples and Use Cases

Implementing look-through governance rigorously often introduces evidentiary overhead, requiring organisations to weigh vendor convenience against the cost of continuous assurance and documentation.

• An insurer uses a third-party LLM to draft claims summaries but still needs records showing how prompts are filtered, outputs are reviewed, and bias is monitored before decisions are finalised.
• A bank outsources fraud detection to a cloud AI service and must still prove how alert thresholds, drift checks, and escalation paths are controlled in production.
• A healthcare provider integrates an external API for identity verification and must look through the provider contract to verify retention rules, access restrictions, and incident notification duties.
• A security team adopts an agentic workflow platform and must understand which tools the agent can invoke, what human approval exists, and how actions are logged for audit.
• A procurement team selects a SaaS product with embedded AI features and must map supplier claims to internal controls rather than treating marketing statements as operational assurance.

This is why governance teams often pair contract review with control mapping and assurance testing, using references such as NIST Cybersecurity Framework 2.0 and related internal risk registers. In AI-heavy environments, the look-through question is whether the organisation can actually evidence how the model behaves, not just who supplies it.

Why It Matters for Security Teams

The look-through problem matters because many operational failures are hidden behind a false sense of delegation. When teams assume that a supplier’s controls are sufficient on their own, they often leave gaps in monitoring, approval, logging, and incident response. That can create weak assurance over AI-assisted decisions, outsourced identity checks, and automated actions taken by agents with execution authority. For NHIMG’s identity and AI security lens, the risk is especially acute where a vendor controls secrets, model access, or decision logic that influences authentication, fraud screening, or privileged workflows.

Security teams need a clear answer to three questions: who owns the control, who can evidence it, and who acts when it fails. Without that clarity, audits become reactive and incidents become harder to contain. The problem also affects governance reporting, because risk committees may receive supplier summaries instead of proof that the organisation itself can supervise the service. References such as NIST Cybersecurity Framework 2.0 are useful because they reinforce ownership, oversight, and continuous risk management rather than blind trust in third parties. Organisations typically encounter the real cost only after a model incident, a failed audit, or a disputed decision, at which point look-through accountability becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is SPIFFE and what problem does it solve for NHI security?
• What does good NHI governance look like for audit and compliance purposes?
• When does a machine identity become a compliance problem?
• What problem does ownership attribution solve for service accounts and API keys?