AI agents in DTC create governance gaps that IAM teams cannot ignore

At a glance

What this is: This is a practitioner-focused analysis of how DTC companies are using AI agents and where security breaks down when those agents act without sufficient oversight.

Why it matters: It matters because AI agents can touch customer data, invoke tools, and make decisions, which means IAM, PAM, and governance teams need visibility into agent identities and permissions as well as human access.

By the numbers:

• By deploying AI agents across order support and post-purchase flows, DTC brands can cut average handling time by around 25% and automate 80% of routine customer service requests without human intervention.

👉 Read Straiker's blog on how DTC companies are securing AI agents

Context

DTC environments are becoming agent-driven as customer support, recommendations, fulfillment, and post-purchase workflows increasingly depend on systems that can take action rather than only answer questions. That shifts the security problem from simple content moderation to governance of tool use, customer data exposure, and decision boundaries in AI agents.

For IAM and NHI teams, the important change is that these agents behave like operational identities with access to systems, data, and business processes. Once a third-party or internal agent can refund orders, update accounts, or retrieve customer records, access control, auditing, and lifecycle governance become part of the AI control plane, not just back-office identity plumbing.

Key questions

Q: How should security teams govern personal data used by AI agents?

A: Security teams should govern agent access as a runtime control problem, not as a one-time permission decision. Limit the data each agent can reach, bind access to a specific task, and monitor actual behaviour continuously. That approach makes privacy records and IAM controls reflect the same operational reality.

Q: Why do AI agents create more risk than standard chatbots in DTC environments?

A: AI agents create more risk because they can call tools, move data, and take actions, not just generate text. In DTC environments, that can affect orders, customer accounts, and support cases. The risk is compounded when permissions are broad or inherited from third-party platforms that the organisation does not fully control.

Q: What breaks when MCP-connected agents are not tightly governed?

A: When MCP-connected agents are not tightly governed, teams lose visibility into which tools and data sources the agent can reach. That makes least privilege hard to enforce and incident investigation difficult. The result is hidden expansion of delegated access, which can turn a single agent into a broad pathway to sensitive systems.

Q: Who is accountable when a third-party AI agent misbehaves in production?

A: The organisation using the agent remains accountable for the outcomes, even if a vendor supplies the platform. Security, legal, compliance, and business owners should share responsibility for controls, monitoring, and incident response. If the agent can affect customers or regulated data, accountability cannot be outsourced with the technology.

Technical breakdown

Agentic workflows turn customer support tools into access-bearing identities

An AI agent is not just a chatbot with a better interface. In the DTC use case, it can call APIs, update accounts, issue refunds, and escalate cases, which means it operates with a defined set of permissions and execution paths. That creates an identity problem because the agent needs authentication, authorisation, and auditability, just like any other workload or service account. The risk grows when permissions are broad, opaque, or inherited from a third-party platform without clear ownership.

Practical implication: treat each customer-facing agent as an identity with explicit scope, not a feature inside a product.

MCP servers and third-party integrations expand the agent attack surface

The article points to local MCP servers as a common integration layer for connecting agents to tools and data. MCP, or Model Context Protocol, standardises that connection, but it also concentrates risk if the server can reach sensitive systems without strong governance. In practice, the agent is only as safe as the tool endpoints, prompts, and access policies around it. If those controls are weak, attackers can misuse the agent’s delegated capabilities or tamper with instructions to trigger unsafe actions.

Practical implication: inventory every MCP-connected tool and enforce least privilege at the integration layer.

Guardrails matter because security failures are often runtime failures

The article shows why pre-deployment testing alone is not enough. AI systems can behave safely in a lab and still drift, leak, or overreach in production when exposed to real prompts, languages, and customer behaviour. Runtime guardrails, monitoring, and alerting are therefore part of the control stack, not optional enhancements. For DTC teams, the hard problem is sustaining visibility into what agents are doing across multiple journeys and languages while preserving business speed.

Practical implication: combine testing, monitoring, and policy enforcement so agent behaviour is controlled after go-live, not only before it.

Threat narrative

Attacker objective: The attacker’s objective is to abuse the agent’s delegated authority to manipulate customer workflows, extract data, or create operational and reputational harm.

1. Entry occurs when a DTC organisation connects an AI agent to customer workflows or third-party conversational platforms with broad delegated access.
2. Escalation happens when the agent can call tools, retrieve data, or execute actions without tight scope controls, allowing misuse of its delegated permissions.
3. Impact follows when the agent refunds purchases, exposes system prompts, leaks customer data across sessions, or makes unsafe brand and compliance decisions.

