Who is accountable when a service account is over-privileged and customer data is exposed through support tooling?

Why This Matters for Security Teams

Over-privileged service account are not just an access control issue. They are an accountability failure that spans IAM design, support tooling, data classification, and operational monitoring. When a service account can see customer records it does not need, the organisation has already accepted avoidable exposure. The pattern is familiar in NHI incidents: broad default access, weak ownership, and delayed detection. NHIMG notes that 97% of NHIs carry excessive privileges, and that is why this problem often looks routine until it becomes a disclosure event.

Security teams should treat support tooling as a high-risk data path, not a convenience layer. The relevant control question is not only who can log in, but what the account can retrieve, export, or relay through connected systems. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs both point to the same operational risk: NHI permissions drift faster than most review cycles can catch. In practice, many security teams encounter this only after a support workflow has already exposed data rather than through intentional access design.

How It Works in Practice

Accountability usually sits with the organisation, but operational responsibility is shared across the teams that define, approve, and run the service account. IAM owns the entitlement model, the application team owns what the account actually needs, and the platform or support tooling team owns how data is surfaced, exported, and logged. If any one of those layers is loose, the service account becomes a hidden superuser for customer data.

The practical control pattern is to bind the account to a narrowly defined workload, then continuously verify that its permissions still match the task. For non-human identities, best practice is evolving toward short-lived access, explicit scoping, and monitoring that is tied to the workload rather than the person who created it. That includes:

• using workload identity and strong authentication for the account itself, rather than shared human-style credentials;
• restricting the account to specific objects, queues, tenants, or case records;
• removing broad read access from support tooling unless it is justified and approved;
• issuing time-bound credentials or tokens where possible;
• logging every retrieval, export, and privilege escalation path.

When customer data exposure occurs, incident response should map the blast radius to the account’s effective permissions, not just the ticket that triggered the alert. That is why NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant: access enforcement, auditing, and least privilege must be provable. NHIMG’s 52 NHI Breaches Analysis shows how often identity misuse, not exotic exploitation, drives exposure. These controls tend to break down when support tools are built for speed first and retrofitted with access controls after customer data is already reachable.

Common Variations and Edge Cases

Tighter access control often increases support friction, so organisations have to balance containment against case-handling speed. That tradeoff is real, but it does not change accountability: if customer data is exposed through a service account, the owning organisation is responsible for the permissions model and the control gaps around it.

There is no universal standard for how much visibility support staff should have into live customer records, but current guidance suggests minimising standing access and using just enough context to resolve the issue. In regulated environments, temporary elevation with approval, session logging, and data masking are better patterns than permanently broad access. Where agentic automation is involved, the risk becomes harder to predict because a tool-using agent may chain actions and expose more than the original workflow intended, a concern highlighted in NHIMG’s Why NHI Security Matters Now and the broader AI misuse concerns in Anthropic’s AI-orchestrated cyber espionage report. The hardest edge case is a shared support account with no clear business owner, because then accountability becomes political instead of operational.

Related resources from NHI Mgmt Group

• Who is accountable when a privileged OT service account is exposed through SSRF?
• Who is accountable when a service account breach exposes customer data?
• Who is accountable when cloud data is exposed through a shared account or snapshot?
• Who is accountable when a service account used for API access is over-privileged?