Who is accountable when NHIs used by AI agents are not tracked or secured properly?

Accountability sits with the organisation that deploys the agents and the teams that approve their access, typically IAM, security architecture, and the business owner of the workflow. If no one owns inventory, privilege review, and revocation, NHI sprawl becomes a governance failure. Clear ownership, auditability, and control standards are required before AI agents are scaled.

Why This Matters for Security Teams

When NHIs are used by AI agents, accountability is not just about inventorying tokens or keys. It is about who approved autonomous access, who can prove the agent’s identity at runtime, and who is responsible when the agent chains tools beyond its original task. Static ownership models often fail because agent behaviour is dynamic, context-driven, and harder to predict than human workflows.

This is why current guidance around OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework places emphasis on governance, traceability, and operational controls rather than simple credential custody. The practical issue is not whether an NHI exists, but whether the organisation can explain its use, constrain its scope, and revoke it quickly when the agent changes behaviour.

NHIMG research shows the gap is already material: in The State of Non-Human Identity Security, only 1.5 out of 10 organisations were highly confident in securing NHIs, while 45% cited lack of credential rotation as the top cause of NHI-related attacks. In practice, many security teams discover this ownership gap only after an agent has already been granted broad access and used it in ways no one expected.

How It Works in Practice

Accountability should be assigned across three layers: the business owner of the workflow, the technical team that provisions the NHI, and the security function that enforces policy and auditability. For autonomous agents, the control question is not simply “who owns the secret?” but “who can prove what the agent was allowed to do, when, and under what context?” That is why the emerging model relies on workload identity, short-lived credentials, and policy decisions made at request time.

In practice, security teams should treat the agent as a workload with its own identity, not as a person borrowing a service account. Standards such as MITRE ATLAS adversarial AI threat matrix and CSA MAESTRO agentic AI threat modeling framework both reinforce the need to anticipate tool chaining, lateral movement, and misuse of delegated privileges. That means using JIT issuance, tight TTLs, logging that links each action to a specific agent task, and revocation that is automatic at task completion.

• Give each agent a named owner in the business and a technical custodian in IAM or platform engineering.
• Issue short-lived tokens or secrets per task instead of long-lived shared credentials.
• Require policy-as-code checks before each sensitive action, not only at onboarding.
• Log the agent identity, task context, and approval chain for every privileged request.

NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs highlights how quickly exposed cloud credentials are abused, with attacker attempts occurring in an average of 17 minutes. These controls tend to break down when agents share legacy service accounts across multiple tools because attribution, revocation, and least privilege all become ambiguous.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, so organisations have to balance speed of agent deployment against the cost of continuous control. There is no universal standard for this yet, but current guidance suggests that high-risk workflows need stronger ownership, narrower scopes, and faster revocation than low-risk automations.

One common edge case is delegated SaaS access through OAuth, where the business owner assumes the vendor or platform team is responsible while the IAM team assumes the workflow owner is accountable. That handoff gap is exactly where NHIs go untracked. NHIMG research notes that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes accountability incomplete even when the NHI technically exists.

Another exception is multi-agent systems, where one agent can create or invoke another. In those environments, the accountable party is still the deploying organisation, but operational responsibility may need to be split across platform, security, and product teams. The practical test is simple: if no one can answer who approved access, who monitors use, and who revokes it after completion, the control design is not mature enough for scale. For broader context, the OWASP NHI Top 10 and the NIST AI Risk Management Framework both point toward continuous governance, not one-time approval.

Related resources from NHI Mgmt Group

• Who is accountable for AI policy decisions when gateway enforcement is used across models and agents?
• Why do AI agents increase compliance and breach investigation risk when access is not fully tracked?
• Who is accountable when a high-risk SaaS or AI tool is used without documented purpose or review?
• Who should be accountable for access reviews on Azure AI Foundry agents?