Who is accountable when AI platform activity cannot be tied to a person or approved scope?

Why This Matters for Security Teams

When AI platform activity cannot be tied to a person or approved scope, the issue is not only attribution. It is evidence that the organisation has allowed an execution path to exist without a defensible identity chain, approval record, or bounded authority. That becomes a governance failure because security teams cannot prove who authorised the action, what the agent was allowed to do, or whether the action stayed inside policy. The OWASP Non-Human Identity Top 10 treats this as a core identity risk, not a logging issue.

This matters because AI platforms often execute across tools, services, and data stores faster than human review can reconstruct. In practice, the question is not whether an operator can later infer intent, but whether the system can prove it at the moment of execution. NHIMG’s analysis of McKinsey AI platform breach shows how quickly platform activity becomes a security and accountability problem when scope and ownership are weakly enforced. In practice, many security teams encounter unowned AI activity only after access has already been abused, rather than through intentional governance design.

How It Works in Practice

Accountability for AI platform activity depends on binding every action to a workload identity, an approval context, and a policy decision that can be evaluated at request time. Static role-based access control is usually too blunt for this because agents and AI platforms do not behave like fixed human users. Their tool use is dynamic, goal-driven, and often unpredictable. Current guidance suggests shifting from “who has a role” to “what this workload is allowed to do right now” using workload identity, short-lived credentials, and policy-as-code enforcement.

In mature environments, this usually means the following:

• Issue identity to the workload, not just the operator, using cryptographic proof such as OIDC-bound workload tokens or SPIFFE-style identities.
• Grant NHI permissions just in time, with short TTLs and automatic revocation at task completion.
• Require every privileged action to resolve against a runtime policy engine, such as OPA or Cedar, so the decision reflects current context rather than a stale role assignment.
• Record the approval trail, the originating prompt or task, the workload identity, and the downstream systems touched so investigators can reconstruct scope.

The NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework both support the idea that control evidence must be observable and repeatable, not inferred after the fact. This also aligns with the operational direction in The State of Secrets in AppSec, which highlights how fragmented secrets management weakens centralized control and makes accountability harder to sustain. These controls tend to break down in loosely integrated multi-agent environments because one agent can chain tool calls through another service and obscure the original approval context.

Common Variations and Edge Cases

Tighter accountability controls often increase operational overhead, requiring organisations to balance speed against evidentiary strength. That tradeoff becomes most visible in autonomous workflows, where too much friction can cause teams to bypass the very controls meant to preserve scope. Best practice is evolving, but there is no universal standard yet for how granular attribution must be across multi-agent systems, shared service identities, and delegated approvals.

Some environments also complicate ownership in ways that traditional IAM does not handle well. A shared AI platform may act on behalf of multiple business units, a single task may traverse several agents, or the executing workload may be hosted by a provider with limited local visibility. In those cases, the organisation still remains accountable for defining the control plane, even if the underlying platform is external. The key is to preserve a clear chain from request to identity to approval to action, because without that chain, forensic review becomes guesswork rather than evidence.

NHIMG research on LLMjacking reinforces why short-lived, tightly scoped credentials matter when AI systems can be hijacked and repurposed quickly. When identities are static or overbroad, the same weakness that blocks attribution also expands blast radius.

Related resources from NHI Mgmt Group

• Who should be accountable for AI platform activity in identity governance?
• Who is accountable when an approved AI system drifts from its declared posture?
• Who is accountable for deception controls in AI and NHI programmes?
• Who is accountable when a fraudulent request is approved through a trusted channel?