Who is accountable when a non-human identity deletes production data through a valid token?

Why This Matters for Security Teams

When a non-human identity deletes production data with a valid token, the immediate question is not whether the token was “legitimate.” The real issue is whether the organisation allowed a single credential to cross too many trust boundaries without compensating controls. That is an identity design failure, a policy failure, and a recovery failure at the same time. NHI governance breaks down when teams treat issuance as the end of security, rather than the beginning of continuous control.

The risk is amplified by overprivileged service accounts and long-lived secrets. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes destructive actions far more likely once a token is valid. NIST’s NIST Cybersecurity Framework 2.0 frames this as a governance and recovery problem, not just an authentication problem. In practice, many security teams encounter this only after production data has already been erased, rather than through intentional control testing.

How It Works in Practice

Accountability should be assigned across the control chain, not collapsed onto the workload that executed the deletion. The team that approved the secret model is accountable for how the identity was minted, scoped, rotated, and revoked. The platform team is accountable for whether the runtime policy allowed destructive actions without step-up controls. The data protection and recovery owners are accountable for whether backups, rollback paths, and deletion safeguards were actually separable from the same token.

This is where static IAM models fail for autonomous or tool-using workloads. If an AI agent, daemon, or pipeline can decide at runtime what tool to call next, then RBAC alone is too coarse. Current guidance suggests intent-based authorisation, JIT credentials, short-lived secrets, and workload identity as the more defensible pattern. That means the identity should prove what the agent is, while policy should decide what it may do right now, for this task, against this resource. OWASP’s agentic guidance and NIST Cybersecurity Framework 2.0 both reinforce the need for least privilege, logging, and recovery readiness.

A practical control stack usually includes:

• Workload identity such as SPIFFE or OIDC for cryptographic proof of the non-human workload.
• JIT, ephemeral credentials that expire after one task or short window.
• Policy-as-code at request time, so deletion requires current context, not just a standing role.
• Protected recovery boundaries, where backups and admin deletion rights are separated.

NHIMG’s Guide to the Secret Sprawl Challenge shows why broad secret exposure keeps turning valid tokens into enterprise-wide incidents, while the Salesloft OAuth token breach demonstrates how a single abused token can become a business-impacting access event. These controls tend to break down when legacy systems require long-lived service accounts because the credential cannot be narrowed, rotated, or bounded without redesigning the application.

Common Variations and Edge Cases

Tighter credential controls often increase operational overhead, requiring organisations to balance faster automation against stronger containment. That tradeoff is especially visible in CI/CD, backups, and maintenance jobs, where teams sometimes grant broad access “just to keep the pipeline working.” Best practice is evolving, but there is no universal standard for this yet: some environments can move to per-task tokens immediately, while others need transitional patterns such as brokered access or scoped gateway identities.

Edge cases matter. A database migration job that deletes staging data is not the same as an agent that can purge production records and backup snapshots. If the same secret can do both, accountability becomes shared because the boundary was never designed. This is also why 52 NHI Breaches Analysis and the Top 10 NHI Issues consistently point back to weak scoping, poor rotation, and missing offboarding. For agentic systems, the emerging baseline in NIST Cybersecurity Framework 2.0 and the NIST AI risk guidance is to separate who can act, what they can access, and what can be recovered after failure.

The accountability answer is therefore operational: assign ownership to the people who allowed the token to exist with destructive reach, then prove that a valid token cannot silently become irreversible damage.

Related resources from NHI Mgmt Group

• Who is accountable when a non-human identity is over-privileged?
• Who is accountable when an inactive non-human identity is still present after business use has ended?
• How should teams certify non-human identity access without breaking production?
• Who is accountable when a privileged non-human identity causes a security incident?