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.
The egress allowlist is where you tell Sentisec which destinations your agents legitimately talk to. It is the highest-leverage thing you can configure, because most agent compromises end the same way: something in the agent's context talks it into sending data to a host you have never heard of.
When the engine evaluates a tool call, the destinations it finds in that call are checked against this list. A call aimed at a host you have declared reads as ordinary work. A call aimed somewhere else is exactly the signal you want raised.
What an entry looks like
Each entry is a hostname or an IP range — never a URL.
| Form | Example |
|---|---|
| Hostname | api.example.com |
| Wildcard subdomain | *.example.com |
| Hostname with port | api.example.com:8443 |
| IPv4 address | 192.168.1.1 |
| IPv4 range | 10.0.0.0/8 |
| IPv6 address or range | ::1, fe80::/10 |
Rejected, with the reason returned to you:
- anything carrying a scheme —
https://api.example.com - anything carrying a path —
api.example.com/v1 - entries with whitespace, empty entries, entries over 253 characters
If you paste a URL out of a browser, strip the https:// and everything
after the host.
Editing the list
In the dashboard, go to Settings → Egress. You will see your own entries alongside the destinations your workspace's policy already allows by default — model-provider endpoints and the like — so you can tell which entries are yours.
Saving replaces the whole list, rather than appending to it. Edit the list you see and save it as a unit.
An empty list is valid and meaningful: it means nothing beyond the built-in defaults. Some destinations are always refused regardless of what you put here — internal metadata endpoints and similar — because allowing them is never the right answer.
Editing the allowlist is administrator-only, and every change is recorded in the workspace's audit log with the before-and-after counts. A change applies to new sessions; a session already in flight keeps the list it started with.
Getting the list right
The practical approach is to run the workspace in shadow first, let real traffic flow, and read the sessions. The destinations your agents actually reach show up in the timeline. Add the legitimate ones, then flip to enforce.
Starting the other way around — guessing the list up front, in enforce — is how you end up debugging a blocked deployment script at 2am.
Related
- Enforcement mode — shadow vs enforce
- Threat model — why exfiltration is the shape that matters
- Dashboard — where the editor lives
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.
Approval for payments, messages and contact changes
Make money movement, outbound messages and contact or identity changes wait for an admin's approval: always, after the agent has read outside content, or when a recipient or account is not one you know. No learning step needed.