Organisations should treat customer-facing AI agents as identity and API problems, not just chatbot problems. Put strong authentication, scoped authorisation, data minimisation, and API governance in place before production use. The agent should only access the data and actions needed for the task, with logging and monitoring that can detect misuse, policy drift, and suspicious customer account activity.
Why This Matters for Security Teams
Customer-facing AI agents are not just conversational interfaces. They are execution points that can retrieve account data, trigger workflows, and expose sensitive information if their identity, permissions, and data pathways are not tightly constrained. The main risk is not a bad answer in isolation. It is the combination of prompt injection, overbroad API access, and weak fraud controls that turns a helpful agent into an untrusted automation layer.
That is why guidance from the OWASP Top 10 for Agentic Applications 2026 and NHIMG research on OWASP Agentic Applications Top 10 both emphasize runtime control over static trust assumptions. In practice, a customer agent may be asked to verify identity, summarize account history, or execute a transaction in the same session, which means one missed authorization boundary can become a fraud event or privacy incident. The security team’s job is to make sure the agent never gets more trust than the specific task requires.
NHIMG research in the AI Agents: The New Attack Surface report found that 33% of organisations say AI agents have already accessed inappropriate or sensitive data beyond intended scope. In practice, many security teams encounter abuse only after a customer complains, rather than through intentional policy testing.
How It Works in Practice
The safest pattern is to treat the agent as a constrained workload with narrow, auditable rights, not as a general-purpose assistant. Start with strong customer authentication, then bind the agent to a small set of allowed actions and data classes. Use scoped tokens for each transaction, enforce step-up checks for sensitive operations, and require the agent to call approved APIs rather than directly touching back-end systems. The goal is to make every request observable, policy-checked, and revocable.
Current best practice is to combine identity, policy, and telemetry:
- Use workload identity for the agent itself, so the system can prove what the agent is before it is granted access.
- Issue just-in-time credentials that expire quickly and are revoked when the task ends.
- Apply data minimisation so the agent only receives the minimum customer context needed to complete the request.
- Evaluate policy at runtime, not just at deployment, so risky requests can be blocked in context.
- Log prompts, tool calls, data returns, and high-risk decisions for fraud review and incident response.
For implementation, the NIST AI Risk Management Framework is useful for structuring governance, while NIST SP 800-53 Rev 5 Security and Privacy Controls supports access control, audit logging, and system monitoring. NHIMG’s Moltbook AI agent keys breach shows why long-lived agent keys are dangerous: once exposed, they can be reused across sessions, customers, and downstream tools. These controls tend to break down when customer service flows rely on legacy back-end systems that cannot enforce per-request authorization or produce reliable audit trails.
Common Variations and Edge Cases
Tighter controls often increase customer friction and operational overhead, so organisations have to balance fraud reduction against usability and support cost. That tradeoff is especially visible when the agent handles refunds, account changes, password resets, or payment-related actions, where step-up verification can interrupt the flow but is still necessary.
There is no universal standard for this yet, but current guidance suggests treating high-risk actions differently from low-risk informational queries. A customer can ask an agent for store hours without extra friction, but the same agent should not move money, change bank details, or reveal full account records without stronger verification and explicit policy checks. This is also where fraud teams need to be involved early, because attackers often use conversational systems to probe for account recovery paths, social engineering opportunities, or token leakage.
Two external references are especially relevant here: the Anthropic report on AI-orchestrated cyber espionage and the CSA MAESTRO agentic AI threat modeling framework, both of which reinforce that autonomous tool use changes the threat model. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio also illustrates a common edge case: an agent can become a credential harvesting path if its tools, connectors, or consent flows are too permissive.
Related resources from NHI Mgmt Group
- Why do customer-facing AI agents create fraud risk in refund workflows?
- How should organisations build IAM to support AI agents, contractors, and mobile workers without increasing risk?
- How should organisations share fraud intelligence across institutions without exposing customer data?
- How should organisations train employees to use public AI tools without exposing sensitive data?
