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 and invoke published workflows, but it cannot create, edit, or change workflows in the workflow builder. Administrators control the full surface area of what it can use: knowledge sources, which workflows it may run, access management tools, guidance, 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 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 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 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. 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 (timestamps, authors, restore). Teams can also use the CLI 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. Beyond workflows, every API call is audited, including access management 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 is its own isolated environment with workflows, knowledge, integrations, 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, organization admins define cross-team identity and access boundaries for your entire Serval account. 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. Within each team, RBAC applies at every layer: the team itself, its integrations, API behavior, who can build, workflow execution scope, and approvals.Integrations and API
API scoping per team. 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, 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.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.Compliance
See the Serval Trust Center.FAQ
Here are straightforward answers to questions we hear often. For more detail on workflows or access management, see Workflow organization and the Access management quickstart.Mistakes, hallucinations, and destructive actions
What if the AI gets it wrong?
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 and Approvals.
How does Serval limit hallucinations or destructive actions?
How does Serval limit hallucinations or destructive actions?
Your administrators decide what gets built. They publish deterministic workflows and configure controls (for example approvals, execution scope, integration permissions from the apps you connect, 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 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 and Property 3.
How do we limit what the system can change (for example sensitive groups or directories)?
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 and Approvals.
Human control and automation
I don’t want AI running actions without a person in the loop.
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 and Property 3.
What if it grants access to the wrong person?
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 explains who on your team can build or change those workflows.
What if someone tries to manipulate the help desk AI with prompts?
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.
Can a single user create and publish workflows with no one else involved?
Can a single user create and publish workflows with no one else involved?
It depends on role. Contributors can install installable workflows 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.
Data access and staying in scope
Can the AI see data it should not see?
Can the AI see data it should not see?
Only what you explicitly expose. Admins choose which knowledge, workflows, and tools the help desk can use. Organizations and teams are separated. When you connect an integration, API scoping is fixed at setup, so workflows cannot exceed the permissions your team already granted (see 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 and Property 3.
How do we reduce cross-team leakage or misuse of sensitive fields?
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 sources and app connections with your internal rules. A fuller picture of data categories is in the Data elements inventory; how visibility works is in Execution scope.
What guardrails work well for sensitive data (for example health or HR information)?
What guardrails work well for sensitive data (for example health or HR information)?
Auditing what happened
How do we see what ran, not just what the chat said?
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 and Run history, and Property 2.
Can simple requests stay self-service while sensitive actions need more review?
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 and Execution scope.
Quick reference
Who controls what the help desk agent can use?
Who controls what the help desk agent can use?
Your administrators choose knowledge, published workflows, access tools, guidance, and options like web search (including allowed domains, if you use it). See Help desk agent.
Can a workflow expand app permissions or show credentials in the help desk chat?
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; 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.
Where can I read more about compliance?
Where can I read more about compliance?
See the Serval Trust Center.