Who is accountable when a vendor or bot gets excessive access to a production system?

Why This Matters for Security Teams

When a vendor account or bot receives too much access, accountability is rarely a single-person issue. The business owner approved the relationship, the identity team enforced or failed to enforce the guardrails, and the system owner exposed the production resource. That split matters because excessive access often persists after onboarding, during integration changes, and after the original risk review is forgotten. NHI Management Group research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which means this is usually a control failure, not a one-off exception.

The practical challenge is that vendor access and bot access are often treated like ordinary user access, even though their behaviour is broader, longer-lived, and harder to supervise. Guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point toward shared control ownership, least privilege, and periodic review, but many organisations still do not assign those duties to specific named roles. In practice, many security teams discover excessive access only after a vendor integration is already in production and the system has become operationally dependent on it.

How It Works in Practice

Accountability should be mapped before access is granted. The business owner owns the risk acceptance and use case, the system owner owns the exposed asset and technical boundaries, and the identity team owns the policy enforcement, review cadence, and revocation mechanics. For bots and other non-human identities, that model should also include the service account or workload owner, because the identity often outlives the original implementation team.

Security teams should document three things for every production entitlement: who approved it, who can revoke it, and who must review it. That review should include the access scope, credential lifetime, logging coverage, and whether the vendor or bot is using an identity model that supports least privilege. The OWASP NHI guidance stresses that non-human identities need lifecycle controls, not just provisioning, while NIST controls such as access authorisation and account management push organisations toward periodic validation rather than permanent trust.

• Use named accountable owners, not generic team labels, for every production integration.
• Require time-bound approvals for vendor access and task-bound approvals for bots.
• Separate approval authority from enforcement authority so exceptions are visible.
• Reconcile actual permissions against the approved scope on a fixed schedule.
• Trigger revocation when the vendor contract, workload, or automation job ends.

This is especially important for production systems exposed through APIs, CI/CD runners, support tooling, or shared service accounts. In those environments, the identity may be embedded in automation and inherited by multiple tools, which makes accountability harder to trace if ownership is not explicit. The NHI Management Group Ultimate Guide to NHIs — Key Challenges and Risks highlights how broad exposure and poor lifecycle control turn ordinary access into persistent privilege. These controls tend to break down when vendors share credentials across environments because revocation and attribution become technically and contractually ambiguous.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance fast onboarding against stronger control ownership. That tradeoff is real, especially when a vendor needs emergency access or a bot supports production remediation. Current guidance suggests that temporary access can still be accountable if it is pre-approved, logged, time-limited, and tied to a named approver and revoker. There is no universal standard for this yet, so organisations should document their own decision rules and exception thresholds.

Edge cases usually appear when the access path is indirect. A bot may be launched by CI/CD, a vendor may authenticate through a managed gateway, or a third party may inherit privileges from a shared platform account. In those cases, the accountable party is still the owner of the relationship and the control environment, but the technical evidence may sit in different logs, vaults, and ticketing systems. NHI Management Group’s 52 NHI Breaches Analysis shows how these weak points become breach pathways when ownership is unclear.

For high-risk production access, best practice is evolving toward just-in-time access, short-lived credentials, and explicit revocation duties. That reduces standing privilege, but it also means accountability must be operational, not ceremonial. If nobody owns the approval workflow, the service account inventory, and the offboarding step, the access will persist long after the business need has ended.

Related resources from NHI Mgmt Group

• Who is accountable when identity blind spots lead to excessive access or missed risk?
• Who is accountable when a vendor session touches a production system outside the approved scope?
• Who is accountable when a legacy system or vendor path is left with standing access?
• Who is accountable for agent behaviour when coding agents can shape production code and system access?