Who should own governance for customer AI agents?

Why This Matters for Security Teams

Customer AI agents sit at the intersection of identity, product experience, and abuse prevention, which means ownership cannot live in a single silo. IAM can define who or what the agent is, fraud teams can detect suspicious behaviour, digital experience teams can understand customer impact, and application security can assess how the agent chains tools and data. Without shared governance, teams tend to optimise their own slice and miss the combined risk.

The practical challenge is that agents are not static users. They act on intent, change behaviour across sessions, and may access systems that were never designed for delegated machine activity. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward governance that spans technical, operational, and risk functions rather than a narrow access-control model.

NHIMG research on AI agents shows why this matters: 80% of organisations report agents have already acted beyond intended scope, yet only 44% have implemented policies to govern them. In practice, many security teams discover this gap only after an agent has already overreached, rather than through intentional governance design.

How It Works in Practice

Effective ownership for customer AI agents usually works best as a federated model with one accountable lead and several contributing control owners. The accountable group defines the policy state, evidence requirements, and escalation path. Commonly, IAM owns identity proofing and lifecycle controls, fraud owns behavioural abuse signals, digital experience owns product journey constraints, and application security owns tool exposure and failure modes. That division reflects the reality that agent risk is cross-functional, not just a login problem.

Operationally, this means governance must cover the agent as a workload, not as a person. Current best practice is evolving toward runtime authorisation, short-lived credentials, and continuous policy evaluation. For example, an agent may authenticate with workload identity, receive only task-scoped access, and be re-authorised each time it attempts a sensitive action. That approach is consistent with the direction of the CSA MAESTRO agentic AI threat modeling framework and with NHIMG’s coverage of real-world agent abuse in CoPhish OAuth Token Theft via Copilot Studio.

• Define who approves the agent’s purpose, allowed tools, and sensitive data classes.
• Issue task-scoped access with short TTLs instead of durable credentials.
• Log prompts, tool calls, approvals, and data access for audit and fraud review.
• Require kill-switches and step-up review for payment, account recovery, or export actions.

This model also improves incident response because it gives one team clear accountability for policy drift while still preserving specialist input. These controls tend to break down when customer journeys are fully dynamic and product teams can deploy new tools faster than governance review can update policy.

Common Variations and Edge Cases

Tighter governance often slows product experimentation, so organisations have to balance customer friction against abuse resistance. That tradeoff is real, especially when AI agents are embedded in support, commerce, or onboarding flows where speed matters.

There is no universal standard for this yet, but current guidance suggests a few patterns. If an agent only recommends actions, product and UX may own primary oversight, with security providing guardrails. If an agent can take actions on behalf of a customer, governance should shift toward IAM, fraud, and application security with business ownership from the product line. If the agent touches regulated data or payment flows, legal and compliance should be part of the control group from the start.

NHIMG’s The State of Non-Human Identity Security research highlights the broader ownership problem: only 1.5 out of 10 organisations feel highly confident securing NHIs. That confidence gap becomes more pronounced when customer-facing agents can chain tools, access external services, and act outside expected paths. Where this becomes especially hard is high-velocity environments with many product squads, because governance degrades into ad hoc approvals unless a single accountable owner maintains policy consistency.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• Why do AI agents create new risk in non-human identity management?