Who should be accountable for AI agent approvals and audits?

Why This Matters for Security Teams

AI agent approvals and audits are not just an access-control issue; they are a governance issue for autonomous software that can act, chain tools, and change state faster than manual review cycles can keep up. That is why accountability should stay with a human owner and the application governance chain, not the agent itself. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward explicit ownership, runtime controls, and auditability because static, role-only models do not describe what a goal-driven agent will do next.

NHIMG research shows why this matters operationally: AI Agents: The New Attack Surface report found that 80% of organisations say their agents have already acted beyond intended scope, while only 44% have policies in place. That gap is exactly where approval ownership gets blurred between IAM, app teams, and compliance. In practice, many security teams encounter audit failure only after an agent has already accessed data or executed actions no reviewer expected, rather than through intentional governance design.

How It Works in Practice

For agentic systems, approvals should be tied to the business owner of the agent’s workflow, the application owner, and the identity governance process working together. The practical model is: the owner defines the use case, security defines the policy, and audit verifies evidence. That means the approval record should state what the agent is allowed to do, what data it can touch, what tools it can call, and who is accountable when behavior drifts.

Static RBAC is usually not enough for autonomous workloads because the agent’s actions are context-dependent. Better practice is evolving toward intent-based authorisation, where policy is evaluated at request time against the task, data sensitivity, and execution context. That approach fits well with CSA MAESTRO agentic AI threat modeling framework, which emphasizes threat paths around tool use, identity, and orchestration.

In implementation terms, teams should require:

• JIT credential provisioning with short TTLs, so the agent gets access only for the task at hand.
• Workload identity for the agent, so its identity is cryptographic and auditable rather than implied by a shared service account.
• Policy-as-code checks at execution time, not just a one-time approval ticket.
• Immutable logs that connect the human approver, the agent action, and the data or system touched.

This is also where NHI controls matter. NHIMG’s NHI Lifecycle Management Guide and OWASP NHI Top 10 both reinforce that approvals, secrets, and audits must be lifecycle-managed, not treated as one-off onboarding events. These controls tend to break down when agents share long-lived credentials across multiple tools because attribution and revocation become unreliable.

Common Variations and Edge Cases

Tighter approval and audit controls often increase operational overhead, so organisations have to balance speed against governance depth. That tradeoff becomes sharper when the agent is embedded in customer support, software delivery, or security operations, where legitimate actions happen frequently and delays can hurt service quality.

There is no universal standard for this yet, but current guidance suggests a few patterns. First, high-risk agents should have named human owners, not generic team ownership, because audit questions eventually need a clear accountable subject. Second, shared or delegated approvals can work for low-risk automation, but they should still resolve to a single recordable owner. Third, long-lived secrets should be avoided for agent paths; if a system still relies on static keys, then audit quality will lag behind execution speed, and compromise response will be slower.

NHIMG’s AI LLM hijack breach coverage and Top 10 NHI Issues both show the same edge case: when an agent is allowed to operate across environments, the audit trail often spans multiple systems that do not share the same identity model. That is where approval ownership must stay anchored to the application and data steward, while the agent remains only the executor, not the accountable party.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent changes prices or processes a refund incorrectly?
• Who is accountable when an AI agent makes a risky decision?
• Who is accountable when an AI agent misuses Slack access?
• Who is accountable when an AI agent causes a clinical access problem?