Accountability belongs to the enterprise that relied on the service, because it still owns the data, the identities, and the business continuity risk. Teams should know where prompts, outputs, and related access records live, who can revoke authority, and how to recover them if the provider changes hands or exits. Without that clarity, governance disappears with the vendor.
Why This Matters for Security Teams
When a vendor can no longer operate, or the business is absorbed through acquisition, the hardest question is not whether the service keeps running. It is whether the enterprise still has enforceable control over the identities, data, and authorisation paths that service depended on. In practice, that means prompts, outputs, audit records, secrets, and delegated access need to remain governable even if the provider changes ownership or shutters.
This is why NHI governance cannot stop at procurement language. The risk is not just downtime; it is orphaned access, lost evidence, and a false assumption that the vendor will preserve operational continuity on the enterprise’s behalf. NHI Management Group has repeatedly shown how quickly exposed or unmanaged secrets become a live incident, including the patterns discussed in the LLMjacking research and the broader NHI market context in the Ultimate Guide to NHIs — The NHI Market.
The operational issue is simple: if the enterprise cannot revoke, recover, or reissue the AI workload’s access, then it does not truly control the workload. In practice, many security teams discover that gap only after an acquisition notice, a service sunset, or a credentials leak has already forced emergency response.
How It Works in Practice
Accountability should be designed around control, not hosting. The enterprise remains responsible for what the AI vendor processed on its behalf because the enterprise owns the business use case, the data classification, and the risk acceptance. That is consistent with the direction of NIST Cybersecurity Framework 2.0, which emphasizes governance, supply chain oversight, and outcome-driven risk management.
For AI services, current guidance suggests treating the vendor as a processor of enterprise-authorised activity, not the owner of the identity boundary. Security teams should require:
- Documented ownership of prompts, outputs, logs, and training artefacts created from enterprise data.
- Escrow or export rights for audit trails, configuration, and policy records.
- Revocation procedures for API keys, tokens, service accounts, and delegated approvals.
- Recovery plans that cover vendor shutdown, acquisition, and data transfer.
- Clear evidence of where secrets and access records are stored, who can retrieve them, and how they are destroyed.
This matters because acquired vendors often inherit different retention rules, access models, and support obligations. If the enterprise has not negotiated portability and revocation, the new owner may legally control the platform while the original customer still bears the operational fallout. The security model should therefore include workload identity, short-lived credentials, and explicit exit controls so that the enterprise can re-establish authority without waiting for the provider’s cooperation. NHI Management Group’s research on DeepSeek breach shows why exposed AI-related records can become a governance problem as quickly as a technical one.
These controls tend to break down when the vendor’s terms of service, acquisition terms, or data retention defaults prevent the enterprise from exporting logs and revoking access before the platform is repurposed.
Common Variations and Edge Cases
Tighter control over AI vendor exit rights often increases legal and operational overhead, requiring organisations to balance portability against procurement speed. That tradeoff becomes sharper when the vendor runs a managed model, an agentic workflow, or a multi-tenant system with shared credentials.
There is no universal standard for this yet, but current best practice is to distinguish between three cases. First, if the vendor is only providing infrastructure, the enterprise should own the workload identity and the secrets lifecycle. Second, if the vendor is performing managed inference or agent orchestration, the enterprise still needs contractual rights to export records and revoke delegated authority. Third, if the vendor is acquired, the enterprise should assume continuity risk until it verifies who now controls the environment and whether prior controls still apply.
The most common edge case is a hidden dependency on vendor-held keys or proprietary logs that cannot be transferred in time. Another is a model or agent that has been allowed to retain context from enterprise data without a clean offboarding path. In both cases, governance degrades at the exact moment a company expects continuity. Security leaders should therefore treat acquisition and shutdown as predictable lifecycle events, not exceptional incidents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | Vendor shutdown and acquisition are supply chain governance problems. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Orphaned AI access and unmanaged secrets are core NHI risks. |
| NIST AI RMF | GOVERN | AI accountability must remain assigned across vendor lifecycle changes. |
Assign a business owner for AI systems and require offboarding controls for provider exit events.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
