Does Zendesk use customer prompts to train third-party generative models?

Zendesk says its generative capabilities use pre-trained third-party models and that providers cannot use customer inputs to train their models or improve their services. Its generative AI documentation also describes zero-data-retention processing for the LLM paths it uses. Keep this claim scoped to the third-party generative capabilities Zendesk documents. Zendesk publishes a separate process for proprietary machine-learning models, including sanitation measures for data used by models that could serve other customers. AI agents - Advanced (Ultimate) can place responsibility for training-data sanitation with the customer when Service Data is required. The security review should therefore record what the capability is and which model category it uses, along with the processing route and sanitation configuration.

Can a Zendesk administrator restrict every role to selected AI agents?

Zendesk documents per-agent selection for Client users. Client editors and Client admins have access to all AI agents by default. A Client admin can ask Zendesk customer support to restrict another Client admin, while the published guide says Client editor access currently cannot be restricted. Test each role that exists in the tenant instead of extrapolating the Client user behavior. The evidence should show the Admin Center role assignment and the selected AI agents where selection is supported. It should also show the result of opening one assigned and one unassigned asset.

Do Zendesk conversation logs replace the account audit log?

The two logs answer different questions. Conversation logs document interactions between an AI agent and end users, including messages, procedure details, actions, and current API-integration information. Zendesk's account audit log tracks specified account changes made by agents and administrators; it excludes end-user activities. A complete investigation may need both records. Use the platform conversation ID to match the Zendesk interaction with the CRM, then attach the relevant administrative entry when a role, integration, action flow, or account setting changed. Preserve the source of every field so the final packet never presents one log's scope as another's.

Can DeepInspect govern native Zendesk AI traffic?

DeepInspect governs authenticated HTTP requests to LLM endpoints that a customer-controlled integration explicitly routes through its proxy. Zendesk's built-in generative processing follows the vendor-managed model paths described in Zendesk documentation, so that traffic remains outside an external interception point unless Zendesk exposes and the customer configures a compatible route. A separate custom application that receives Zendesk context and calls an LLM through a configurable customer endpoint can be tested for DeepInspect coverage. Ordinary Zendesk calls to a CRM or order system, including a billing API, remain outside the LLM boundary.

Zendesk AI Security: Separate Data, Access, Logs, and Model Routes

A Zendesk AI agent can read a customer message and choose a procedure before generating a reply and triggering an API integration. Zendesk AI security therefore crosses several control boundaries before the ticket changes. Third-party LLM processing is one boundary. AI agent roles and per-agent access are another. Conversation logs show messages and reasoning context, along with actions, while the account audit log records a different class of administrative change. I want to keep those records separate. The green check beside a successful conversation proves execution. It cannot prove that every model-bound request received an independent policy decision.

TL;DR

Zendesk's third-party LLM processing for generative capabilities uses documented zero-data-retention controls. Review this route separately from Zendesk's proprietary machine-learning models.
Admin Center roles open the AI agents workspace. Client admins can scope named agents for client users, while other roles have broader documented access.
Conversation logs expose messages, procedure context, actions, and current API-integration details. Account audit logs focus on changes by agents and administrators.
DeepInspect applies only when a customer-controlled integration routes an authenticated HTTP LLM request through its proxy. Native model traffic and business-application calls stay outside that boundary.

Generative processing has two documented data paths

Zendesk's generative AI documentation says LLMs developed by third-party vendors support its generative capabilities. It describes two integration patterns. Some models run on infrastructure platforms such as AWS Bedrock and Microsoft Azure, where Zendesk says the model provider lacks access to Service Data. Directly hosted providers such as OpenAI and Google Gemini use zero-data-retention endpoints. Zendesk says request and response bodies exist in memory to serve the request and are not stored by the LLM provider afterward.

That statement is a precise starting point for the security review. For each enabled Zendesk AI capability, inventory the processing pattern Zendesk assigns to it, then record the relevant agreement. Record the data classes that can enter prompts. Keep a dated copy of the vendor documentation beside the internal approval. A procurement spreadsheet with one row marked "Zendesk AI" is too coarse for this job; the reviewer needs the named capability and processing path visible on the same screen.

Model training needs a separate control statement

The Zendesk AI Data Use Information distinguishes proprietary machine-learning models from third-party generative models. Zendesk says its third-party generative capabilities use pre-trained models and customer inputs are excluded from provider training or service improvement. For proprietary models that can be used by other customers, Zendesk describes identifier-field exclusion and natural-language processing to remove certain identifying information, followed by tokenization.

