Accountability should remain with the sponsoring organisation, but operational ownership must be split between the human requester, the platform team that granted access, and the governance team that approved the scope. Frameworks such as the NIST AI Risk Management Framework and Zero Trust Architecture both support that shared accountability model.
Why This Matters for Security Teams
When an employee-facing AI agent makes a risky action, the issue is not just misuse of a tool. It is an autonomous workload acting with execution authority, tool access, and often weakly bounded intent. That makes accountability a governance problem, not a blame-shifting exercise. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points toward shared operational responsibility, but the sponsoring organisation remains the accountable entity for the outcome.
That distinction matters because static RBAC assumptions fail fast in agentic environments. An agent does not follow a neat, predeclared path of access; it chains tools, adapts to context, and may reach systems nobody expected it to touch. In NHIMG’s OWASP NHI Top 10 coverage, this is exactly why identity and authorisation must be treated as runtime controls rather than one-time provisioning decisions. In practice, many security teams encounter the failure only after the agent has already accessed data or executed a harmful action, rather than through intentional testing.
How It Works in Practice
Operationally, accountability should be split across three layers. The human requester owns the intent and must be clear about what the agent is allowed to do. The platform team owns the guardrails, including workload identity, token issuance, logging, and revocation. The governance or risk team owns scope approval, policy standards, and escalation paths. This is consistent with CSA MAESTRO agentic AI threat modeling framework and the direction of the NIST AI Risk Management Framework, both of which treat AI risk as a lifecycle control problem.
For agents, the practical control set is different from human IAM:
- Use workload identity for the agent, not a shared user account, so actions can be tied to cryptographic proof of what the agent is.
- Issue JIT credentials and short-lived Secrets for each task, then revoke them automatically when the task ends.
- Evaluate policy at request time with intent-based authorisation, not only at onboarding time.
- Log every tool call, data access, and privilege change so attribution is possible after a risky action.
- Apply ZTA and ZSP principles so the agent never carries broad standing access by default.
NHIMG research shows why this is not theoretical: the AI Agents: The New Attack Surface report found that 80% of organisations say their AI agents have already acted beyond intended scope. That is why accountability must be operationalised through policy and telemetry, not inferred after the fact. These controls tend to break down when agents are embedded in legacy workflows that still depend on long-lived service accounts and manual approval chains.
Common Variations and Edge Cases
Tighter runtime control often increases friction, so organisations must balance safety against workflow speed. That tradeoff becomes sharper when agents are employee-facing, because users expect fast task completion while security teams need traceability and bounded access. In some environments, current guidance suggests intent-based authorisation is the right model; there is no universal standard for this yet, especially across mixed SaaS, internal APIs, and human-in-the-loop approval steps.
Edge cases usually appear when an agent is allowed to call downstream systems on behalf of a user, when multiple agents share a toolchain, or when Secrets are reused across tasks. A risky action may also be the result of a mis-scoped prompt, not a compromised identity, which is why blame should not stop at the end user. The sponsoring organisation still owns the risk, but the control evidence must show who approved access, who configured the agent, and who monitored the action. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and the DeepSeek breach both reinforce the same lesson: long-lived credentials and weak scope controls turn one agent mistake into a broad enterprise incident.
For highly regulated or high-impact use cases, mature teams increasingly combine NIST Cybersecurity Framework 2.0 governance with agent-specific policy-as-code, but implementation depth varies widely. The safe assumption is simple: if an agent can act independently, accountability must be explicit before it is allowed to act at all.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Defines governance accountability for AI risk across the lifecycle. | |
| OWASP Agentic AI Top 10 | A1 | Agentic risks center on excessive autonomy and tool misuse. |
| CSA MAESTRO | Provides threat modeling for agentic systems and control ownership. |
Assign named owners for agent scope, monitoring, and incident response before deployment.
Related resources from NHI Mgmt Group
- Who is accountable when an AI agent performs an unauthorized action after injection?
- Who is accountable when an AI agent performs an unauthorized action in a SaaS product?
- Who is accountable when an AI agent takes a harmful action in healthcare?
- Who is accountable when an AI agent makes a risky decision?
