Who is accountable when internal automation exposes customer credentials?

Why This Matters for Security Teams

When internal automation exposes customer credentials, the issue is not just a leaked secret. It is a control failure that spans design, approval, storage, monitoring, and revocation. Accountability typically lands with the teams that defined the workflow, allowed standing access, or failed to enforce a boundary around the automation. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-63 Digital Identity Guidelines is clear that identity assurance and lifecycle control must be explicit, even for non-human actors.

The problem is amplified by secret sprawl and delegated trust. NHIs often inherit broad permissions, static tokens, and weak handoffs between platform teams and security owners. That is why NHIMG’s Guide to the Secret Sprawl Challenge and 52 NHI Breaches Analysis are so relevant: the breach is usually less about one bad commit and more about a system that let automation behave like a trusted operator without the constraints a human would face. In practice, many security teams encounter this only after exposed credentials are already being reused elsewhere, rather than through intentional governance.

How It Works in Practice

Accountability should be mapped to the control owners who approved each part of the workflow: the IAM team for identity design, PAM for elevation boundaries, platform engineering for runtime execution, and security operations for monitoring and response. That does not mean shared blame in the abstract. It means each team owns a specific control point, and those control points must be auditable. For example, a CI/CD job, script, or internal agent should not hold long-lived customer credentials if a short-lived delegation pattern will do. That is aligned with the direction of the OWASP Non-Human Identity Top 10 and with the broader identity assurance model in NIST SP 800-63 Digital Identity Guidelines.

In mature environments, the workflow is usually structured around:

• Named ownership for each automated action, including who approved the authority and who can revoke it.
• Just-in-time issuance of ephemeral secrets rather than persistent tokens stored in code, logs, or build variables.
• Workload identity for the automation itself, so the system proves what it is before it receives access.
• Policy checks at request time, not only at deployment time, so the action is judged against current context.
• Continuous detection for abnormal access paths, especially where the automation can chain tools or copy secrets into downstream systems.

NHIMG research shows the scale of the problem is still underappreciated: in the 2024 Non-Human Identity Security Report, 23.7% of organisations said they share secrets through insecure methods such as email or messaging applications. That matters because a workflow that leaks a customer credential is rarely operating in isolation. It is usually part of a larger secret-handling pattern that has already been normalised. These controls tend to break down in hybrid and multi-cloud environments because ownership, token lifetime, and enforcement points are split across too many systems.

Common Variations and Edge Cases

Tighter credential controls often increase delivery overhead, requiring organisations to balance speed of automation against the cost of stronger isolation. That tradeoff becomes more visible in shared service accounts, third-party integrations, and legacy jobs that cannot easily support workload identity. In those cases, current guidance suggests documenting the exception, reducing the blast radius, and moving to ephemeral credentials as the default rather than treating static access as acceptable long term.

There is no universal standard for this yet in every agentic or automation pattern, but the direction is consistent. If an internal agent is autonomous, goal-driven, or capable of tool chaining, then static RBAC alone will not describe the real risk. The practical answer is to bind authority to the workload, constrain it with ZSP and ZTA principles, and enforce revocation as part of the workflow itself. NHIMG’s LLMjacking research and the external Anthropic report on the first AI-orchestrated cyber espionage campaign both show why autonomous systems cannot be treated like ordinary batch jobs once credentials are in play. In practice, the hardest cases are the ones where automation is owned by one team, deployed by another, and monitored by a third.

Related resources from NHI Mgmt Group

• When does NHI automation become necessary?
• Should organisations prioritise external exposure or internal credential governance first?
• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?