Who should be accountable for AI agent access and fraud controls across security, identity, and business teams?

Why This Matters for Security Teams

Accountability for AI agent access and fraud controls fails when it is treated as a pure identity problem or a pure business process problem. Autonomous agents can invoke tools, request secrets, move between systems, and trigger transactions without the predictable patterns that standard role models assume. That means security teams, identity teams, and business owners all hold partial control, but none can safely own the full risk alone.

The practical issue is not just who approves access, but who can stop misuse fast enough when an agent behaves unexpectedly. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point to shared governance, but shared governance only works if accountability is explicit. NHIMG’s Ultimate Guide to NHIs reinforces that these identities need owner mapping, lifecycle controls, and monitoring aligned to real operational risk.

NHIMG research also shows how thin confidence remains in practice: only 1.5 out of 10 organisations are highly confident in securing NHIs. In practice, many security teams encounter agent abuse only after an approval path, data access path, or billing workflow has already been exploited, rather than through intentional control testing.

How It Works in Practice

Effective accountability starts with separating three responsibilities. Security owns the control standard: logging, fraud detection thresholds, anomaly response, and containment. Identity teams own how the agent is represented to systems: workload identity, secrets handling, token lifecycle, and least-privilege access boundaries. Business owners own the agent’s purpose, acceptable actions, data exposure, and the fraud scenarios that matter most to customers and operations.

That division becomes operational when it is translated into approvals, reviews, and escalation paths. The agent should not receive broad standing access just because a business process needs speed. Instead, current best practice is moving toward runtime authorization, just-in-time credentials, and short-lived secrets issued only for the task at hand. For implementation detail, OWASP Non-Human Identity Top 10 is useful for identity lifecycle concerns, while CSA MAESTRO agentic AI threat modeling framework helps teams map control ownership to agent behaviour and misuse paths.

• Security defines fraud indicators, alerting, and incident response criteria.
• Identity enforces workload identity, credential expiry, and access revocation.
• Business approves intended outcomes, data classes, and customer-impacting actions.
• All three teams should review agent logs and control exceptions together on a fixed cadence.

For a practical reminder of how quickly exposed credentials are abused, NHIMG’s LLMjacking analysis shows attackers move fast once secrets are exposed. These controls tend to break down in environments where agents can chain multiple tools across separate owners because no single team can see the full transaction path.

Common Variations and Edge Cases

Tighter accountability often increases approval overhead, requiring organisations to balance faster agent execution against stronger fraud resistance. That tradeoff is especially visible when an agent supports revenue operations, customer support, or finance workflows, where business teams want speed but security teams need strong guardrails.

There is no universal standard for this yet, but current guidance suggests that the accountable business owner should not be the same person who configures the technical controls. That separation reduces blind spots when an agent has legitimate access but still behaves fraudulently. Where agents are embedded in third-party platforms or delegated OAuth flows, ownership becomes harder because access may be controlled outside the core identity stack. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that gaps often emerge at integration boundaries, not only in the agent itself.

For highly autonomous systems, the accountability model should also include a named risk owner who can suspend the agent, revoke credentials, and approve containment actions without waiting for cross-functional consensus. That matters most when the agent has write access, financial authority, or access to customer records. In those cases, teams should treat the agent like a high-risk workload under continuous review, not a one-time onboarding decision.

Related resources from NHI Mgmt Group

• How should security teams implement PCI DSS identity controls across human, service, and AI agent accounts?
• Who is accountable for protecting identity data when access is granted across partners and internal business units?
• Who should be accountable when fraud, AI security, and compliance controls fail together?
• How should security teams reduce identity risk when access is spread across multiple systems and policies are applied inconsistently?