Protection setup

Connecting a workspace tells Sentisec where your traffic goes. Protection setup tells it what your agents are allowed to do.

It is four screens in the dashboard, one decision per screen. You reach it from Run protection setup on Protection → Overview; the screens sit under Tools & rules, in the rail's Advanced group. When you finish, you continue on Protection, where you choose the rung of the posture ladder your workspace runs on.

The four screens

A fifth page, Channels & readers, linked under the steps, holds the declarations of whose content each tool returns (see who wrote a tool's results).

Each screen is its own URL, so browser back works, a link to a screen is shareable, and a resumed session is never ambiguous about where you are.

Steps 1, 2 and 3 are required. Step 4 is genuinely optional — skipping it is recorded as a choice, not left as a silent gap, and it blocks nothing.

1 · Action registry

You registered your agents when you connected them. This registers what they can do.

Paste the tool list your agents already ship with. Four shapes are accepted — an MCP tools/list response, an OpenAI tool array (either form), an Anthropic tool array, or Sentisec's canonical form. The screen reads the shape from the entries you paste and says which one it found; the shape selector applies only when no entry matches a known shape.

Two buttons, in this order:

A tool with no schema cannot be governed

This is the one thing on this screen worth reading twice.

A tool declaration that carries no description of its arguments — no JSON Schema — cannot be classified, and an action with no class cannot be governed. Not governed more weakly. Not governed later. Not at all.

So the screen splits your tools into what can be governed and what cannot, states the count for each, and gives the reason. Declare the argument names and types for a schemaless tool and it moves across.

If none of your tools carries a schema, setup says so rather than reporting success. You get "N tools declared, and none of them can be governed" — because every other signal on that screen looks like the happy path (the request succeeded, nothing was rejected, rows were written), and "setup succeeded and nothing is protected" is the single most expensive thing this flow could let you believe.

The arithmetic is on screen

The result shows accepted + rejected = offered. That is there so you can verify a payload was not half-swallowed instead of taking our word for it — if the three numbers ever fail to add up, the screen says so and tells you not to rely on that registry.

Re-running is normal

A new integration means a new tool list. Re-running is a diff, not a reset: existing tools are re-stamped, new ones are added, and a tool whose schema changed shows up as a shape change with the previous shape retained. Nothing you previously declared is deleted.

2 · Action identity

Every action gets a class. There are five that matter:

• money movement
• counterparty change
• credential change
• external send
• destructive write

Sentisec proposes one thing about your tools on its own: whether people outside your organisation write what a tool returns (see who wrote a tool's results). Every other class comes from you. Set it on this screen, or run the classifier below, which proposes classes and flags the arguments that identify a counterparty. You then take one of three actions on each tool:

Your corrections are scoped to your workspace. Reclassifying a tool never changes how that tool is treated for anyone else.

The screen also keeps two different kinds of "nothing happened" apart: a cache-only run tells you the remaining tools have not been looked at; a run you opted into that reached no classifier tells you nothing was called and nothing was billed.

Argument classes unknown

Besides a tool's class, Sentisec keeps what each of its arguments carries, such as an account, an address or an amount. In the tool table on Action registry, a tool whose argument classes are not known yet is marked argument classes unknown.

What that means for protection, until they are filled:

• Checks on what an argument carries see only a value's shape. An email address or a URL is still recognised as a destination. An account number, a vendor id or an amount is not, so a check that looks for one has nothing to examine in that tool's calls and does not stop them.
• The tool's class still applies. For a payment or messaging tool, the approval policy still holds its calls under always and after_outside_content. Under unanchored_destination, it sees only the destinations it can recognise by their shape.
• It does not flag the session. A watch-only check that could not examine a call says so in the session's record.

Fill them: propose again on Learn

This path works whether or not you declared your tools here:

Classify on this screen fills them too, with the box ticked that lets it call your model (the button then reads Classify (calls the paid API)). Classify works only on the tools declared on Action registry. If your workspace has not declared its tools, Classify has nothing to run on, so use Propose again.

Either way, Sentisec copies a suggestion it already holds for that tool, or asks your model once. Your class corrections are kept: correcting a tool's class does not stop its argument classes from being filled, and filling them never changes a class you set. Without a model call, a tool with no earlier suggestion stays unknown. A workspace with no stored provider key gets no model calls.

Who wrote a tool's results

A tool that only reads can still bring content written outside your organisation into the agent's context. Sentisec decides trust by who wrote what a tool returns, not by where it is stored.

• Untrusted by default: content outsiders can write. That includes inbound email and its attachments, documents others upload or send, support tickets and their comments, customer chat and call transcripts, form submissions and web pages. It stays untrusted when your application reads it by id from its own database or inbox. A call that fetches a URL counts as well.
• Your own: data your organisation writes itself, such as the vendor master, the product catalog, price lists, the ledger and your own configuration.

Sentisec proposes this on its own. When results from a tool you have not classified pass through, and the tool's declaration shows that outsiders write them, as for a tool that reads an inbox, Sentisec proposes outside content for that tool. The Outside content column then reads Yes — outsiders can write its content.

• The proposal is unreviewed. Keep it, or change it with the answer below. Your answer always wins, and Sentisec never overwrites a class you set.
• It never arms a block. It makes the tool's results count as outside content, so values copied from them are treated as untrusted, and after_outside_content in the approval policy can ask. A rule that applies only to outside-content tools keeps watching until you confirm the class.
• It only moves toward untrusted. Sentisec never proposes on its own that a tool's results are your own, and it proposes no other class automatically.

When the classifier proposes classes for a tool, it also asks whether outsiders can write what the tool returns. That answer can only move a tool toward untrusted too. A tool classified before Sentisec asked this is asked once, the next time a model classifies your tools.

Sessions recorded before a tool was marked as outside content were learned as they were recorded: they still count as having no outside content. After you mark a tool, let your agent record new sessions before you propose a contract again.

Only a workspace admin can mark a tool's results as your own. On the Action registry screen, each tool's Outside content column asks Can people outside your organisation write what this tool returns? Choose No, my organisation writes it for a tool whose results your organisation writes. A tool that fetches a URL stays untrusted whatever you answer.

You can also declare it from Channels & readers, in the protection setup steps:

[{ "selector_kind": "tool", "selector": "lookup_vendor", "trust": "trusted" }]

The editor holds the workspace's complete set of declarations, so keep the ones already there and add yours. A declaration with "trust": "untrusted" does the opposite, for a tool whose outside content classification missed. To treat every tool result you have not declared as outside content, turn on Restrict undeclared non-URL results in the reader settings on the same screen.

Correcting a tool's class, or marking it Not governed, keeps its outside-content mark. Only the Outside content answer changes it.

Fields your own system writes

A tool whose content outsiders write often returns a few fields your own system filled in. A helpdesk ticket carries the customer's message, and also the customer id your helpdesk recorded when it matched the sender to an account. You can name those fields, so that Sentisec reads them as your own data while the rest of the result stays outside content.

On Channels & readers, the Fields your own system writes section has one row per tool. A workspace admin types the field names, comma separated, such as customer_id, and chooses Save fields for the tool. Members can read the rows but not change them.

• Saving a tool you have not declared yet declares its results as outside content, except the fields you name. Use it only for a tool outsiders write into.
• A tool declared as your own organisation's has nothing to name, so its row has no field to fill.
• If the declaration editor on the same screen has unsaved changes, save or discard them first.

The row writes the same declaration you can also type into the editor, with each field your system writes marked "internal":

[{ "selector_kind": "tool", "selector": "read_ticket", "trust": "untrusted",
   "field_authorship": { "$.customer_id": "internal" } }]

What changes:

• A lookup keyed by a named field reads your own data. When the agent looks up the customer by customer_id and replies to the address your CRM returns, that reply goes to a destination your data knows. Under unanchored_destination in the approval policy, it goes out without a wait.
• Everything else in the result stays outside content. The message text and every field you did not name are treated as written by an outsider. A lookup keyed by an id copied from the message text is treated as chosen by an outsider, and a reply to an address written in the message still waits.
• Under "trust": "trusted" the list works the other way. Fields marked "external" are outside content in a result that is otherwise your own.

Name a field only when your own system writes it. If a requester can type into it, for example a customer id entered on a web form, leave it out: Sentisec takes your declaration at its word. Sessions recorded before you add a field were learned as they were recorded, so let your agent record new sessions before you propose a contract again.

Coverage that is real, not implied

Not every class is governed by every rule. The screen tells you which of your tools your rules actually cover and which they do not, rather than rendering everything as protected. Coverage that reads as present and is absent is worse than no coverage, because you stop looking.

3 · Name check

Rule matching is on the exact wire string, case included. A rule written for WebFetch never sees a tool your agent sends as webfetch. That is coverage that looks present, is absent, and produces no error anywhere.

So before you rely on anything, setup compares every declared name against four surfaces: your workspace's rules, the tools it has seen before, the tools that can take a vouched counterparty, and the tool list against itself.

Nothing is renamed for you. The wire name is ground truth about what your agents actually send, and the rule is at least as likely to be the wrong half. Silently picking one is how a coverage void becomes a coverage lie. You resolve each void yourself, two ways:

• "The rule's spelling is right — my list is wrong." The entry is corrected, re-fingerprinted and re-classified.
• "My list is right — the rule is stale." The collision is recorded with your assertion, and the rule is reported as not covering that tool. That note stays on screen after you resolve it: a bare "resolved ✓" would tell you the opposite of what happened.

4 · Vouched counterparties

Your counterparty master, signed off out of band: the vendors, accounts and destinations your agents are allowed to be dealing with.

This is the step that changes your timeline the most. With a vouched list in place, a first-contact counterparty is meaningful on day one. Without one, the workspace has to learn its counterparties from its own traffic, and until it has seen enough of them it abstains rather than guessing.

Worth stating plainly, because the arithmetic hides it: a vouched counterparty list is the counterparties you have, not all the counterparties there are. Anyone you have not transacted with recently is a first-contact review the first time they appear. That is the control working, not a false alarm.

Importing that list from the dashboard is not available yet. If seeding one matters for your rollout, get in touch.

Otherwise, skip the step and continue. Skipping is recorded as a decision with a timestamp, and the screen says what skipping costs.

Then: choose when to block

Setup moves no rung. The last screen takes you to Protection, where you learn and prove a contract, then choose when to block on Protection → Enforce: its checklist shows each requirement of the posture ladder with what was measured, and Turn on enforcement moves the workspace up once they are met.

Resolve every name void in step 3 before you turn blocking on: a blocking rung over a rule that cannot fire is the worst of both outcomes.

When setup is complete

Steps 1, 2 and 3 must each be complete, and the workspace must have chosen a rung. Step 4 counts as settled whether you imported a list or recorded a skip.

Re-run it whenever your agents change. Adding an integration means adding tools, and a tool your rules have never heard of is exactly the gap this flow exists to close.

Related

• Posture ladder — the four rungs and what it takes to move up
• Enforcement mode — the shadow / enforce view of the same setting
• Egress allowlist — where your agents are allowed to reach
• Dashboard — the rest of the operator surface

Updates / contradictions

2026-10-16 — Setup has four screens: the time-to-protection read and the staged-promotion screen left the flow, and you choose the rung on Protection → Enforce. Setup starts from Protection → Overview, which replaced the Posture page.