Accountability sits with the provider and the operating organisation that chose the control design. If a high-risk system is deployed with only documentation and logging, they are responsible for the gap between intended policy and actual runtime behavior. Under regimes like the EU AI Act, continuous risk management and human oversight require active controls, not archival records alone.
Why This Matters for Security Teams
When runtime AI controls are missing, accountability does not disappear into the model. It stays with the provider that shipped the system and the operating organisation that accepted a high-risk deployment without enforcing runtime policy. Documentation, logging, and post-incident review help, but they do not substitute for active control at the moment the system acts. That distinction is central in high-risk AI governance and in the NIST Cybersecurity Framework 2.0, which treats control execution as part of operational risk, not paperwork.
For NHI and agentic systems, the gap is sharper because the identity is not just a user, it is an autonomous workload with tool access, secrets, and execution authority. NHIMG has shown how often security confidence outruns actual control depth in practice, especially when secrets and access paths are fragmented across environments, as discussed in The State of Secrets in AppSec. The same pattern applies to AI controls: if runtime authorisation is missing, the system can still chain actions, call tools, and expose data even when policy says it should not. In practice, many security teams discover this only after a harmful action has already been executed, rather than through intentional testing.
How It Works in Practice
Accountability is usually shared across the parties that made the control decision. The provider is accountable for the system design, the operating organisation is accountable for deployment choices, and both may be exposed when the system is placed into a high-risk environment without runtime enforcement. Under current guidance, the question is not whether policy existed, but whether it was evaluated at the point of action. That is why NIST Cyber AI Profile (IR 8596) is useful here: it moves attention toward operational controls, monitoring, and governance for AI systems that can affect real-world outcomes.
In practice, effective accountability mapping starts with three checks:
- Who approved the deployment of the high-risk system, and with what control assumptions?
- Which runtime controls existed for authorisation, human override, and escalation prevention?
- Which team owned evidence that those controls were actually enforced, not merely described?
For NHI and agentic workloads, this usually means moving from static approval records to enforceable runtime controls such as policy-as-code, short-lived credentials, and workload identity. The Top 10 NHI Issues page is a useful reference point for the recurring failure modes: overprivileged identities, weak rotation discipline, and gaps between intended policy and actual access. Where runtime checks are absent, the organisation can still be responsible even if the vendor supplied a technically capable system, because the deployment decision accepted a known control gap. These controls tend to break down when a system is integrated into legacy workflows that lack request-time policy enforcement and no team owns live override authority.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance speed of deployment against the cost of continuous enforcement. That tradeoff matters because not every AI system carries the same risk, and current guidance suggests accountability should scale with the harm potential, not with the size of the model alone.
There is no universal standard for this yet, but a few edge cases are clear. If the provider markets a high-risk capability and the operating organisation disables runtime controls for convenience, both can remain accountable because the control gap was intentional. If a third-party integrator strips out guardrails during deployment, accountability may extend to that integrator as well. If a system relies only on audit logs, the organisation may know what happened later, but it still lacks the ability to prevent or constrain harmful action in real time. NHIMG’s OWASP NHI Top 10 research reflects this broader pattern: missing runtime controls are not a documentation problem, they are a governance failure at the point where the identity acts.
For security leaders, the practical test is simple: if the system can take a high-impact action without a live policy decision, accountability is already established, even before an incident occurs.
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, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF governs accountable AI risk management when runtime controls are missing. | |
| NIST CSF 2.0 | PR.AC-4 | Access control gaps map directly to missing runtime enforcement and privilege checks. |
| OWASP Agentic AI Top 10 | Agentic systems fail when runtime guardrails and action controls are absent. | |
| CSA MAESTRO | MAESTRO addresses governance and control of autonomous agent behaviour. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification, not trust based on deployment status. |
Assign owners for AI risk decisions and require live control validation before high-risk deployment.
Related resources from NHI Mgmt Group
- Who is accountable when AI-assisted discovery exposes a high-risk legacy system?
- Who is accountable when a high-risk AI system needs reassessment after a substantial modification?
- Who is accountable when an AI-assisted human risk platform makes an automated intervention?
- When should organisations treat an NHI as a high-priority risk?
