Compliance:

an AI service desk with SOC 2 Type II,
and the evidence behind it
Siit is an AI service desk with a SOC 2 Type II report covering September 2024 to September 2025. What makes it verifiable: three autonomy levels, per-action approval, OAuth scopes and a logged timeline are all published.
A compliance page normally sets out what a vendor holds. An AI service desk has to answer a second question: what the agent is permitted to do inside your identity provider, and what it records when it acts. This page covers both. First the controls Siit holds and where to verify each one, then the questions worth putting to any AI service desk before it touches an access grant, Siit included.
AI service desk with SOC 2: what Siit holds, and where you check it
Siit holds a SOC 2 Type II attestation and is subject to the GDPR as Siit SAS. SOC 2 is a framework of the AICPA, built on five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy. The criteria an AI agent puts under pressure are the common criteria: CC6 for logical access, CC7 for monitoring, CC8 for change management, CC3 and CC4 for risk assessment and its follow-up. That mapping is set out in detail in Teleport's analysis of AI agents and SOC 2.
The reason those five matter more than the badge is simple. An agent that opens a ticket changes little. An agent that adds a user to a group in the identity provider, an Okta group for example, is a new actor inside CC6, and its decisions have to land in the same evidence trail as a human administrator's. The table below is the Siit control set from that angle: each line names the control, the evidence, and the page where you read it yourself.
| Control | What Siit holds | Where to verify |
|---|---|---|
| SOC 2 Type II attestation | SOC 2 Type II, covering the period from 4 September 2024 to 3 September 2025, report issued 18 September 2025. Three Trust Services Criteria in scope: Security, Availability and Confidentiality | trust.siit.io .siit.io/security |
| Logical access, CC6 | The Siit agent acts as a workspace agent with role-based permissions and sees only the data the requester is allowed to see. Connectors are least-privilege, tokens are rotated, and sensitive tokens are excluded from prompts | docs.siit.io/ai/ai-trust-model |
| Monitoring and evidence, CC7 | Each answer, decision and external action is logged in the request timeline, and runs can be replayed step by step: prompt, decision, action, approval | https://docs.siit.io/ai/it-agent |
| Change management, CC8 | A Siit playbook moves from draft to a pilot audience before wider rollout, and its audience is scoped by channel, team and service. Shadow mode runs a playbook in simulation before it is switched on | https://docs.siit.io/ai/it-agent |
| Encryption | TLS 1.2 and 1.3 in transit, AES-256 at rest | siit.io/security |
| Perimeter, WAF and DDoS | Web application firewall and DDoS protections in front of the platform, on AWS in the eu-west-1 region, with logical tenant separation | siit.io/security |
| Penetration testing | An external penetration test is run annually by a qualified third party, confirmed by the test matrices in the SOC 2 report | trust.siit.io |
| Vulnerability scanning | siit.io/security | siit.io/security |
| GDPR | The GDPR applies to Siit SAS, and the privacy policy sets out how personal data is handled | siit.io/privacy-policy |
AI service desk with access governance: what happens after "approved"
Once granted, the access record carries its own state machine, visible on the application's activity feed, and it stays visible after the parent request is closed. This is the part a request-centric workflow tends to lose. A request closes, a ticket is archived, and the access outlives both. In Siit, an access record can carry an expiry date, and Siit creates the deprovisioning task on the morning of that expiry. The grant is not only given: it is taken back, and the taking back is a task somebody owns.
The flow itself starts where the work is. Requests come in from Slack or Teams, approval is routed, provisioning goes through the identity provider, each step is logged, and access is revoked at expiry. Siit integrates with Okta, Microsoft Entra ID, Google Workspace and JumpCloud as IAM platforms: the same category Microsoft describes as identity governance, applied to the service desk rather than to a separate console.
This section is about the record and its trail. For the capability itself, what autonomous app access does end to end, see Siit autonomous app access. For infrastructure controls, see Siit security.
Can I trust an AI agent to grant access?
Three autonomy levels.The Siit agent runs at one of three: Suggest only, Execute with approval, and Auto-execute. Third-party actions require an approval unless a setting explicitly turns on auto-run, and each action can be gated behind an approval individually, action by action in Okta for example. So the honest statement is not "the agent asks first" as a principle: it is that the level is a setting, it is chosen action by action, and Siit publishes what the setting does.

What the agent can do, taking Okta as the example. Siit connects to Okta, Microsoft Entra ID, Google Workspace and JumpCloud; Okta is used here because it is the connector whose actions and scopes Siit documents in full. Activation, suspension, deprovisioning, password reset, MFA reset, session revocation and restoration, group add and remove, application assignment and removal. That list is the ceiling of what the connector can do.

