Agentic AI systems deployed across CX platforms operate with identity and access controls designed for static, predictable workloads—a fundamental mismatch that creates exploitable security gaps. Unlike traditional service accounts or human users, AI agents authenticate, receive permissions, call APIs, and trigger workflows with autonomy that scales at machine speed, yet most organisations have no inventory of which credentials these agents hold, who owns them, or what they're authorised to do. The problem compounds because agents arrive through multiple channels: embedded quietly into SaaS platforms like Zendesk and Salesforce, built by internal teams during rapid experimentation, or delegated permissions by individual users without central oversight. This creates shadow AI sprawl that security teams cannot see, let alone govern—and as the Taipei Metro case demonstrates, attackers are already exploiting these blind spots to manipulate systems and spread threats through customer-facing channels.
The core vulnerability lies in how organisations grant access to agents. Traditional least-privilege models assume static roles and predictable behaviour, but an agent handling ticket summarisation requires different permissions than one authorised to issue refunds or modify customer records. Most teams take shortcuts during development—embedding API tokens directly into workflows, granting admin rights to SaaS connections, or using shared credentials—creating identity debt that accumulates at scale. When an agent can read untrusted customer input and also take privileged action, prompt injection becomes a viable attack vector; attackers need not compromise traditional accounts if they can simply influence what an overprivileged agent can access. For CX teams already running agents within Zendesk, Salesforce, or similar platforms, the question is not whether this risk exists in your environment—it almost certainly does—but whether you have visibility into which agents hold which credentials and whether those permissions are actually necessary for their stated purpose.
The path forward requires reframing agentic AI governance as an identity problem, not an AI problem. Each agent needs a distinct identity with a defined owner, business purpose, approved scope, and lifecycle—not shared accounts or borrowed human credentials. Access should be contextual and time-bound, expiring when no longer needed, and governance must be automated rather than manual, discovering new agents, classifying their access, detecting risky permission paths, and enforcing policy without waiting for quarterly reviews. This demands a shift from centralised security bottlenecks to decentralised control with centralised policy: teams can build and deploy agents quickly, but within guardrails that enforce identity, access logging, and revocation capabilities. Organisations that treat this as a separate AI security initiative will fail; those that embed identity-centric controls into how agents are built, deployed, and monitored will maintain both innovation velocity and control.
AI agents can access data, trigger workflows, and take action across enterprise systems. Token Security explains why governing these privileged identities is becoming essential for enterprise security. [...]