Because the enterprise still owns the customer relationship, the policy commitments, and the fallout. Hosting does not transfer responsibility for a harmful answer, so the organisation needs explicit governance for what the agent can say, what it can access, and who owns the response when it fails.
Why hosting does not remove accountability
The accountability risk comes from the operating model, not the infrastructure bill. A vendor can run the model, but the enterprise still defines the customer promise, approves the use case, and absorbs the business and legal consequences when the agent gives a harmful, misleading, or unauthorised response. That is why customer-facing agents need governance over content, access, and escalation, even in a hosted service.
Hosting also does not eliminate agency in the practical sense: the agent is still speaking in the enterprise’s context, using the enterprise’s policies, and shaping the customer experience on the enterprise’s behalf. If the output is wrong, the customer does not call the cloud provider first, they hold the brand, support function, or regulated business line responsible.
Where responsibility actually sits in the customer journey
Customer-facing systems create shared execution, but not shared accountability. The vendor may control uptime, patching, and platform security, yet the organisation still owns whether the agent is allowed to promise refunds, interpret policy, disclose account details, or trigger downstream actions. In practice, responsibility is split across procurement, product, legal, security, and operations, but the enterprise remains the accountable entity for the customer outcome.
This matters because customer interactions often blend advice, decision support, and transaction handling. A hosted agent that quotes the wrong policy or oversteps its remit can create the same customer harm as an employee error, except at much higher volume and speed. The organisation therefore needs a named business owner, a clear response path, and explicit boundaries for what the agent may say and do.
What governance has to control
Good governance is not just a disclaimer. It needs to define three things with enough precision to be testable: what the agent may say, what systems or data it may touch, and who is accountable when the answer is disputed or harmful. That is where ownership, approval gates, and auditability matter more than the hosting model itself. For identity and access structure, see NHI Ownership and Accountability Guide and AI Agent Authorisation Guide.
The other control point is evidence. If a customer challenges a response, the organisation should be able to show which policy source the agent used, which permissions were in force, what escalation logic applied, and whether a human approval was required. Without that traceability, the enterprise cannot separate a vendor defect from its own governance failure, and it cannot correct the behaviour consistently.
Risk and Threat Considerations
Customer-facing agents create concentration risk because one flawed policy, prompt, or permission set can affect many customers at once. They also create attribution risk, since vendors may host the system while the enterprise still owns the harm, complaint handling, and remediation burden. If the agent can access customer data or transaction systems, a mistake becomes both a service issue and an exposure issue.
Failure mechanism: the organisation treats the vendor as the responsible party, leaves the agent loosely bounded, and discovers too late that the customer sees the enterprise as the operator of record. Weak escalation paths, overbroad access, or unreviewed content policies then turn a bad answer into a compliance, privacy, or contractual failure.
Impact: the business may face customer loss, regulatory scrutiny, claim disputes, and expensive incident response even when the underlying platform was externally hosted. The risk scales with customer volume, decision authority, and how much trust the agent can create or break in a single interaction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Customer-facing agents need bounded authority to avoid harmful actions and responses. |
| Recommendation — Limit agent permissions to the minimum customer-facing scope needed for the task. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Hosted agents still create abuse risk when identity and authority are not tightly governed. |
| Recommendation — Enforce per-action authorization and approval for customer-impacting agent actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Enterprise accountability depends on restricting what the agent may access or do. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Accountability needs records that explain what the agent said and did. | |
| Recommendation — Apply least privilege to every customer-facing agent permission and integration. Review agent logs for disputed answers, policy breaches, and escalation failures. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Customer-facing agents need clear access boundaries and accountable control ownership. |
| A.5.32 — Intellectual property rights | Hosted agents can create contractual and content ownership issues that need governance. | |
| Recommendation — Define and enforce access boundaries for agent actions and customer data exposure. Assign ownership and approval for agent-generated customer content and outputs. | ||
Practitioner Guidance
What to prioritise: assign a single accountable business owner for each customer-facing agent, and make that owner responsible for content boundaries, escalation rules, and exception handling. Technical hosting ownership is not the same thing as customer-outcome ownership.
What to verify: test whether the agent is constrained to approved policy sources, whether it can reach any customer data or transactional action it should not, and whether logs are sufficient to reconstruct the exact exchange when a customer complains. If you cannot reconstruct it, you cannot defend it.
Decision rule: if the agent can affect customer rights, money, account status, or regulated advice, treat it as a governed business control rather than a simple hosted application. At that point, human review, explicit approval paths, and measured escalation thresholds are part of the control design, not optional extras.
Practitioner takeaway: hosted or not, a customer-facing agent still speaks for the enterprise, so accountability must be designed into ownership, authorisation, and response handling before the first customer interaction goes live.
Related resources from NHI Mgmt Group
- Why do non-human identities create compliance risk even when policies exist?
- Why do customer-facing AI agents create fraud risk in refund workflows?
- Why do AI agents create new abuse risk even when users intentionally share their credentials with them?
- Why does over-refusal create operational risk in customer-facing AI support agents?