Dashboard

app.sentisec.ch is where you watch your agents and configure what Sentisec does about their actions. Select a workspace first: its credentials, keys, sessions and settings are isolated from other workspaces.

The operator surface

First run

1. Create or select a workspace.
2. Open Settings → Connect. Choose the API-key path for your own application or the subscription setup for Claude Code and Codex.
3. For an API-key integration, add your provider key under Settings → Providers, in its Provider keys section, then issue a workspace key under Settings → API keys with Issue key. Provider keys travel over HTTPS to the dashboard server and are encrypted server-side before storage; your application never sees them. Copy your new workspace key when it is shown; it is shown once.
4. Follow the quickstart and make a call using the workspace-scoped base URL.
5. Open Sessions to inspect the run, or Gateway → Requests to inspect an individual model request. A recorded request proves connectivity; it does not by itself prove that the workspace is enforcing.

New workspaces start in shadow. Choose when to move to blocking on Protection → Enforce, after reviewing the recorded verdicts. See enforcement mode.

Find the right view

The workspace rail keeps the same destinations as traffic grows. A new workspace can show empty views; they become useful as your first sessions arrive. Use ⌘K to find a destination without traversing the rail.

Under Advanced:

A clean measured verdict, an unevaluated request and a failed measurement mean different things. Read the evaluation state alongside the verdict; a blank count or missing evidence is not proof that nothing happened.

Learn and prove a contract

Protection → Learn proposes a behavior contract learned from your workspace's recorded sessions. Protection → Prove tests it before activation.

What a proposal learns from

A proposal reads your recorded sessions as they were recorded.

• Mark your tools first, then record. A session recorded before you marked a tool as returning outside content still counts as having no outside content, so proposing again on the same sessions changes nothing. After you mark your tools in protection setup, let your agent record new sessions, then propose again. When no session had outside content in reach, the proposal says so, and its checks against untrusted content only watch.
• A call that only waited for approval is normal work. A session whose only holds were waits under the approval policy is read like any other.
• A blocked session is skipped. A session holding a call Sentisec blocked or would have blocked, or a wait an approver rejected, is not read, and the proposal says how many it skipped.

Prove a proposal before you activate it

Prove replays the proposal against your recorded sessions before it can block anything.

• Every wrongly blocked call counts. If Prove blocks a call that your labels say is legitimate, by a check it can measure offline, that call is a false block, even when the same session also reaches checks Prove cannot measure.
• Approval waits are reported apart. The calls the approval policy would hold over each whole session are reported as approval load, never as catches or false blocks. The load reads as calls in waits, for example "27 legitimate calls in 19 waits": each call is one approval a person gives, and calls held in the same answer are one wait for the agent.
• An answer is one plan, as in live traffic. A call that changes something, proposed in the same answer as a call the proposal holds or refuses, is not sent, and Prove never scores it on its own. It counts with that call: as part of one approval wait, of one false block, or of one catch. See calls proposed together.
• Requests your provider refused do not spoil a session. A request your provider turned away, for example over its rate limit, with no answer and no tool call, gave Sentisec nothing to judge, and the retry carries the same content. Prove leaves it out when it checks that a session's recorded content is complete, and lists it in the replay evidence. A request with any answer or tool call still counts.
• When Prove cannot run, it says why and what to do. The message names the problem in plain words, for example a check from one of your tools' own input schemas that the proposal left out, and the next step, usually to propose again. When no attack could be scored because the proposal already blocks every legitimate session Prove builds attacks from, the refusal says that those blocks are false blocks and names the rules that made them.

What Prove measures also decides what blocks at once when you activate on a workspace that already blocks: see what blocks after you activate. For how to read the numbers, see reading proof results.

The sessions Prove tests on

Prove measures a proposal on sessions it never learned from. Sentisec chooses them for you, when you propose.

• Set aside before learning. The newest fifth of the eligible sessions the proposal considers, never fewer than 20, is set aside before the proposal reads any session. The proposal does not learn from them. They are listed under Frozen holdout on Protection → Learn.
• Eligible means recorded in the proposal's window, with at least one tool call, and not kept out of learning.
• From 60 eligible sessions. With fewer, nothing is set aside, and the proposal says so. Let your agents record more sessions, then propose again.
• The same set each time. A session set aside stays set aside. Proposing again on the same traffic reuses the set instead of taking another fifth.
• Labelled by a person. A set-aside session counts once someone labels it: normal work, a confirmed threat, or skipped. Label them one by one, or mark every unlabelled one as normal work in one recorded act. A clean verdict is never a label.

