AI Service Desk with SOC 2: What to Read Before Granting Rights

An AI service desk with SOC 2 has had controls examined by an outside auditor against the AICPA’s Trust Services Criteria. It has not been cleared to hold rights in your systems. A SOC 2 Type II report describes how a vendor’s controls operated over a past period, for the products and the trust services categories its scope selected, and it carries the auditor’s opinion and any exceptions. That report rarely sits on a trust page: Atlassian publishes its reports in an authenticated portal, and Zendesk, Freshworks and Ravenna send theirs on request. The badge on a security page is the vendor’s summary, not the examination. Before granting an agent rights, read four things: the report’s period, scope and opinion; where data is stored and which model providers process it; what the identity connector may request; and whether the agent’s actions land in an audit trail you can export. None of these covers the months after the audited period closed.

What does the report behind an AI service desk with SOC 2 cover, and leave out?

The framework is not owned by the vendors that report against it. The AICPA publishes the 2017 Trust Services Criteria, with points of focus revised in 2022, “for use in attestation or consulting engagements to evaluate and report on controls” over security, availability, processing integrity, confidentiality, or privacy. A report addresses the categories its scope selected, so the first line to read is which of the five are in it: a team whose obligations turn on processing integrity or privacy needs to know whether the report speaks to them. The trust centers of Harmony and Zendesk name the categories of their SOC 2 reports, as do the security pages of Atomicwork and Moveworks; the other vendor pages cited here do not.

The second line is the product. Atlassian’s compliance FAQ states that “the Products vary per compliance program”. A badge on a company page does not say whether the specific product, or the AI feature added to it, was inside the examination.

The third line is the type and the period. Atomicwork’s security page draws the distinction in its own words: its Type 1 entry speaks of a platform “designed with strong controls”, its Type 2 entry of audits that “validate that the SOC controls operate consistently over time”. Atlassian’s FAQ says that “SOC 2 Type 2 audits are a review of performance of controls over a period of time”, and that its reports cover 12 months, from October 1 to September 30, with refreshed reports usually available by the end of December.

The months after the period are where a reader is most easily misled. Atlassian’s FAQ states: “We also issue a 3-month bridge letter in January/February of each year that extends the coverage period through the end of January.” For any vendor’s bridge letter, ask who signs it, what period it covers, and whether an auditor examined it.

What a vendor publishes about itself, and what an auditor examined

A trust page and a SOC 2 report are two different kinds of document, and an evaluation goes wrong when one stands in for the other.

The trust page is the vendor describing itself. Siit’s security page is a compact example of the form: it lists “SOC 2 Type II Compliance” beside AWS hosting and its encryption values, and links to its trust center. Ravenna and Serval publish the same kind of summary, each writing “SOC 2 Type II certified”. Everything on such a page is a declaration: the fastest way to open a review, not the part an auditor signed.

The report is that part, and it reaches a buyer through a gate. Zendesk says its SOC 2 Type II reports are available “upon request and under NDA”. Freshworks lists its SOC 2 Type 2 reports and bridge letters as available on request, usually within one business day, and its SOC 3 report with no request. Ravenna’s report comes through an account manager. Harmony sends its reports by email to a named person, under NDA. Atlassian publishes its reports through an authenticated portal.

Reading the report is a task, not a checkbox. Ask for the system it describes, the period it covers, the auditor’s opinion and any exceptions noted, the sub-processors the vendor relies on, and the controls the report leaves to the customer.

Where is the data hosted, and who processes it?

Hosting and encryption values on a page are declarations to examine, and the quickest to check if three questions are kept apart, since vendors answer them in different places.

Storage first. Zendesk states that it hosts Service Data primarily in AWS data centers in the United States, Europe (EEA) and Asia Pacific, with region selection for subscribers who have the Data Center Location Add-on or the functionality in their plan. Serval publishes two regions, AWS US West and EU Central, set when an organization is created and not changeable afterward. Atlassian relies primarily on AWS, states that “regional deployments differ based on product”, and points to its SOC 2 reports for locations. Atomicwork states residency options “in approved regions” without listing them, and the Siit page names AWS without a region. A residency obligation needs the region in writing.

Processing second. A storage region does not settle every path the data takes. Serval states that SAML SSO and SCIM directory sync are handled by WorkOS, a sub-processor whose processing is not confined to the region the customer selected. Zendesk states that features from acquisitions, such as AI Agents - Advanced, “may remain on Google Cloud Platform (GCP) hosting locations in the US and/or Europe for a period of time”. Ravenna names its model providers, Anthropic, OpenAI and Google Vertex AI, and states that they do not train on customer data or retain prompts and responses; Zendesk names OpenAI with zero data retention endpoints and models hosted on Azure, Amazon Bedrock or Google Cloud Platform; Harmony hosts its models on AWS inside its own account. These statements say who processes a request, not in which region inference runs.

