Who is accountable when a cross-door agent attack slips through separate controls?

Accountability sits with the teams that allowed the workflow to span two governance domains without a unified control plane. The issue is not only malicious behaviour, but the architecture that made attribution difficult. Security, identity, and platform owners all need a shared answer for the same agent trail.

Why This Matters for Security Teams

Cross-door agent attacks expose a governance gap that traditional ownership models rarely cover: one team controls the first doorway, another controls the second, and neither has full visibility into the agent’s end-to-end path. That matters because agents are not passive workloads. They can chain tools, reuse tokens, and shift from one domain to another faster than human review can keep up. Current guidance increasingly treats this as a control-plane problem, not just an incident-response problem.

NHI Management Group has repeatedly shown that weak visibility and over-privilege create the conditions for compromise, and the same pattern applies when agents cross boundaries. See the Ultimate Guide to NHIs — Why NHI Security Matters Now and the OWASP Agentic Applications Top 10 for the broader risk pattern. External guidance from the NIST AI Risk Management Framework reinforces that accountability must be assigned across the full lifecycle of AI behaviour, not just at deployment.

In practice, many security teams encounter cross-domain agent abuse only after logs show an apparently “valid” sequence that no single owner can explain.

How It Works in Practice

Accountability becomes clear only when the agent trail is stitched together from identity, policy, and execution telemetry. Static RBAC alone is not enough for autonomous systems because agents do not follow fixed request patterns. They act on intent, and that intent can change mid-workflow. For that reason, practitioners are moving toward runtime authorization, ephemeral credentials, and workload identity as the primary control points rather than long-lived shared secrets.

In an operational model, the agent should present a workload identity, such as an OIDC-backed token or a SPIFFE-based identity, before it can call any downstream tool. The authorization layer then evaluates the request in real time, using task context, data sensitivity, risk posture, and session scope. Where the request is approved, JIT secrets should be issued only for the specific action and revoked on completion. This is the practical difference between “the agent has access” and “the agent is allowed this one action right now.”

That approach is consistent with OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize runtime controls, tool isolation, and scoped authorization. NHI Management Group research also highlights how often secrets and service accounts remain overexposed; the 52 NHI Breaches Analysis shows that identity failures usually surface only after an attacker has already chained access across systems.

• Define a single owner for agent identity, policy, and audit correlation.
• Use short-lived credentials tied to one task, not one service account for many tasks.
• Evaluate every tool call at runtime with current context, not only at login time.
• Record a unified trail so security, identity, and platform teams can reconstruct the same sequence.

These controls tend to break down in loosely coupled SaaS-to-SaaS workflows because each platform records a partial truth and no one system can enforce end-to-end policy.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance blast-radius reduction against workflow latency and coordination cost. That tradeoff is especially visible in multi-agent pipelines, third-party integrations, and delegated automation where one agent hands work to another across separate governance domains.

The hard edge case is attribution. If one control plane authorizes the first action and another approves the second, accountability depends on whether the organisation defined a shared policy model before production. Best practice is evolving, but there is no universal standard for this yet. Many teams are now using intent-based policies, shared event correlation, and per-step approval boundaries to reduce ambiguity, but those practices only work when both domains expose compatible telemetry.

For governance leaders, the question is not whether the attack “belonged” to one team. It is whether the organisation created a workflow that made a cross-door attack possible without a common enforcement point. The Ultimate Guide to NHIs — 2025 Outlook and Predictions and the Anthropic report on AI-orchestrated cyber espionage both point to the same lesson: once an autonomous system can chain tools, separate controls often fail unless they are designed as one governed path.

Edge cases also include human-in-the-loop approvals that are too slow to matter, emergency access that bypasses policy, and shadow agent workflows created outside central identity standards. Those environments require explicit ownership for the policy boundary itself, not just for the systems inside it.

Related resources from NHI Mgmt Group

• Who is accountable when P2P fraud slips through fragmented APAC controls?
• Who is accountable when a merchant slips through onboarding controls?
• Who is accountable when an MCP tool call is authorised through a gateway and fails downstream?
• What is the difference between human identity governance and AI agent governance?