> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/ai/ai-trust-model.md).

# AI trust model

Siit's AI is governable by design. Control what each agent can read, propose, and execute with least-privilege permissions, explicit approvals, and a full audit trail on every request

Siit’s AI is designed to be useful and governable. Our trust model gives admins fine‑grained control over what AI can read, propose, and execute—backed by least‑privilege permissions, approvals, and full audit trails. It applies to both agents:

<table data-card-size="large" data-column-title-hidden data-view="cards"><thead><tr><th data-type="content-ref"></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><a href="/ai/triage-agent.md">Triage Agent</a></td><td>Knowledge answers, triage &#x26; request deflection.</td><td><a href="/ai/triage-agent.md">Triage Agent</a></td></tr><tr><td><a href="/ai/it-agent.md">IT Agent</a></td><td>Executes operational tasks across your tools (for example, Okta, Jamf) via curated playbooks.</td><td><a href="/ai/it-agent.md">IT Agent</a></td></tr></tbody></table>

### What “trust model” means in Siit

* Identity and scope
  * AI acts as a workspace agent with role‑based permissions. It only sees data the requester is allowed to see (service audience, article visibility, directory rules).
  * For third‑party systems, the IT Agent uses dedicated, scoped service accounts or OAuth scopes—never broad admin tokens by default.
* Knowledge boundaries
  * You choose the knowledge sources (Siit Knowledge, specific collections, selected URLs/docs).
  * Answers cite sources. If no trustworthy source exists, the agent defaults to “I don’t know” and can open/route a request.
* Action governance
  * All actions are packaged as playbooks (for example, “Reset Okta MFA,” “Add to App X group”).
  * Per‑playbook autonomy levels:
    * Suggest only: propose steps to an agent.
    * Execute with approval: require human approval (assignee, team lead, manager).
    * Auto‑execute: run automatically when conditions are met.
  * Extra controls: allow/deny lists, parameter whitelists, requester eligibility checks (employment status, manager, location, device posture).
* Human in the loop
  * Any interaction can be escalated to a human. Approvals are private and auditable. Agents can always override or roll back via a paired playbook.
* Observability and audit
  * Every answer, decision, and external action is logged in the request timeline with who/what/when, inputs, outputs, and the playbook used.
  * Shadow mode: test playbooks with “simulate” to log what would have happened without making changes.
* Safety and privacy
  * Least‑privilege connectors, token rotation, and encryption in transit/at rest.
  * Prompt hardening: sensitive tokens never included in prompts; PII redaction rules for inputs you choose.
  * Rate limits and throttling per user/channel to prevent abuse.
  * We use model providers through “no training” endpoints when available and do not permit providers to use your content for their own model training. Refer to your chosen provider’s data‑handling terms.

### How each agent applies the model

[Triage Agent](/ai/triage-agent.md)

* Reads only the knowledge sources you enable; respects article visibility.
* Produces short answers with citations; can suggest forms or open a request when needed.
* Optional behaviors: auto‑tag, classify to a service, language detection and response in the user’s language.<br>

[IT Agent](/ai/it-agent.md)

* Executes only the playbooks you publish and only for eligible users.
* Typical uses: unlock Okta account, reset MFA, add to group, provision/deprovision app, run Jamf remediation.
* Guardrails: require approvals for high‑impact operations, restrict to office hours, or limit to P1 incidents.

### Admin controls

* Sources and tone
  * Choose knowledge collections; set answer length and personality.
* Playbooks and connectors
  * Connect apps with scoped credentials (Okta, Azure/Google, Jamf, etc.).
  * Build playbooks with pre‑checked conditions, required parameters, and post‑actions (notify, tag, update status).
  * Set autonomy: Suggest, Execute with approval, or Auto‑execute.
* Policies
  * Who can invoke which agent and where (channels, DMs, Portal).
  * Office‑hours rules and rate limits.
  * Data filters and redaction preferences.
* Kill switch
  * Pause an agent or a single playbook instantly; all requests fall back to human.

### Rollout checklist

* Start in a pilot channel with Shadow mode for IT Agent playbooks.
* Enable the Triage Agent on a small, high‑quality knowledge collection; review answer sources.
* Add approvals to any playbook that changes identity or device state.
* Monitor logs and CSAT; gradually increase autonomy where safe.

### Model providers and data residency

Siit routes model calls to EU-hosted or US-hosted providers, according to the processing configuration agreed for your workspace. Different setups are available depending on your data residency requirements. The list of model providers and other subprocessors, with their processing location, is published and kept up to date on our trust center: [trust.siit.io/subprocessors](http://trust.siit.io/subprocessors).

<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.siit.io/ai/ai-trust-model.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
