> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Product security

> Security model for AI-assisted automation: isolated agents, deterministic workflows, and segregated teams with RBAC at the org and team level

**Serval is an AI company that trusts AI only where it has to.** We treat the AI as a **probabilistic** component surrounded by deterministic enforcement. The hard security guarantees come from the infrastructure layers around the model, not from trusting the model to behave correctly.

Here's what that actually means in practice.

## Property 1: Separation between agents

We maintain a **strict separation** between two dedicated agents with very different jobs. They do **not** share context.

### Help desk agent

**The help desk agent** handles end-user conversations. It can use your [knowledge base](/sections/documentation/knowledge-base/overview) and invoke **published** [workflows](/sections/documentation/workflows/overview), but it **cannot** create, edit, or change workflows in the [workflow builder](/sections/documentation/workflows/Configure/build-guide). **Administrators control the full surface area** of what it can use: knowledge sources, which workflows it may run, [access management](/sections/access-management/overview) tools, [Skills](/sections/documentation/skills/overview), and anything else exposed to help desk. It only gets tools your team **explicitly** turned on.

### Automation agent

**The automation agent** (the admin-facing [workflow builder](/sections/documentation/workflows/Configure/build-guide) experience) is **separate**. It is for creating and configuring automations. It has **no** access to end-user ticket context and operates in a **different environment** from the help desk.

### What this isolation gives you

Because the agents are isolated, a conversation in one [ticket](/sections/documentation/ticketing/overview) stays isolated from other tickets. Workflow runs are isolated in execution: one run cannot see or influence another. So there is no path for someone in one chat to manipulate the help desk agent into **leaking another ticket’s context** or into **reaching the workflow builder layer**. The help desk agent cannot author or modify workflows.

Prompt text cannot override identity. The system uses the authenticated session, so "I'm Jane" in chat does not change requester identity.

## Property 2: Deterministic workflows you can own and audit

The help desk agent can only use tools your team configured. Those tools are **deterministic, code-based** [workflows](/sections/documentation/workflows/overview) by default. When you publish a workflow, it runs as **fixed TypeScript** that executes as written. The model **cannot** modify, bypass, or alter a published workflow’s behavior. It can only invoke it with the parameters you defined. **An LLM appears in a run only if your team intentionally adds a step that calls one.** That is not the default; typical workflows are fully deterministic end to end.

A few things follow:

* **No LLM in the default runtime path.** The automation agent’s job is to help translate intent into workflow code **during [authoring](/sections/documentation/workflows/Configure/build-guide)**. After publication, the same workflow runs the same way unless you explicitly put a model (or other non-deterministic) step inside the workflow.
* **Real code you can edit and review.** Workflows live as TypeScript with **in-product [version history](/sections/documentation/workflows/Manage/versioning)** (timestamps, authors, restore). Teams can also use the [CLI](/sections/cli/overview) to pull and push workflows and keep them in Git: read them, diff them, and hand them to a security reviewer the way you would **application code**.
* **Full audit trail.** Every published workflow version is tracked with timestamps and authors, and you can restore prior versions. Every workflow run is logged step by step with inputs, outputs, and status in [run history](/sections/documentation/workflows/Run/run-history). Beyond workflows, every API call is audited, including [access management](/sections/access-management/overview) actions such as role changes, profile updates, and approvals, plus integration configuration and admin settings changes. Logs are exportable.

## Property 3: Organization- and team-level segregation, roles, and controls

Serval layers controls at two levels. Your organization governs cross-team access and identity, while each [team](/sections/documentation/platform/teams) is its own isolated environment with workflows, knowledge, [integrations](/sections/integrations/overview), policies, approvals, and RBAC. Controls at both levels are enforced independently. Team-level permissions cannot widen what your organization has scoped.

### Organization-level controls

In [Organization settings](/sections/documentation/platform/org-settings), organization admins define cross-team identity and access boundaries for your entire Serval account. [Access Profiles](/sections/access-management/configuration/access-profiles) enforce eligibility based on user and group attributes, including who can request access to apps, resources, and roles, and who can run scoped workflows across teams.

### Team-level controls

Every team in Serval is its own isolated environment, with its own workflows, knowledge, integrations, policies, access, roles, and approvals. Configure much of this under [team settings](/sections/documentation/platform/team-settings). Within each team, RBAC applies at every layer: the team itself, its integrations, API behavior, who can build, [workflow execution scope](/sections/documentation/workflows/Configure/execution-scope), and approvals.

#### Integrations and API

