How do IAM and AI teams decide who is accountable for agent actions?

Who should own agent actions when both IAM and AI are involved?

Accountability should be assigned to the control point that made the action possible, not only to the agent that executed it. If the agent acted because a workflow, permission set, routing rule, memory state, or delegated token allowed it, the owning team is the one responsible for that control. In practice, this is usually shared across AI platform, IAM, and security operations.

That shared model matters because agent behaviour is rarely a single-team problem. One team may own authentication and entitlements, another may own tool access and runtime policy, and a third may own logging or incident response. The accountability answer should follow the control boundary, the approval boundary, and the place where escalation can actually stop unsafe action.

For a useful operating model, define who owns the agent, who approves its access, who monitors its actions, and who can revoke it quickly. If those responsibilities are split, the split should be explicit, documented, and tested before the agent is allowed to operate in a production workflow.

How do teams decide the right accountability boundary?

Start by asking which mechanism enabled the action. If the issue was excessive permissions, the IAM owner is accountable for access design and review. If the issue came from the agent selecting the wrong tool, wrong route, or wrong memory context, the AI platform owner is accountable for orchestration and guardrails. If the issue is missed detection, weak auditability, or delayed response, security operations needs clear ownership of monitoring and escalation.

The cleanest test is simple: if you remove the control point, does the answer change? A delegated action token, an approval gate, a policy decision, or a memory reference can all be the real control point. When that happens, accountability should sit with the team that governs that control, even if another team “owns the agent” in a product sense.

This is why mature organisations use shared RACI-style ownership rather than a single blanket owner. It avoids the common failure where IAM believes the AI team owns behaviour, while the AI team assumes IAM will police privilege. The result is a gap exactly where high-risk agent action needs a clear stop rule.

What does good shared ownership look like in practice?

Good shared ownership separates platform responsibility from approval responsibility and response responsibility. The AI platform team should own the agent runtime, routing logic, memory design, and tool orchestration. IAM should own identity, delegated access, and privilege boundaries. Security operations should own monitoring, alert triage, and incident escalation for suspicious or out-of-policy actions.

To make that structure operational, AI Agent Authorisation Guide is useful for the per-action policy and least-privilege side, while AI Agent Observability, Audit and Incident Response Guide helps define what must be logged, attributed, and escalated when an agent crosses a boundary.

For organisations building the wider operating model, Identity Security Programme Guide is a good reference for RACI, governance, and programme ownership across human, non-human, and AI agent identities. It helps prevent accountability from being trapped inside one team when the risk spans several.

Risk and Threat Considerations

When accountability is unclear, unsafe agent actions tend to move faster than the organisation can stop them. That creates both governance risk and security exposure: excessive privilege may go unreviewed, delegated access may outlive its purpose, and logging gaps may prevent teams from proving which control actually allowed the action.

Failure mechanism: The agent executes under valid authority, but no single team owns the permission source, the workflow rule, and the runtime guardrail together. That split lets dangerous actions slip through approval, attribution, or revocation gaps.

Impact: The organisation can end up with delayed containment, disputed accountability, weak audit evidence, and a larger blast radius if the agent’s access is reused, inherited, or not revoked quickly after abnormal behaviour.

Practitioner Guidance

What to verify: Make sure every high-risk agent action has a named owner for access, a named owner for orchestration, and a named responder for abnormal behaviour. If any of those are missing, the accountability model is incomplete even if the agent technically “works.”

Decision rule: If the action came from permissions, delegation, or entitlements, start with IAM ownership. If it came from routing, memory, or tool choice, start with AI platform ownership. If it was detected late or not at all, treat that as a security operations ownership gap as well.

Common mistake: Treating “the agent did it” as an accountability answer. That hides the real control failure and usually leads to either over-restricting the agent or under-owning the permission and monitoring layers that enabled it.

Practitioner takeaway: Accountability should follow the governing control, not the runtime actor alone, and the strongest operating model is the one that makes escalation and revocation obvious before a risky action is ever permitted.

Related resources from NHI Mgmt Group

• How do IAM and NHI teams decide which agent actions need stronger controls?
• How do IAM teams decide whether an AI agent needs new controls?
• How do IAM teams decide whether an AI agent needs runtime policy enforcement?
• How do IAM teams decide whether an AI agent should be treated like an NHI?