What should IAM and security leaders do when AI agents start interacting with customers and business systems?

Leaders should define a clear operating model for agentic access, including ownership, approval boundaries, and monitoring responsibilities across identity, security, and application teams. They should also decide which journeys can safely include AI agents and which require tighter controls or human review. The right model preserves personalization while keeping trust boundaries visible and enforceable.

How Should Leaders Set the Operating Model for AI Agents?

When AI agents are allowed to interact with customers or business systems, the first job is to make the operating model explicit. That means assigning an owner, defining who can approve access and actions, and deciding which team monitors behavior at runtime. The architecture should make it clear when the agent may act independently and when it must pause for review.

AI agents usually fail in organisations that treat them as a feature instead of an actor with bounded authority. The practical difference is that an agent can carry context across steps, invoke tools, and complete actions that affect customers or records, so the governance model has to cover both access and accountability, not just user experience.

That is why a useful operating model separates product decisions from security decisions. Product and application teams decide where the agent belongs in the journey, while identity and security teams define what the agent may touch, how approval works, and what signals prove the action was legitimate.

Where Should Human Review Still Stay in the Loop?

Not every customer or business journey should be fully agent-led. Leaders should identify the points where the risk of incorrect action, misrepresentation, or policy breach is high enough that human review remains the safer control. A good rule is to keep humans involved where the agent can create external commitments, change customer state, or trigger material business impact.

This is less about distrusting automation and more about matching control strength to consequence. A low-risk routine task may be suitable for direct agent action, but a journey that affects payments, entitlements, complaints, regulated disclosures, or irreversible changes deserves tighter oversight and clearer escalation paths.

Leaders should also expect the boundary to shift over time. As the agent proves reliable in a narrow workflow, some review points can be reduced, but only if the organisation can still explain what the agent saw, what policy it followed, and why the action was allowed.

What Needs to Be Visible Before You Scale Agentic Access?

Before scaling, leaders need visibility into the full agent path, not just the final output. That includes who or what the agent is acting on behalf of, which systems it can reach, which tools it can invoke, and where approval or policy enforcement occurs. If those boundaries are hidden, the organisation will struggle to investigate errors, prove compliance, or contain misuse.

Visibility also needs to include action-level monitoring. A control that only records login events will miss the more important question: what did the agent actually do after authentication? That is why runtime logging, action attribution, and access reviews matter when agents move from internal pilots into customer-facing or business-critical flows.

For leaders, the scaling test is simple. If the business cannot quickly answer whether an agent action was permitted, expected, and attributable, then the operating model is not ready for broader use. AI Agent Authorisation Guide is a useful reference point for task-scoped access, delegated authority, and human approval boundaries. AI Agent Observability, Audit and Incident Response Guide is the natural companion for logging, attribution, and response readiness. Zero Trust for AI Agents reinforces the need to verify the principal and the request before every meaningful action.

Risk and Threat Considerations

When agents can interact with customers or business systems, the main risk is not only bad output, but bad action. Overbroad permissions, weak approval boundaries, or poor monitoring can let an agent create account changes, expose data, or trigger workflows the business did not intend. Attackers may also try to abuse the agent’s trusted position to obtain consent, move through systems, or extract tokens and other secrets.

Failure mechanism: The control breaks when the agent is granted standing access or delegated authority without tight action scoping, so a compromised prompt, malicious input, or confused-deputy path turns a helpful workflow into an execution channel.

Impact: The result can be customer harm, unauthorized business actions, data exposure, and a loss of trust in both the channel and the control environment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agents acting for customers or systems need bounded authority and approval.
Recommendation — Enforce per-action authorization and narrow agent privilege before exposing business actions.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Agent journeys depend on limiting what the agent can reach or change.
	AU-6 — Audit Record Review, Analysis, and Reporting	Agent actions must be attributable and reviewable at runtime and after incidents.
Recommendation — Restrict agent permissions to the minimum needed for each approved journey. Review agent audit trails for unauthorized or unexpected actions.
NIST Zero Trust (SP 800-207)	JIT — Just-In-Time Access	Agent access should be granted only when needed for a specific action or session.
Recommendation — Use just-in-time access for agent actions that do not need standing privilege.
ISO/IEC 27001:2022	A.8.2 — Privileged access rights	Operating models for agentic access must govern elevated access and approvals.
Recommendation — Define approval and review rules for any privileged agent access.

Practitioner Guidance

What to prioritise: Start with journeys that have clear business value but limited blast radius, then expand only after the approval model, logging, and rollback path are proven. Do not begin with the most sensitive customer workflow unless you can show the agent’s actions are tightly bounded.

Decision rule: If the agent can change customer state, move money, or touch regulated records, require explicit ownership, per-action authorization, and a documented exception path before go-live. If you cannot explain who approves the action and who reviews it after the fact, the control design is incomplete.

What to verify: Confirm that runtime logs show the actor, the request, the tool call, the approval decision, and the resulting system change. The evidence should make it possible to reconstruct whether the agent acted within its intended authority.

Practitioner takeaway: The right operating model is not “let the agent act” or “keep humans on everything”, it is to make agent authority narrow, observable, and reversible wherever the business consequence is material.