Who is accountable when a tool vendor leaves credential exposure unpatched?

The vendor remains accountable for the software control failure, but the deploying organisation still owns the risk acceptance decision. Security teams should document the exposure, restrict affected tooling, and decide whether the business case justifies continued use while the flaw remains open. That is the point where governance meets operational tolerance.

Why This Matters for Security Teams

Credential exposure is not just a vendor defect. Once a tool integrates into production, the deployed environment inherits the risk, and the organisation still decides whether to keep using it, isolate it, or remove it. That distinction matters because exposed secrets are routinely abused within minutes, not days, as shown in NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs research and the broader pattern documented in the 52 NHI Breaches Analysis.

The practical mistake is treating a vendor patch delay as if it were only a procurement issue. In reality, it becomes an operational access decision, a detection problem, and often a governance exception that needs explicit sign-off. OWASP’s OWASP Non-Human Identity Top 10 frames this well: secret exposure and weak lifecycle control are identity failures, not just software bugs. In practice, many security teams encounter the blast radius only after the credential has already been used for lateral movement, rather than through intentional risk review.

How It Works in Practice

Accountability splits along two lines. The vendor is accountable for the control failure if its product leaked or failed to protect a credential. The deploying organisation is accountable for what happens next: whether that tool stays connected to sensitive systems, whether the exposed secret is rotated or revoked, and whether compensating controls are strong enough to justify continued use.

That means the response should be operational, not purely contractual. Current guidance suggests four actions:

• Document the exposure, affected systems, and the exact secret type involved.
• Revoke or rotate the credential immediately, then invalidate any dependent tokens or sessions.
• Restrict tool permissions to the minimum viable scope while the issue remains open.
• Track the vendor’s patch status as a condition of continued approval, not as a passive update notice.

This is where non-human identity governance becomes concrete. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why long-lived credentials are especially dangerous: the longer the secret lives, the longer the exposure window. For implementation, the strongest pattern is short-lived, task-bound credentials with automated revocation, backed by workload identity and policy checks at request time. NIST’s NIST SP 800-63 Digital Identity Guidelines reinforces that identity assurance only has value when issuance, binding, and lifecycle are controlled tightly.

Anthropic’s report on the first AI-orchestrated cyber espionage campaign also shows how quickly adversaries operationalise stolen access once it is available, which is why rapid containment matters as much as root-cause remediation. These controls tend to break down when a vendor credential is embedded in a shared platform or CI/CD path because multiple teams inherit the same secret without clear ownership.

Common Variations and Edge Cases

Tighter vendor control often increases operational overhead, requiring organisations to balance supply-chain speed against exposure tolerance. That tradeoff is real, especially when the tool is business-critical or replacement is slow. Best practice is evolving, and there is no universal standard for this yet, but the direction is consistent: shorten credential lifetime, shrink scope, and make exceptions explicit.

Edge cases usually involve shared credentials, embedded API keys, or tools that cannot be patched without downtime. In those environments, the question is not whether the vendor is blameworthy. It is whether the organisation has enough compensating control to keep the tool connected at all. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because secret proliferation often turns one exposed credential into many.

For teams operating under compliance pressure, the safest interpretation is that vendor accountability does not reduce internal accountability. A patch promise is not a risk treatment. Until the flaw is fixed and the secret is proven dead, the deploying organisation owns the decision to tolerate exposure, and that decision should be time-bound, reviewed, and revocable.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Who is accountable when AI tool use happens through unmanaged browser sessions?
• Who is accountable when an AI vendor changes an agent's capabilities without notice?
• Who should be accountable when sensitive data exposure is found through privileged access?