Who is accountable when agent-based identity controls miss an application?

Accountability sits with the identity and application owners who approved the operating model, not with the agent alone. If an access path is outside coverage, the organisation still owns the governance gap. Frameworks such as NIST Cybersecurity Framework 2.0 help assign responsibility across identify, protect, and govern functions.

Why This Matters for Security Teams

When agent-based identity controls miss an application, the problem is not that the agent “made a mistake.” The real issue is that the organisation approved an operating model with a coverage gap, then assumed policy would catch every access path. That assumption fails quickly when agents chain tools, pivot across APIs, and invoke services outside the original approval boundary. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs.

For security teams, accountability has to be assigned before deployment: identity owners define the control model, application owners define what the application can expose, and governance teams verify that the app is actually in scope. That aligns with the governance emphasis in the NIST AI Risk Management Framework, which treats AI risk as an organisational responsibility rather than a purely technical one. In practice, many security teams encounter missing agent coverage only after an access path has already been used in production.

How It Works in Practice

Effective accountability starts with control ownership, not incident blame. The identity team usually owns the NHI control plane: workload identity, secret issuance, token lifetimes, and policy enforcement. The application owner owns the app surface area: which endpoints exist, which tools the agent may call, and what actions are acceptable. If the app is not covered, the control failure belongs to the operating model, because the environment did not define how that application would be discovered, classified, and brought under policy.

Operationally, teams should map every agent-facing application to a named owner and a control status. That status should answer four questions:

• Is the application in the NHI inventory?
• Does the agent use workload identity or shared secrets?
• Are approvals runtime-enforced or only documented in a ticket?
• What revocation path exists if the app is added late or misclassified?

This is why guidance from the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework matters: they push teams toward runtime controls, least privilege, and explicit trust boundaries for autonomous workloads. The NHI Management Group’s 52 NHI Breaches Analysis reinforces the same lesson: missed inventory and weak ownership are recurring failure points, not edge cases. These controls tend to break down when fast-moving product teams deploy new agent integrations through CI/CD without a security review because the app is never formally added to the identity control boundary.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster delivery against clearer ownership. That tradeoff becomes visible in multi-team environments, where one group runs the agent platform, another owns the application, and a third manages secrets or IAM. In those cases, “who is accountable” should be answered by the control, not by the org chart alone.

There is no universal standard for this yet, but current guidance suggests a few practical patterns. First, if the agent platform team publishes reusable controls, it should own baseline enforcement and exception handling. Second, if an application exposes a new tool or API, the application owner should own its inclusion in the coverage model. Third, if a business unit insists on a custom integration, that unit should own the risk acceptance until the app is brought into standard control.

Edge cases include third-party SaaS apps, shadow AI tools, and legacy systems that cannot support modern workload identity. In those environments, accountability still does not move to the agent. It sits with the organisation that approved use of the app without adequate coverage. Where shared responsibility is unclear, the safest practice is to document the control owner, the approver, and the rollback path before access is granted.

Related resources from NHI Mgmt Group

• How should security teams evaluate agent-based IAM against legacy identity controls?
• Who is accountable when forged session data bypasses application access controls?
• Which identity controls matter most for merchant-side agent integrations?
• Who should own lifecycle controls for agent identity and federation?