Accountability sits with the organisation that failed to align identity controls, data classification, and operational monitoring. Training helps, but it does not replace governable access decisions, auditable reviews, or containment controls that can prove who touched the data and when.
Why Accountability Does Not Move to the Tool Vendor
When leakage occurs despite training and monitoring, the accountability question usually turns on governance, not intent. Security awareness reduces avoidable mistakes, but it does not create control over who can access data, how long access lasts, or whether activity can be proven after the fact. NHI Management Group’s The State of Non-Human Identity Security shows how often organisations still lack confidence in those controls, even while spending on them.
The practical failure is usually a gap between policy and enforceable identity controls. If a bot, service account, API key, or agent can read sensitive data without tight classification, approval, and logging, leakage is an organisational control failure even when users received training. NIST’s SP 800-53 Rev. 5 makes this clear through access control, audit, and accountability requirements, but many teams still treat monitoring as if it were a substitute for prevention.
In practice, many security teams discover this only after a workflow has already copied, exported, or replayed data through an over-privileged identity rather than through intentional control testing.
How Accountability Is Proved in Practice
Accountability is established by reconstructing who or what had authority, what data was reachable, and whether the access path was appropriate for the task. That means identity records, data classification, approval history, and immutable logs must line up. For non-human identities, this often includes service accounts, OAuth apps, workload tokens, and agent credentials. NHI Management Group’s 52 NHI Breaches Analysis is useful because it shows how frequently leakage starts with weak credential governance, not with a training failure.
Security teams should look for four proof points:
- Was the identity least-privileged for the specific data set?
- Was access time-bound or long-lived?
- Was the activity logged with enough fidelity to identify the action and context?
- Was there a containment control that could have stopped or limited replay, export, or lateral movement?
For agentic workflows, the bar is higher because the actor can chain tools, call APIs, and repeat actions at machine speed. Current guidance suggests using workload identity, short-lived credentials, and policy evaluation at request time rather than relying on broad role assignment. That is consistent with emerging practice in the Anthropic report on AI-orchestrated cyber espionage, where autonomous action made containment and attribution more important than user training alone.
These controls tend to break down in environments with shared credentials, weak log correlation, or data stores that cannot attribute read access to a specific non-human identity.
Where the Shared Responsibility Boundary Gets Messy
Tighter monitoring often increases operational overhead, requiring organisations to balance forensic certainty against system complexity and cost. The hardest cases are usually shared-service environments, outsourced automation, and AI-assisted operations where multiple teams touch the same workflow. In those settings, responsibility can be distributed, but accountability does not disappear: the organisation still owns the control design, the vendor owns only the part they contractually operate, and the platform team owns the identity path.
Best practice is evolving for agentic and automated workloads. There is no universal standard for exactly how much telemetry is enough, but guidance from the NHI Lifecycle Management Guide points toward lifecycle ownership, periodic review, and revocation discipline as the minimum defensible baseline. When the investigation shows that access was too broad, logging was incomplete, or secrets were not rotated, accountability sits with the organisation that approved and operated that setup. Training may explain the event, but it does not excuse the control failure.
The exception is a narrow contractual one: if a third party operated the system and the organisation lacked visibility into its credentials, telemetry, or data handling, then accountability may be shared, but the internal owner still failed to demand and verify the control evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers weak rotation and lifespan of non-human credentials that enable leakage. |
| OWASP Agentic AI Top 10 | A-03 | Agentic systems need runtime controls because behaviour is dynamic and hard to predict. |
| CSA MAESTRO | IAM-2 | Maps to identity governance for autonomous workloads and delegated tool use. |
| NIST AI RMF | AI RMF governance addresses accountability, traceability, and operational oversight. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access enforcement are central when leakage occurs despite training. |
Rotate NHI secrets aggressively and revoke any long-lived credential path that cannot be audited.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