AI agents - Advanced (Ultimate) is a customer decision point in that documentation. When Service Data is required for model training, customers determine how to sanitize the training dataset. Zendesk describes entities that replace detected personal data, including placeholders for email addresses and bank-account numbers. Treat that configuration as a production control. Sample the transformed training material with synthetic records and preserve the selected entities, then assign a named approver. Zero retention at a third-party generative endpoint answers a different question than sanitation of data used for a Zendesk model. Combining them into one "no training" claim would erase the distinction Zendesk publishes.

AI agent access starts with roles and named assets

Zendesk's AI agent access guide says workspace access is in Admin Center. An administrator creates the user account and assigns a role. Support administrators receive the Client admin role for AI agents by default, and Client admins can change other users' AI agent roles.

Asset scope then depends on the role. Client admins can select the specific AI agents available to a Client user. Client editors and Client admins receive access to all AI agents by default. Zendesk says another Client admin's access can be restricted through Zendesk customer support, while Client editor access currently cannot be restricted.

Test those paths with separate accounts. Put the Client user beside a restricted agent list, then attempt to open an unassigned AI agent. Run a second check under Client editor. Capture the role and named agent, along with the observed result and review date. I would reject a sign-off that says "RBAC enabled" without these two screenshots because the documented scope differs by role.

The larger post-authentication gap still matters. Workspace authentication establishes who entered the administration surface. Request-specific authority asks which customer message, data class, procedure, and destination that identity may approve.

Conversation records and account changes answer different questions

Zendesk's conversation-log guide documents the evidence available for an automated interaction. A reviewer can inspect end-user and AI agent messages, conversation status, resources used, active instructions, and actions. For generative procedures, message details include the plan, procedure step, response before customization, and active instructions. Current API integration entries can expose the timestamp, source dialogue, integration name, scenario, request parameters, session parameters, and errors. Zendesk notes that legacy API integrations are absent from these conversation logs.

The account audit log is for another purpose. Zendesk's account audit-log documentation covers changes by agents and administrators on Enterprise plans and above. Entries include time, actor, IP address, item, activity type, and activity detail. Zendesk states that end-user activities are excluded.

Build the incident packet with both sources. Print the platform conversation ID at the top and attach the matching action details. Add any relevant administrative change. A blank field should remain blank rather than being inferred from the neighboring log.

Agent actions create an authorization boundary

Zendesk documents agentic AI agents that can select procedures and execute actions, including API calls. Conversation logs can show which action ran and which procedure triggered it. That gives operations teams a reconstruction path after a customer interaction changes an order, account, or ticket.

The receiving system is still responsible for authorization for the business operation. A Zendesk integration credential might be permitted to read an order and issue a refund through the same API. The model's choice of action supplies intent, while the target application's access control decides what that credential can execute. Constrain credential scopes inside that receiving system. Add transaction limits and approval requirements where the impact warrants them, then match the application response with the Zendesk platform conversation ID.

This boundary also prevents over-crediting an AI gateway. A call from Zendesk to a CRM or billing API is application traffic, not an LLM inference request. DeepInspect's HTTP policy enforcement boundary is for model-bound HTTP traffic deliberately routed through its enforcement point. Zendesk-native actions and target-system permissions remain under Zendesk and the connected application.

A Zendesk AI security review needs four evidence packets

The result of a useful Zendesk AI security review is four executed tests.

Data processing: state which Zendesk capability is enabled and name its documented LLM processing pattern. Preserve the approved prompt data classes and agreement, along with the documentation date.
Access: test Client user and Client editor behavior against a named AI agent. Record the Admin Center role and observed asset scope.
Conversation: run a synthetic request through a procedure, then retain the messages, plan, active instructions, action details, platform conversation ID, and any integration error.
Administration: export the relevant Zendesk account audit entries. Keep the actor, IP address, item, activity, and UTC timestamp beside the configuration change.

The four packets should share a case identifier in the review file. On a whiteboard, draw the customer channel, Zendesk AI agent, third-party model processing, and connected application as separate boxes. Mark which evidence source belongs under each box. The drawing exposes unsupported arrows quickly. It also shows where a zero-trust AI architecture needs request-specific authority in addition to authenticated identities and vendor controls.

DeepInspect

This is the gap DeepInspect closes on a supported customer-controlled inference route. DeepInspect is inline as a stateless proxy between an authenticated user or agent and an LLM endpoint. The calling application supplies identity and relevant request context. DeepInspect evaluates the role, prompt classification, requested model, destination, and versioned policy before the model request proceeds.

Zendesk is responsible for settings for native AI capabilities, workspace roles, conversation records, account auditing, and connected-application actions. DeepInspect adds an independent allow or deny decision only for model-bound HTTP requests deliberately routed through the proxy, with redaction when policy requires it and a signed, tamper-evident record for each decision. Vendor-managed inference and traffic that bypasses the proxy stay outside its visibility. Book a technical deep dive at deepinspect.ai.