How Sentisec works
Point your agent at a Sentisec base URL. Supported model calls carry your workspace policy; tool proposals are checked before release, and evidence explains the decision.
Sentisec is a proxy that speaks supported provider APIs. Point your agent at its workspace URL and authenticate with a Sentisec key. The integrity engine evaluates supported tool proposals against the workspace policy before releasing them to your agent. In enforce mode, blocked proposals are replaced with a response explaining the decision. Your agent remains responsible for executing the tools it receives.
This page explains that loop end to end.
What you change
Two values: a base URL and an API key.
# Anthropic-shaped clients
export ANTHROPIC_BASE_URL="https://api.sentisec.ch/ws/<your-workspace-id>"
export ANTHROPIC_API_KEY="sk_sentisec_..."
# OpenAI-shaped clients
export OPENAI_BASE_URL="https://api.sentisec.ch/ws/<your-workspace-id>/v1"
export OPENAI_API_KEY="sk_sentisec_..."Your provider credential stays yours. You paste it once into your workspace, Sentisec encrypts it, and it is used to reach the provider on your behalf. Your application code, your prompts, and your tool definitions are untouched.
Use the workspace-scoped base URL — the form with /ws/<your-workspace-id>
in it. That is the form that guarantees your workspace's policy travels with
every request, on every transport.
The request loop
The call arrives
Your agent sends an ordinary request — Anthropic Messages or OpenAI Chat Completions, streaming or not. Sentisec authenticates it, resolves which workspace it belongs to, and loads that workspace's policy.
The engine evaluates it
The integrity engine reads the call in the context of the session, not as an isolated string. It knows what the agent was asked to do, what content has entered the conversation since, where that content came from, and what the agent is now reaching for. It scores that against your policy and produces one of four verdicts.
This is the part a content filter cannot do. A filter asks "does this text look dangerous?" The integrity engine asks "does this action make sense, given everything this session has seen?"
The verdict selects an intervention
Your policy maps the verdict to an intervention: PROCEED, SANITIZE,
HALT, or ABORT. HALT and ABORT are the two that stop a call. See
Verdicts and interventions for what each one does.
The call is forwarded, or it is not
An allowed tool proposal is released to the client. On a blocking intervention in enforce mode, the proposal is withheld or replaced and your agent gets a response describing the block. Provider compatibility adjustments can still change the wire representation; see Bedrock.
The decision is recorded
Verdicts are recorded against the session, and session closure starts evidence sealing. The dashboard distinguishes recorded evidence from missing or unavailable evidence; configured exports can deliver events to your SIEM.
What a block actually looks like
This is the detail that matters most in practice, because it determines whether your agent survives a block or crashes on it.
A policy block uses a response in the provider's format, never an
error status. By default the offending call is withheld: it is removed
from the answer and assistant text explains it in its place,
[Sentisec blocked tool_use: …]. Other calls in the same answer that
only read go through. A call that changes something is not sent when
another call in the answer is held or refused, so an agent cannot
announce an action that has not happened
(calls proposed together).
The turn ends with a standard stop value. The shape is the same streamed
or not.
With no call left to run, your agent's loop ends and the explanation is
its answer. If you would rather the model re-plans, a workspace admin can
opt in to rename, which hands the blocked call back as
sentisec_tool_call_blocked; treat that as a denial, never a tool to run.
Both shapes are in
what happens when a tool call is blocked.
Shadow first, then enforce
Every workspace runs in one of two modes, switchable from the dashboard:
- Shadow — the engine evaluates every call and records the truthful verdict, but every call passes, including malformed or text-form tool-call attempts.
- Enforce — interventions apply.
Enforce is the fail-safe default. If the workspace's protection setting is missing or unreadable for any reason, Sentisec resolves to enforce rather than to open. Coverage still depends on the configured policy and supported API.
Review recorded traffic, learn and review a candidate policy, then use Prove before activation. Check both denied actions and legitimate task completion on live traffic.
What gets recorded
Captured calls in order, with recorded verdicts, model, latency, tool calls, and token counts when the provider supplies them.
Verdicts stream into the dashboard as they happen, so an operator can watch a run in real time.
Sealed records have a hash-chained bundle and an Ed25519-signed manifest. An auditor can verify their integrity independently. Recording failures remain distinct from sealed evidence.
Eligible policy findings enter a review queue where an operator can mark a confirmed threat, a false positive, or expected behaviour. Structural tool-call holds are recorded without creating a review card.
Every administrative action — key minted, credential rotated, protection mode changed — is written once and never updated or deleted.
Point a webhook at Splunk, Sentinel, or your own collector and events arrive as they are produced.
Reading proof results
From 0.8, proof results distinguish independent evidence from causal replay evidence:
- Independent evidence uses eligible cases labelled independently of Sentisec's own verdict, with enough recorded detail to assess the candidate. Constructed changes to another case and labels derived from a verdict do not enter that independent population. Authored test cases remain test cases, not observed customer traffic.
- Causal replay assesses what the candidate would do on recorded cases and eligible constructed variants. It answers a different question and keeps its own population and exclusions.
Read each result with its numerator, denominator, coverage, and exclusion reasons. Unmeasured never means pass. Empty or insufficient eligible populations cannot establish a passing independent result. A replay score is not proof that an executor withheld an action or that a business task completed.
Some controls are measured only on live traffic. In particular, offline rates do not count catches, passes or false blocks made by controls that block based on learned relationships; command-shape, sensitive-path, and unknown control types also remain unmeasured offline. Such a control can only add blocks, so a block made by a control Prove does measure always counts: a call your labels say is legitimate, blocked offline by a measured control, is a false block even when the same session also reaches an unmeasured one. Those exclusions are not successes and must stay visible when assessing coverage. Validate the actual executor outcome and legitimate task completion separately.
When Prove cannot run on a candidate, the answer says why in plain words and what to do next.
By default, the independent result is measured on sessions set aside before the candidate was learned; see the sessions Prove tests on. What to do when a result misses the quality targets is in when activation is refused. On a workspace that already blocks, a rule blocks at once after activation only when Prove saw it stop harm and no good work; the others watch until an admin arms them. See what blocks after you activate.
Where Sentisec runs
| Deployment | What you operate |
|---|---|
| Hosted | Connect a provider and use your workspace URL at api.sentisec.ch; the dashboard is at app.sentisec.ch. |
| Self-hosted | Run the published container stack on your infrastructure. See Deployment. |
| In your VPC | Use a dedicated Sentisec deployment with your identity provider, storage, and keys. See Enterprise. |
Next
Concepts
The three pages that make every other page read faster: how Sentisec works, the attack class it defends against, and what a verdict means.
Threat model
Sentisec defends against one class of failure: an agent taking a real action because something it read steered it off-task. This page defines that class precisely, and states what Sentisec does not cover.