The scopes it asks for. Still on the Okta example, the Siit connector requests 7 OAuth scopes: okta.users.read, okta.users.manage, okta.groups.read, okta.groups.manage, okta.apps.read, okta.apps.manage, okta.sessions.manage. Publishing scopes is uncomfortable, because a reader can hold them against you. That is the point of publishing them.
What it writes down. Each action triggered from Siit is logged on the request timeline, and a run can be replayed as prompt, decision, action, approval. An agent holding more permission or autonomy than its task needs is a named risk in the OWASP AI agent security cheat sheet, and in the OWASP Top 10 for LLM Applications, and read in practice in Auth0's analysis of excessive agency. The scoped connector, the approval gate and the replayable log are the three answers Siit gives to it.
Autonomous AI agents for IT: seven checks to run before you buy
Autonomous AI agents for IT are evaluated badly when the evaluation is a feature list. The useful version is a short set of checks that a vendor either passes with a public document or does not. Below are seven, in the order they cost you if the answer is missing. Siit's own answer is in the second column, and the third is where you read it without asking a salesperson.
| # | The check | Siit's answer | Where to verify |
|---|---|---|---|
| 1 | What is the agent's default autonomy, and is it set per action? | Three levels, Suggest only, Execute with approval, Auto-execute. Third-party actions require approval unless auto-run is set explicitly | ai-trust-model |
| 2 | Which scopes does the connector request in my identity provider? | 7 published OAuth scopes on the documented Okta connector: read and manage on users, groups and apps, plus session management | integrations/iam/okta |
| 3 | Can a decision be replayed, or only summarised? | Prompt, decision, action and approval are logged; runs can be replayed | ai/it-agent |
| 4 | Does an access grant expire, and who removes it? | An access record can carry an expiry; Siit raises the deprovisioning task on the morning of expiry | app-access-policies |
| 5 | Can a change be tested before it reaches production? | Shadow mode simulates a playbook; playbooks go from draft to a scoped pilot audience first | ai/it-agent |
| 6 | Is our content used to train models? | Model providers are reached through "no training" endpoints where available, and are not permitted to use customer content for their own model training | ai-trust-model |
| 7 | Which audit do you hold, and can I read the report? | An external penetration test is run annually by a qualified third party, confirmed by the test matrices in the SOC 2 report | trust.siit.io |
Check 7 is the one that separates a claim from a document. A certification grid confirms that an audit took place; it does not put the report in a reviewer's hands. Siit holds a SOC 2 Type II attestation and points to its trust center for the report itself. This page names what Siit publishes and points at the source; the parts that live in the report live in the report.
Two boundaries define the model. Auto-execute is available as a setting, and it is set per playbook rather than globally. And policy remains a configuration rather than an inference: who may request, who approves, and in what order are set by your administrators.
Subprocessors, data residency and model training
Siit runs on AWS in the eu-west-1 region, in Europe, with logical separation between tenants. The list of Siit subprocessors is published on the trust center rather than reproduced here, so that the version you read is the current one: see trust.siit.io/subprocessors.
Model routing follows residency. Siit routes to Mistral AI, hosted in the EU, by default for EU workspaces, and to OpenAI for US and global workspaces. Model providers are reached through "no training" endpoints where available, and are not permitted to use customer content to train their own models. Redaction rules apply to the inputs you choose, and sensitive tokens are excluded from prompts.
This matters more each year rather than less. Gartner, cited by IBM, expects 33% of enterprise applications to include agentic AI by 2028, against under 1% in 2024, a forecast published in 2025. The Cloud Security Alliance's agentic trust framework maps that shift onto existing compliance regimes. Siit's position is narrower: publish the settings, log the actions, and let the buyer verify.
Check 7 is the one that separates a claim from a document. A certification grid confirms that an audit took place; it does not put the report in a reviewer's hands. Siit holds a SOC 2 Type II attestation and points to its trust center for the report itself. This page names what Siit publishes and points at the source; the parts that live in the report live in the report.
The documents themselves
Control descriptions, the subprocessor list and the SOC 2 Type II report are referenced on the Siit trust center: trust.siit.io. If your security review needs something that is not there, ask for it before the trial rather than after: that request is also a check on the vendor.
FAQs
Can I trust an AI agent to grant access?
Yes, to the extent its settings and its logs let you verify it, and not further. In Siit, the agent runs at one of three autonomy levels, Suggest only, Execute with approval, Auto-execute, third-party actions require an approval unless auto-run is set explicitly, each action can be gated behind its own approval, per Okta action for example, and prompt, decision, action and approval are logged in the request timeline so a run can be replayed.
Is Siit SOC 2 Type II compliant?
Yes. The report covers the period from 4 September 2024 to 3 September 2025 and was issued on 18 September 2025, with Security, Availability and Confidentiality in scope. It is available through the Siit trust center at trust.siit.io. The GDPR also applies to Siit SAS.
Does Siit train AI models on our data?
No. Siit reaches model providers through "no training" endpoints where available, and does not permit providers to use your content for their own model training. Redaction rules apply to the inputs you choose, and sensitive tokens are excluded from prompts.
What OAuth scopes does the Siit Okta connector request?
Seven: okta.users.read, okta.users.manage, okta.groups.read, okta.groups.manage, okta.apps.read, okta.apps.manage and okta.sessions.manage. Siit publishes them so an administrator can compare the scopes requested against the actions actually needed.
Does access granted through Siit expire automatically?
It can. An access record in Siit may carry an expiry date, and Siit creates the deprovisioning task on the morning of that expiry. The access record keeps its own state machine on the application's activity feed, including after the parent request is closed.
What happens if an approver rejects a request halfway through?
Approvals in Siit run in rounds and the order is enforced: round 2 starts once round 1 is signed, and a rejection cancels the downstream rounds automatically. A Role's approval step takes an Approval Policy, auto-accept, auto-reject or Skip approval, and an Approval Policy can chain several rounds.
Where is Siit hosted, and does the GDPR apply?
Siit runs on AWS in the eu-west-1 region, in Europe, with logical separation between tenants, TLS 1.2 and 1.3 in transit and AES-256 at rest. The GDPR applies to Siit SAS. For EU workspaces, Siit routes model calls to Mistral AI, hosted in the EU; US and global workspaces route to OpenAI.
Can we test a Siit playbook before it touches production?
Yes. Siit has a shadow mode that runs a playbook in simulation before activation, and a playbook moves from draft to a scoped pilot audience before wider rollout. Audience scope is set by channel, team and service.
Who are Siit's subprocessors?
The list is published and kept current on the Siit trust center at trust.siit.io/subprocessors, rather than duplicated on this page where it would drift out of date.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.