Enforcement mode
Run a workspace in shadow to record verdicts without changing agent behaviour, or in enforce to block. How each mode behaves, and what it takes to switch.
Enforcement mode is the short view of one question: does Sentisec watch, or does it act?
| Mode | What happens |
|---|---|
shadow | The integrity engine runs on every request and records the truthful verdict — but the response is released unchanged. Your agent behaves exactly as it would without Sentisec. |
enforce | The same evaluation, and an unsafe tool call is actually stopped. |
New workspaces start in shadow.
What changes on the wire
In enforce, a blocked tool call is withheld and explained: it is
removed from the answer, assistant text says why, and the turn ends with
a standard stop value, streamed or not. The tool never runs. A workspace
admin can instead opt in to rename, which hands the call back as
sentisec_tool_call_blocked so the model can re-plan; see
what happens when a tool call is blocked.
In shadow, nothing is withheld. Every tool call passes through
untouched, including one Sentisec could not read. The verdict is still
computed and still recorded — you get the complete timeline, the
elevated verdicts, and the forensic evidence, with zero effect on a
running agent.
That is the point of shadow: you can put Sentisec in front of production traffic on day one and read a week of real verdicts before you decide what to block.
Switching
In the dashboard, go to Protection → Enforce. Turn on
enforcement moves the workspace to blocking, and Back to Shadow
moves it back. The dashboard shows both blocking rungs as Enforce,
and the switch moves you to scoped_enforce; every rung is under
More settings → Every protection level. The change takes effect on
the next request — no restart, no redeploy, no client change.
The two directions are not symmetrical, and that is deliberate:
- Turning blocking off always works. Back to Shadow shrinks what may block, so it can never make your traffic less safe to run. It takes a stated reason and is applied immediately.
- Turning blocking on can be refused. Turn on enforcement is a promotion up the posture ladder, and a promotion is checked against evidence — vouched counterparties, a clean measured window at your current rung, and a proven policy where one governs the workspace. If the evidence is not there, the request is refused, your workspace is left exactly where it was, and each unmet requirement is shown with what was measured, what is required, and the one action that closes it. The same requirements are listed as a checklist above the button before you press it.
A brand-new workspace with no traffic and no policy will not be able to
reach enforce on its first day, and the refusal will tell you what to
do about it. Protection setup
is that path: it registers what your agents can do, classifies each
action and checks your rule names actually reach them. You then choose
the rung on Protection → Enforce.
Switching enforcement mode is administrator-only. If the control is read-only for you, you are a member rather than an admin of the organisation.
Fail-safe
A workspace is never accidentally unprotected. If the stored setting is
missing, empty, unreadable, or anything other than a value Sentisec
recognises, it resolves to enforce. There is no configuration mistake
and no infrastructure failure that silently turns protection off.
Two different questions, and it is worth keeping them apart: what a
workspace starts on is shadow, deliberately, so that connecting
Sentisec never changes how your agents behave on day one. What an
unreadable setting resolves to is enforce. The first is a product
decision about your first hour; the second is a fail-safe about a
corrupted row, and aligning them would either start you blocking on day
one or leave a damaged workspace unprotected.
A suggested rollout
Start in shadow on a workspace carrying real traffic. This is where you already are.
Run protection setup. Registering what your agents can do is what lets anything be governed later, and it takes a few minutes.
Read the sessions. Look at what got flagged and why. This is where you learn what your agents actually do.
Tighten what needs tightening — most commonly the egress allowlist, so the destinations your agents legitimately use are recognised.
Move up the ladder. Blocked calls are now withheld and explained instead of executed. Most teams want the scoped rung, not the full one — see the posture ladder.
Because mode is per workspace, you can run staging blocking and
production in shadow — or the reverse — while you build confidence.
Related
- Posture ladder — the four rungs behind these two modes
- Protection setup — the guided flow that gets you there
- Egress allowlist
- Verdicts — what each verdict level means
- Dashboard — where the setting lives
Posture ladder
The four rungs a workspace can run on, what each one is allowed to block, and why moving up is gated on a measurement while moving down never is.
Egress allowlist
Declare the hostnames and IP ranges your agents are allowed to reach, so a tool call aimed anywhere else stands out as exfiltration.