Conversation logs third. Ravenna’s page states that conversation logs are stored in Ravenna, retained according to the customer’s retention policy, and can be exported or deleted on request.

Encryption values converge: Zendesk states TLS 1.2 or higher in transit and AES-256 at rest, Ravenna and Serval TLS 1.3 and AES-256. Record them and confirm them against the report; logical separation of tenants is a method to ask about, not a result already tested. The conversational-client side of residency is taken up in the page on conversational clients and model choice.

What should an AI service desk with access governance let a connector ask for?

Two properties of an identity connection are reviewed separately: the kind of credential, an application identity or a named person’s, and what that credential may do. A connector page that lists the OAuth scopes it requests lets an administrator compare what is requested with what the intended playbooks need, before authorizing. The steps for Okta and Entra ID are set out in the identity provider integrations.

Serval documents the concern as a ceiling: when a team connects an integration, “you define exactly what scopes Serval gets access to. That ceiling is set at setup and no workflow on the team can exceed it”, and credentials are injected server-side so that “workflow code never sees API keys or OAuth tokens”. The page lists no scope strings, and not every connector page does. Ask for the requested list in writing, and ask which single permission the product cannot run without.

Do an agent’s actions land in the trail an auditor reads?

This is the question an agent adds. An agent grants access, as an administrator did last quarter, and an access review is workable when both end up in one place, described the same way.

Serval’s page describes a trail built around workflows: published versions carry timestamps and authors, each run is logged step by step with inputs, outputs and status, and API calls are audited, including role changes, profile updates and approvals, with exportable logs. Ravenna’s page states an audit trail of AI interactions, tool executions and configuration changes. The test is whether the agent’s grant, the approval behind it and any later expiry appear in one account that you can export; a list of current holders does not say on whose approval each access arrived. Which approvals and autonomy settings sit in front of an action is taken up in what autonomy means for an IT agent.

• 01

  Read the period, not the badge

  A Type 2 report reviews how controls performed over a period that has closed. Atlassian states its own period and issues its own bridge letter for the months after; ask each vendor who issues theirs and whether an auditor stands behind it.

• 02

  Check the product and the categories in scope

  The AICPA names five trust services categories, and a report addresses the ones its scope selected. Atlassian states that the products in scope vary per compliance program, so the badge of a company is not the scope of a product.

• 03

  Tell the trust page from the report

  Hosting, encryption and a SOC 2 label on a trust page are the vendor describing itself. The auditor's opinion, the exceptions and the period are in the report, which Zendesk, Freshworks, Harmony and Ravenna send on request.

• 04

  Keep three locations apart

  Where data is stored, where a model processes a request, and where conversation logs sit are three questions. Serval fixes a storage region at setup, Ravenna and Zendesk name their model providers, and Atlassian points to its SOC 2 reports for locations.

• 05

  Open the audit trail before the first grant

  An audit trail is worth what it records. Serval logs workflow runs step by step with inputs and outputs, and Ravenna states an audit trail of AI interactions, tool executions and configuration changes. Ask for the same before the first grant.

Where an attestation stops being evidence

This page ranks no vendor on compliance. The documents that would allow it are partly behind requests, NDAs or portals, and the pages read here differ in what they publish. Comparing them point by point is possible; scoring them is not, on public material alone. The settings that narrow what an agent may do alone are covered in scoping what an agent may do alone, and whether an agent belongs in the stack at all is the question in what an AI service desk agent is, and is not.

Which vendors document SOC 2 for an AI service desk?

Listed here: vendors of an AI service desk agent, or of an ITSM that offers one, whose public pages read in October 2026 state a SOC 2 attestation and publish both their hosting, a provider or a region, and their encryption in transit and at rest. Report access is noted where a page gives it. Each line reports what the vendor publishes about itself; none of it stands in for reading the report.

• Atlassian: Its compliance FAQ states SOC 2 Type 2 reports covering October 1 to September 30, hosting primarily on AWS, and reports downloadable from an authenticated portal; its security practices page states TLS 1.2 or higher in transit and AES-256 at rest.
• Freshworks: Its trust center lists SOC 2 Type 2 reports available on request and Amazon Web Services as its hosting sub-processor; its security page states AES 256-bit encryption at rest and TLS 1.2 in transit.
• Harmony: Its trust center lists SOC 2 Type II, hosting on AWS and reports sent by email to a named person under NDA; its data privacy controls page states AES-256 at rest and encryption in transit over TLS.
• Serval: Its welcome page states SOC 2 Type II, TLS 1.3 in transit and AES-256 at rest; its data residency page states a choice of AWS US West or EU Central, fixed when the organization is created.
• Siit: Its security page lists SOC 2 Type II compliance, hosting on AWS, TLS 1.2 and 1.3 in transit and AES-256 at rest.
• Zendesk: Its trust center states SOC 2 Type II reports available on request under NDA, hosting primarily in AWS data centers in the United States, Europe and Asia Pacific, TLS 1.2 or higher in transit and AES-256 at rest.