Why can AI in customer support increase workload instead of reducing it?

When support becomes faster and easier to use, more customers submit requests that they would previously have delayed or avoided. That demand expansion can outweigh efficiency gains. The result is a higher inbound volume, more edge cases, and greater pressure on escalation and exception handling.

Why This Matters for Security Teams

Customer support AI changes demand patterns, not just handling time. When responses become instant, customers submit more tickets, more complex follow-ups, and more “just one more thing” requests that human agents still need to resolve. That means the workload often shifts from simple deflection to exception handling, quality review, and escalation management. NHI controls matter here because support bots, retrieval services, and backend APIs all depend on machine credentials that can amplify operational load if they are poorly governed.

This is not theoretical. NHIMG research shows that 66% of organisations say current tooling is not adequate to manage machine identities at scale, and 61% still rely on spreadsheets or manual tracking in practice, as noted in The Critical Gaps in Machine Identity Management report. When the support stack expands, identity sprawl and weak ownership follow quickly. In practice, many security teams encounter the real cost only after bot traffic, API retries, and escalation loops have already increased incident volume rather than reducing it.

How It Works in Practice

The workload increase usually comes from three places. First, automation lowers friction, so customers open cases they would previously have postponed. Second, AI handles the easy tier of requests, which leaves more ambiguous and emotionally charged cases for people. Third, if the agent is connected to internal tools, it can create more downstream activity by triggering refunds, resets, lookups, or handoffs that require review.

From a governance perspective, support AI should be treated as an autonomous workload with its own identity, not as a user account. Best practice is evolving toward workload identity, short-lived credentials, and runtime policy checks rather than static RBAC assumptions. The SPIFFE workload identity specification is relevant because it focuses on cryptographic proof of what the workload is, while NHIMG’s Guide to SPIFFE and SPIRE explains how that model supports stronger service-to-service trust. For customer support systems, this usually means issuing per-task credentials, limiting tool scope to the exact action needed, and revoking access when the conversation or job ends.

• Use intent-based authorization so the agent can only perform the next approved step.
• Issue JIT secrets with short TTLs rather than shared long-lived API keys.
• Separate read, write, and escalation paths so a support model cannot self-approve privileged actions.
• Log every tool call, customer context, and escalation trigger for review.

That pattern reduces blast radius, but it does not eliminate operational overhead. These controls tend to break down when support workflows are highly fragmented across legacy ticketing systems, because the identity boundary is no longer clear and policy enforcement becomes inconsistent.

Common Variations and Edge Cases

Tighter support controls often increase coordination cost, requiring organisations to balance customer speed against approval depth and auditability. The tradeoff is most visible in high-volume environments where AI is expected to both answer and act. If the agent can issue refunds, reset accounts, or modify records, a simple deflection metric can hide a growing governance burden.

There is no universal standard for every support scenario yet, but current guidance suggests using different controls for different risk tiers. Low-risk FAQ flows can tolerate broader automation, while account changes, payment actions, and identity recovery should use stronger verification and narrower tool access. This is also where static role models fail: support agents do not follow fixed human job patterns, and their behaviour changes with context, prompts, and retrieved data.

For that reason, teams should treat escalation paths as part of the security design, not as an afterthought. The Ultimate Guide to NHIs and Ultimate Guide to NHIs: Standards are useful references when aligning support automation with identity governance. The more a support system can trigger internal action, the more likely it is to create extra review work unless ownership, authorization, and revocation are designed up front.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• What is the difference between workload identity and API keys for AI agents?
• Why do AI agents increase the number of NHIs?
• Why do AI agents increase non-human identity risk?