Who is accountable when a compromised service account or AI agent moves laterally?

Accountability sits with the organisation that assigned the access and failed to constrain it. The right question is whether the identity was given more reach than its task required, and whether the programme had enough segmentation and governance to limit the resulting blast radius. That is the control failure leaders must own.

Why This Matters for Security Teams

When a compromised service account or AI agent moves laterally, accountability does not rest with the malware or the agent itself. It sits with the organisation that issued the identity, allowed the trust boundary to expand, and failed to constrain what that identity could reach. That distinction matters because lateral movement is usually a control failure, not an isolated incident. NHI Management Group’s breach research on 52 NHI Breaches Analysis shows how often non-human identities become the path of least resistance once access is too broad.

Security teams often miss the point by treating the compromise as the root cause. The more useful question is whether the identity was issued for a narrow task, whether segmentation limited blast radius, and whether the owner of the service or model accepted those risks. Current guidance from NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 is consistent on one point: governance has to define who owns access, who approves the scope, and who is on the hook when that scope fails. In practice, many security teams encounter accountability gaps only after the identity has already crossed into systems it was never meant to touch.

How It Works in Practice

Accountability should follow the control plane, not the attacker path. For a service account, that means the application owner, platform team, or business system owner is responsible for the access model they approved, while security is responsible for the guardrails it enforced. For an AI agent, the accountability chain is broader because the agent can chain tools, call APIs dynamically, and behave in ways that were not fully scripted ahead of time. That is why static role design is often too blunt for autonomous systems.

Practitioners increasingly separate three layers:

• Identity issuance: who created the service account or agent identity, and for what task boundary.
• Authorisation scope: what systems, data, and tools the identity may use at runtime.
• Operational oversight: who monitors usage, revokes access, and investigates anomalies.

In agentic environments, intent-aware policy evaluation is more defensible than fixed role assumptions. The policy should be evaluated at request time, with context such as task, destination, data sensitivity, and whether the action is consistent with the declared objective. This is why current guidance increasingly points to workload identity, short-lived credentials, and just-in-time access rather than standing privileges. The pattern aligns with research in AI Agents: The New Attack Surface report and with implementation thinking in the CSA MAESTRO agentic AI threat modeling framework.

In practical terms, teams should instrument audit trails for every delegated action, bind credentials to workload identity, and use revocation on task completion rather than calendar-based rotation alone. These controls tend to break down in highly integrated environments where one identity is reused across multiple pipelines, because no single team can clearly prove where its authority ends.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance faster delivery against stronger containment. That tradeoff is especially visible in shared platform teams, where service accounts are reused for convenience, and in agentic systems where tool access is provisioned on demand. Best practice is evolving, but there is no universal standard yet for how to assign human accountability when an autonomous agent makes a decision within its permitted scope.

There are two common edge cases. First, a compromised service account may be technically owned by infrastructure but functionally controlled by the product team that requested it. Second, an AI agent may act under a business objective approved by leadership, yet the blast radius comes from weak engineering guardrails. In both cases, accountability is shared, but not diluted. The organisation that allowed standing reach, weak segmentation, or vague ownership remains accountable for the design failure.

This is why practitioners should treat lateral movement as evidence that governance was incomplete, not as proof that the attacker was uniquely skilled. NHIMG’s reporting on LLMjacking: How Attackers Hijack AI Using Compromised NHIs and the OWASP NHI Top 10 both reflect the same operational reality: once an identity can move laterally, the failure is usually in ownership, scope, and containment rather than in attribution after the fact.

Related resources from NHI Mgmt Group

• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who is accountable when a service account or AI agent is over-privileged?
• Who should be accountable when an AI agent or service account causes access drift?
• Who is accountable when AI systems make decisions through service accounts or workflows?