What should IAM teams do when AI agents spread across multiple functions?

Why This Matters for Security Teams

When AI agents spread across product, cloud, security, and data functions, the main risk is not just fragmented ownership. It is that one function may approve access while another assumes someone else is watching the agent’s runtime behaviour. That gap matters because agentic systems can chain tools, act outside the original request, and retain useful access long enough to create blast radius. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward shared accountability, but they do not replace operational ownership. NHI Management Group’s research on the LLMjacking threat shows how quickly exposed AI-related credentials can be abused in the wild, which turns governance gaps into immediate exposure.

Security teams often discover the problem only after an agent has already touched production APIs, cloud resources, and internal knowledge stores, rather than through intentional cross-functional design.

How It Works in Practice

The practical answer is to treat the agent as a shared workload with a single policy plane and multiple operational owners. That means identity, permissions, logging, secret handling, and lifecycle controls should be governed through a common operating model, even when execution spans several teams. The control objective is not centralisation for its own sake. It is to ensure that every function sees the same identity, the same policy decision, and the same revocation path.

A workable model usually includes:

• one authoritative owner for the agent identity and registration lifecycle
• one policy definition for what the agent may do, evaluated at request time
• separate approvers for application, cloud, and security risk decisions
• short-lived credentials issued only for the task at hand
• shared telemetry that links identity, action, and approval across all functions

For agentic systems, this is where the line between IAM and runtime governance blurs. The identity primitive should be workload identity, not a static human-style account. Standards such as SPIFFE or OIDC-backed service tokens are useful because they prove what the agent is at runtime, while policy-as-code engines can decide whether the requested action fits current context. NHI Management Group’s State of Secrets in AppSec research is a reminder that fragmented secrets management already creates operational drag; that problem becomes more severe when an agent can request, chain, and reuse credentials across functions.

Current guidance suggests using central policy with distributed execution, not distributed policy with fragmented accountability. These controls tend to break down when separate business units deploy their own agent stacks and each stack owns its own secrets, audit logs, and approval rules, because no team can reconstruct the full permission path.

Common Variations and Edge Cases

Tighter cross-functional governance often increases coordination overhead, requiring organisations to balance speed against control fidelity. That tradeoff is especially visible in multi-agent environments, merger scenarios, and platform teams that support both internal and customer-facing agents.

There is no universal standard for how many owners an agent should have, but best practice is evolving toward a small number of named responsibilities: one technical owner, one security owner, and one business risk owner. That model works better than committee ownership because it preserves accountability while still forcing coordination. The CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix both reinforce the need to map threats across the full agent lifecycle, not just at login. For teams comparing controls, the OWASP NHI Top 10 is a useful lens for separating identity abuse from model misuse.

Edge cases appear when an agent is reused across different products, or when a central platform team manages identity while product teams manage prompts and tools. In those cases, governance can fail if the same agent identity is allowed to inherit different privilege sets in different contexts without clear runtime policy boundaries.

Related resources from NHI Mgmt Group

• How should enterprises govern AI agents across multiple clouds and SaaS platforms?
• How should security teams govern AI agent orchestration across multiple systems?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• How should security teams manage permissions for AI agents?