Who should own approval policy for autonomous agent actions, IAM or application teams?

Why This Matters for Security Teams

Approval policy for autonomous agent actions is not just an access request workflow. It is a control boundary for a workload that can chain tools, change tactics, and act without a human in the loop. That is why the owner of the policy matters as much as the policy itself. IAM can define the identity primitive, token scope, and revocation model, but application teams understand which actions change business state, create fraud risk, or trigger regulatory exposure. The operating model needs both. Current guidance from the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework points toward shared accountability, not a single team owning everything. NHIMG research shows why this urgency is real: 80% of organisations report their AI agents have already acted beyond intended scope, including unauthorised system access and credential exposure in SailPoint’s AI Agents: The New Attack Surface report. In practice, many security teams discover the missing approval boundary only after an agent has already taken an unintended action, rather than through intentional policy design.

How It Works in Practice

The cleanest model is to split ownership by control layer. IAM owns the mechanics of lifecycle governance for NHIs: workload identity, JIT credential issuance, token TTL, key rotation, and revocation. Application teams own action classification: which tool calls, API methods, data domains, or workflow transitions require step-up approval, deny-by-default, or human confirmation. That means policy is evaluated at runtime, not hard-coded into a UI button. For autonomous systems, static RBAC is usually too blunt because the same agent may need different permissions depending on intent, context, data sensitivity, and current task state. A practical implementation usually includes:

• Workload identity for the agent, not a shared user account, so each agent instance can be traced and revoked.
• Short-lived, task-scoped credentials with automatic expiry after completion or timeout.
• Policy-as-code in the dispatch layer, so approval happens before tool execution, not after the fact.
• Risk rules owned by the app team, expressed as action thresholds, data-classification rules, and transaction limits.

Frameworks such as the CSA MAESTRO agentic AI threat modeling framework and OWASP Agentic AI Top 10 both support this runtime-control view, where the authorisation decision is tied to the action and its context. The same pattern is echoed in NHIMG’s OWASP NHI Top 10, especially where excessive privilege and secret exposure become operational failures. These controls tend to break down when teams rely on a shared service account or when the agent can call external tools with inconsistent telemetry, because then approval cannot be evaluated against a trustworthy identity or request context.

Common Variations and Edge Cases

Tighter approval control often increases latency and operational overhead, so organisations have to balance safety against task completion speed. That tradeoff is real, especially for agents handling high-volume internal workflows. Best practice is evolving, but current guidance suggests separating low-risk read actions from high-risk write actions, then using step-up approval only for the latter. For example, retrieving a dashboard metric should not require the same control path as sending money, deleting records, or exporting sensitive data. There is also no universal standard for how much intent context should be exposed to the policy engine. Some teams use coarse rules based on tool name and destination system. Others enrich the decision with prompt intent, data sensitivity, and session history. The stronger pattern is intent-based authorisation, but it requires better telemetry and more mature policy design. NHIMG’s Top 10 NHI Issues and Regulatory and Audit Perspectives both reinforce that auditability matters as much as prevention. For identity architecture, the same principle aligns with NIST AI Risk Management Framework and the NIST Cybersecurity Framework 2.0. The model becomes fragile in multi-agent systems where one agent can hand off work to another and inherit partial context, because ownership of approval policy can blur unless every hop re-evaluates identity, intent, and privilege.

Related resources from NHI Mgmt Group

• Where does cross-environment agent discovery fit in an IAM programme?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?