Prove also builds attacks from the set-aside sessions of normal work, to measure what the proposal catches.

When activation is refused

Activation is refused when the result misses the quality targets: too few attacks caught, or legitimate work blocked. The refusal names the target it missed, and Protection → Prove shows each measured value next to its target.

What blocks after you activate

On a workspace in Shadow, activating a contract blocks nothing until you turn enforcement on. On a workspace that already blocks, activation does not turn every new blocking rule on at once:

• A rule Prove saw working blocks at once. That is a rule that stopped at least one harmful action in Prove and no good work.
• Every other new blocking rule watches. It records what it would have stopped and stops nothing, and it says why it only watches: for example, Prove counted no harm it stopped, or it stopped good work in Prove.
• You arm a watching rule yourself. A workspace admin arms it on Protection → Enforce, under Rules to arm, once a Prove result shows it catching harm without stopping good work.
• A rule you disarmed stays disarmed when you activate a contract again.
• A rule you set to warn watches until you arm it. Arming it makes a new revision of the contract, which you prove and activate like any other.

Keep a session out of learning

Some runs should not teach the contract: a test you ran by hand, an incident, traffic that is not normal work. A workspace admin can choose Exclude from learning on the session, below its steps, and give a reason. The session stays recorded and visible; the next proposal skips it, and does not hold it back to test the proposal either. Excluded sessions are listed on Protection → Learn, each with Include again, and a proposal names the sessions it did not read. The same is available through the Sessions API.

The model calls Sentisec makes for you

To propose a contract, Sentisec may call a model to classify tools it has not seen, to fill in what their arguments carry, and to draft the contract's plain-language summary. Proposing again is how a workspace fills argument classes that are still unknown. Those calls run on your own provider: the newest provider and model your agents used successfully through Sentisec, with the key you stored under Settings → Providers. Sentisec's own model keys are never used, and your provider bills the calls.

• Capped. A proposal makes at most 24 model calls by default, retries included. The cap is checked before each call, so a proposal never goes over it.
• Recorded. Each proposal records its model calls: how many and what for, the provider and model, and the tokens used (unknown when the provider does not report them). The API returns this record in the proposal's coverage.model_calls.
• Failures are stated. When model calls fail, the proposal on Protection → Learn says how many failed, with the provider and model, and what it did without them: argument classes not filled, or a summary from the template. It also says how many calls were not made once the cap was reached. Fix the cause, then propose again.
• Read as answered. Some models wrap their answer in a Markdown code block. Sentisec reads one complete code block as the answer; text around it, several blocks or malformed content are rejected. A rejected answer is retried within the cap, and the reason is logged without the model's text.
• Optional. Through the API, a proposal can turn model calls off (use_model: false) or set the cap, from 1 to 200 (max_model_calls). Without model calls, Sentisec classifies from each tool's declaration and drafts the summary from a template.

This works with your keys for Anthropic, OpenAI, Moonshot Kimi and Amazon Bedrock. A workspace with no such key gets no model calls, and the proposal says why. A self-managed install can name one model endpoint of its own as the fallback for those workspaces; it is in the configuration reference that comes with self-managed deployment.

Why a call got its verdict

Open a step on a session's page to see the rule that flagged the call, which checks examined it and how each ended, and whether an approval released it. See what a verdict explains in the dashboard.

Settings

Protection is its own destination; it is not a tab of Settings. Administrative controls depend on your organization role. Read-only access does not grant permission to change a workspace.

Organization and billing

Open the workspace switcher for Organization, the workspace list and Billing. Connection setup belongs under Settings → Connect; there is no separate Edge destination to learn.

Next

• Quickstart — connect an application or agent.
• Subscription mode — local agent setup.
• Verdicts — interpret recorded judgments.
• Keys management — credential handling.

Updates / contradictions

2026-09-09 — Updated the map to the consolidated navigation: Sessions and Requests replace the ambiguous Traces label, Evidence replaces Forensics, Posture owns enforcement choices, and Connect owns both setup paths. Removed the earlier claim that a first session unlocks a larger sidebar.

2026-10-15 — Provider keys moved: they now sit in the Provider keys section of Settings → Upstreams, and the old Provider keys address opens that page. The tab table now lists Upstreams and Data & privacy; capture settings left General for Data & privacy. The workspace-key button reads Issue key.

2026-10-16 — The Upstreams tab of Settings is now Providers; the address did not change. Exclude from learning sits on the session, below its steps: the session list no longer has a Learning column. Activating a contract on a workspace that already blocks arms only the rules Prove saw working; see what blocks after you activate.