Who is accountable when AI agents create lateral movement risk in the enterprise?

Why This Matters for Security Teams

When AI agents can chain tools, reach across SaaS, and act without a human in the loop, lateral movement stops being a perimeter problem and becomes an identity and governance problem. The question is not only who approved the agent, but who owns its reach, its credentials, and the controls that should stop it from moving beyond scope. Guidance from the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both point to runtime governance, not static trust.

That matters because AI agents rarely behave like conventional workloads. They can trigger unexpected API calls, reuse tokens in ways humans did not anticipate, and move laterally through integrations that were never reviewed as a single attack path. NHIMG research on AI Agents: The New Attack Surface report found that 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials. In practice, many security teams discover this only after an agent has already crossed a boundary and no single owner can explain why that access existed.

How It Works in Practice

Accountability needs to be split by control plane, then joined through one governance model. Identity teams should own how an agent is authenticated, issued workload credentials, and restricted through just-in-time access. Infrastructure and network teams should own reachable paths, service-to-service trust, and segmentation. Security architecture should define the policy model that decides what an agent may do at runtime. That is the practical way to handle autonomous systems, because a role assigned once at deployment time cannot reliably predict every tool call, prompt chain, or workflow branch.

Current best practice is evolving toward workload identity plus runtime policy. For agents, that usually means cryptographic identity for the workload, short-lived credentials, and policy evaluation at request time. Standards work such as the CSA MAESTRO agentic AI threat modeling framework and the NIST Cybersecurity Framework 2.0 supports this kind of shared control ownership, while implementation guidance increasingly borrows from policy-as-code and Zero Trust patterns.

• Use workload identity for the agent, not a shared human credential.
• Issue ephemeral secrets per task and revoke them when the task ends.
• Enforce network reachability limits so an agent cannot freely pivot between systems.
• Evaluate privilege at runtime based on intent, context, and destination.
• Log every tool call and data access path back to a named owner.

NHIMG’s OWASP NHI Top 10 is useful here because lateral movement often begins as simple overreach: too much standing privilege, too much connectivity, and not enough revocation discipline. These controls tend to break down in legacy environments where agents inherit broad service accounts and flat east-west network access because no single team can change identity policy and routing together.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, so organisations have to balance responsiveness against blast-radius reduction. There is no universal standard for agent accountability yet, especially when an AI system is delivered by one team, integrated by another, and governed by a third. In those cases, the accountable owner should still be explicit: the team approving the trust boundary should own the residual risk, even if execution is distributed.

Some edge cases require special handling. Third-party agent platforms may limit visibility into internal tool chaining, which makes shared accountability even more important. Multi-agent workflows add another layer because one agent can trigger another, creating a lateral path through orchestration rather than through a traditional network exploit. The CoPhish OAuth Token Theft via Copilot Studio case illustrates how identity leakage can become a movement path when governance is fragmented. For deeper threat framing, the NIST AI Risk Management Framework and MITRE ATLAS adversarial AI threat matrix help teams separate model risk from operational abuse.

The practical rule is simple: if an agent can reach systems, then someone must own both the right to grant that reach and the obligation to remove it when behaviour changes. Where that ownership is split informally, accountability usually collapses after the first incident, not before it.

Related resources from NHI Mgmt Group

• Why do autonomous agents create more lateral movement risk?
• Why do service accounts and AI agents increase lateral movement risk?
• Why do AI ETL libraries create such high lateral movement risk?
• Why do AI inference servers create lateral movement risk?