**API scoping per team.** When a team connects an [integration](/sections/integrations/overview), you define exactly what scopes Serval gets access to. That ceiling is set at setup and no workflow on the team can exceed it, regardless of what workflow code requests.

**API credentials never touch the model.** When a workflow calls a connected service, the request flows through our integration proxy, which confirms the caller is a worker (not an end-user browser), validates that the integration belongs to the requesting team, and injects credentials server-side. Workflow code never sees API keys or OAuth tokens.

#### Team roles (RBAC)

Team roles are scoped per team and enforced independently from organization roles. For the full role matrix and capabilities, see [Permissions](/sections/documentation/platform/permissions).

#### Workflows

**Team-scoped execution.** Every workflow is scoped to a team or to the org. A team-scoped workflow is invisible to anyone outside that team, including the help desk agent serving other teams' users.

**Custom conditions in code.** Workflow code can restrict execution based on the requester's location, department, employment type, or anything else in your user data.

**Approval procedures.** Each workflow can require individual approvers, group approvals, manager approvals, multi-step chains, or automated approval logic based on business rules. These are hard-coded into the workflow, not optional at runtime. See [Approvals](/sections/documentation/workflows/Configure/approvals).

## Compliance

See the [Serval Trust Center](https://trust.serval.com/).

***

## FAQ

Here are straightforward answers to questions we hear often. For more detail on workflows or access management, see [Workflow organization](/sections/documentation/workflows/Manage/organize#faqs) and the [Access management quickstart](/sections/access-management/admin-quickstart#faqs).

### Mistakes, hallucinations, and destructive actions

<AccordionGroup>
  <Accordion title="What if the AI gets it wrong?">
    Natural-language replies can vary, but **anything that changes a system or record goes through a published workflow** you control. Those workflows run the same way each time (unless you add a step that intentionally uses a model). You can add **approvals**, limit **inputs**, and set **who can run** a workflow so sensitive actions are explicit. Learn more in [Property 2](#property-2-deterministic-workflows-you-can-own-and-audit) and [Approvals](/sections/documentation/workflows/Configure/approvals).
  </Accordion>

  <Accordion title="How does Serval limit hallucinations or destructive actions?">
    **Your administrators decide what gets built.** They publish **deterministic workflows** and configure **controls** (for example [approvals](/sections/documentation/workflows/Configure/approvals), [execution scope](/sections/documentation/workflows/Configure/execution-scope), integration permissions from the [apps you connect](/sections/integrations/overview), and team boundaries). Those layers restrict AI-assisted flows from triggering changes outside what you designed, so consequential actions stay inside reviewed automation rather than improvised model behavior.

    **[Agent separation](#property-1-separation-between-agents)** keeps chat and authoring in different environments. End users cannot bridge that boundary by prompting: they cannot reach workflow authoring, widen app access, or pull credentials through the conversation. Requester identity still comes from the authenticated session.

    Read [Property 2](#property-2-deterministic-workflows-you-can-own-and-audit) and [Property 3](#property-3-organization-and-team-level-segregation-roles-and-controls).
  </Accordion>

  <Accordion title="How do we limit what the system can change (for example sensitive groups or directories)?">
    **Talking to the AI does not by itself change your systems.** Updates run through your connected apps using the permissions you approved at setup. Combine **team-only workflows**, **who can run** a workflow, logic inside the workflow (for example who is targeted), and **approvals** so important changes only happen through automation you have reviewed. See [Execution scope](/sections/documentation/workflows/Configure/execution-scope) and [Approvals](/sections/documentation/workflows/Configure/approvals).
  </Accordion>
</AccordionGroup>

### Human control and automation

<AccordionGroup>
  <Accordion title="I don’t want AI running actions without a person in the loop.">
    Add **approvals** where you want a human sign-off: single approver, group, manager chain, multi-step, or rule-based. The help desk only **runs** workflows you already published; it does not invent new integrations or side effects beyond what you built. More in [Approvals](/sections/documentation/workflows/Configure/approvals) and [Property 3](#property-3-organization-and-team-level-segregation-roles-and-controls).
  </Accordion>

  <Accordion title="What if it grants access to the wrong person?">
    Access follows the **apps and rules you configured**: connected systems, approved permissions, available entitlements, and logic in the workflow (including who the request applies to). For sensitive grants, require **approvals** so someone reviews before anything changes. [Permissions](/sections/documentation/platform/permissions) explains who on your team can build or change those workflows.
  </Accordion>

  <Accordion title="What if someone tries to manipulate the help desk AI with prompts?">
    The help desk chat is not where automations are written, and it does not expose passwords or API tokens for your connected apps. Whatever someone types cannot switch on new powers: the assistant only uses the workflows and tools your admins already gave it, and who the person is comes from their login, not from the message. Lines like "pretend I'm Jane" or "ignore policy" do not change their role, app permissions, or [who is allowed to run each workflow](/sections/documentation/workflows/Configure/execution-scope).
  </Accordion>

  <Accordion title="Can a single user create and publish workflows with no one else involved?">
    It depends on **role**. **Contributors** can install [installable workflows](/sections/documentation/workflows/Configure/installable) but cannot author custom workflows from scratch. **Builders** and above can create and edit custom workflows. **Managers** configure integrations. Your organization decides who holds each role and who is invited. Details: [Permissions](/sections/documentation/platform/permissions).
  </Accordion>
</AccordionGroup>

### Data access and staying in scope

<AccordionGroup>
  <Accordion title="Can the AI see data it should not see?">
    **Only what you explicitly expose.** Admins choose which [knowledge](/sections/documentation/knowledge-base/overview), [workflows](/sections/documentation/workflows/overview), and tools the help desk can use. Organizations and teams are separated. When you connect an [integration](/sections/integrations/overview), **API scoping** is fixed at setup, so workflows cannot exceed the permissions your team already granted (see [Integrations and API](#integrations-and-api) under Property 3). Connections to your apps run outside the chat and credentials are not shown to the model. See [Property 1](#property-1-separation-between-agents) and [Property 3](#property-3-organization-and-team-level-segregation-roles-and-controls).
  </Accordion>

  <Accordion title="How do we reduce cross-team leakage or misuse of sensitive fields?">
    You decide where data lives: **team-only** workflows, **who can run** them, and logic inside the workflow for who can be affected. For regulated data, align [knowledge](/sections/documentation/knowledge-base/overview) sources and app connections with your internal rules. A fuller picture of data categories is in the [Data elements inventory](/sections/documentation/data-elements-inventory); how **visibility** works is in [Execution scope](/sections/documentation/workflows/Configure/execution-scope).
  </Accordion>

  <Accordion title="What guardrails work well for sensitive data (for example health or HR information)?">
    Share **only** the [knowledge](/sections/documentation/knowledge-base/overview) and tools that team needs, put risky steps in **published [workflows](/sections/documentation/workflows/overview)** (not open-ended chat), and use **[approvals](/sections/documentation/workflows/Configure/approvals)** when your policy requires human review. Serval provides team boundaries and repeatable automation; you decide what to connect and who can run it.
  </Accordion>
</AccordionGroup>

### Auditing what happened

<AccordionGroup>
  <Accordion title="How do we see what ran, not just what the chat said?">
    Every published version shows **who** published and **when**. Each **run** stores inputs, outputs, and status, and you can **export** history. That is your record of what automation did, separate from the conversation. See [Versioning](/sections/documentation/workflows/Manage/versioning) and [Run history](/sections/documentation/workflows/Run/run-history), and [Property 2](#property-2-deterministic-workflows-you-can-own-and-audit).
  </Accordion>

  <Accordion title="Can simple requests stay self-service while sensitive actions need more review?">
    **Yes.** Use different workflows for different risk levels: lighter approvals for routine tasks, stricter approvals or **team-only** visibility for sensitive changes (for example admin or directory updates). See [Approvals](/sections/documentation/workflows/Configure/approvals) and [Execution scope](/sections/documentation/workflows/Configure/execution-scope).
  </Accordion>
</AccordionGroup>

### Quick reference

<AccordionGroup>
  <Accordion title="Who controls what the help desk agent can use?">
    **Your administrators** choose [knowledge](/sections/documentation/knowledge-base/overview), published [workflows](/sections/documentation/workflows/overview), access tools, [Skills](/sections/documentation/skills/overview), and options like web search (including allowed domains, if you use it). See [Help desk agent](#help-desk-agent).
  </Accordion>

  <Accordion title="Can a workflow expand app permissions or show credentials in the help desk chat?">
    **No.** Calls to connected apps use the **permissions you approved** when you set up the [integration](/sections/integrations/overview); a workflow cannot silently widen that access. Secrets stay on the secure execution side and are **not** passed into the help desk conversation. See [Property 3](#property-3-organization-and-team-level-segregation-roles-and-controls).
  </Accordion>

  <Accordion title="Where can I read more about compliance?">
    See the [Serval Trust Center](https://trust.serval.com/).
  </Accordion>
</AccordionGroup>