NHI Mgmt Group analysis

AI agents in DTC are becoming operational identities, not just interfaces. Once an agent can issue refunds, update accounts, or pull customer records, it inherits identity risk that conventional application controls do not fully describe. That makes lifecycle ownership, entitlement scoping, and auditability central governance questions for both IAM and NHI programmes. Practitioners should stop treating agents as mere application features and govern them as access-bearing systems.

Agentic access creates a trust gap when third-party platforms speak for the brand. The article’s first storyline shows the core problem: organisations often assume a hosted AI layer will remain within acceptable behavioural bounds without proving it. That assumption breaks when customer interaction quality, prompt leakage, and compliance obligations all sit outside the organisation’s direct control. The practical conclusion is that third-party AI needs the same scrutiny as any privileged outsourced function.

Low visibility into MCP-connected tools is a governance debt that grows with every deployment. MCP standardises connectivity, but standardisation does not equal control. If security teams cannot inventory which tools, data sources, and execution pathways an agent can reach, they cannot enforce least privilege or investigate misuse. This is where NHI governance intersects with AI governance: every delegated tool connection needs an accountable owner, a defined purpose, and a revocation path.

Runtime protection is now the difference between tested safety and actual safety. Red teaming finds failure modes, but it does not prevent a production agent from drifting into unsafe tool use or inappropriate data access. That is why this topic belongs in broader control frameworks such as NIST AI Risk Management Framework and OWASP Agentic AI Top 10. The field is moving toward continuous assurance, and practitioners should expect runtime policy enforcement to become a baseline expectation.

Agent sprawl creates the same visibility problem the industry already knows from NHIs. The article’s closing point is familiar to identity teams: you cannot govern what you cannot inventory. The difference is that AI agents can scale faster, interact through more languages, and execute across more tools than many traditional service accounts. That makes an explicit agent inventory and ownership model the minimum viable control for any programme that takes identity governance seriously.

What this signals

AI agent rollouts are moving faster than governance models that were designed for application accounts and human approvals. In DTC environments, that creates a structural problem: the business wants autonomous execution, while security still needs provable limits on what each agent can see, call, and change. The organisations that get ahead will build an agent inventory, owner model, and revocation path before scale turns into sprawl.

Agent identity sprawl: every new workflow, language, or integration adds another delegated access path that must be governed. That is the same pattern identity teams already see with NHIs, but AI agents compress the timeline and widen the blast radius. Practitioners should align agent governance with NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, then tie it back to identity lifecycle controls.

For practitioners

• Create an inventory of every customer-facing agent and tool connection Document each AI agent, its business purpose, the systems it can call, the data it can access, and the human or team accountable for it. Include third-party platforms and local MCP servers in the same register so the organisation has a single source of truth for delegated access.
• Apply least privilege to agent permissions and MCP endpoints Review whether each agent needs write access, refund authority, account mutation rights, or read access to customer data. Remove broad permissions by default and separate high-risk actions into distinct workflows that require stronger approval or tighter runtime policy.
• Use runtime guardrails alongside red team testing Test agent behaviour before launch, then monitor tool use, prompt tampering, data leakage, and policy violations in production. Pair detection with blocking controls so the environment can stop unsafe actions, not just alert on them after the fact.
• Define offboarding and revocation paths for every agent If an agent, integration, or vendor relationship is retired, revoke credentials, disable tool access, and remove residual permissions immediately. Treat this as identity lifecycle management for a non-human identity rather than as a generic application change.

Key takeaways

• AI agents in DTC are not just automation layers, they are access-bearing systems that can affect customer data, orders, and brand outcomes.
• The article shows that the biggest risk is not adoption itself, but unmanaged delegation through third-party platforms, MCP connections, and weak runtime visibility.
• Security teams should inventory, scope, monitor, and revoke agent access with the same discipline they apply to high-risk non-human identities.

Key terms

• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

Straiker's full blog covers the operational detail this post intentionally leaves for the source:

• The three front-line DTC examples with the exact failure patterns seen in production AI deployments.
• The red-team and runtime-guardrail controls used to test and contain unsafe agent behaviour.
• The MCP governance and visibility measures applied to enterprise AI integrations.
• The practical differences between testing-only, protection-only, and combined approaches.

👉 Straiker's full post covers the three DTC examples, guardrail setup, and MCP governance details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners apply lifecycle thinking to non-human access across modern programmes.