Isolation
Run agent sessions in a network-isolated namespace.
Flip a per-company policy to run agent sessions inside their own network namespace (netns). In netns mode, outbound egress is denied by default, so an agent can't exfiltrate your data over the network. It's opt-in - the default is off.
Agent session · netns
- Own network namespace
- Loopback + control socket only
- Egress denied by default
- No raw outbound to the internet
Outside world
- Public internet · blocked
- Other tenants · unreachable
- Internal services · allow-list (roadmap)
- Policy is per-company · default off
How it works
1
Set the policy
Choose a per-company sandbox mode: off (default) or netns for network-isolated sessions.
2
Session starts in netns
In netns mode, each agent session runs inside its own Linux network namespace.
3
Egress denied by default
Outbound network traffic from a sandboxed session is blocked, so it can't reach the public internet.
4
Work stays contained
The agent can do its job inside the namespace without an open path to exfiltrate over the network.
Deep dives
Network namespace confinement
netns mode places each agent session in its own Linux network namespace. This is network-level confinement of egress - not a full seccomp/syscall sandbox.
Default-deny egress
Inside a netns-mode session, outbound network access is denied by default, removing the easy path for an agent to send data off the box.
Per-company, opt-in
Sandbox mode is a company-level setting and ships off by default. Turn it on for the companies that need network isolation; leave it off elsewhere.
Turn on egress isolation
shell · per-company egress policy
# Opt in: run agent sessions in a network namespace
$ synaptyx company set-sandbox --mode netns
✓ sandbox_mode = netns · applies to new sessions
# Inside a sandboxed session, outbound is denied by default
$ curl https://example.com
curl: (7) Couldn't connect — network is unreachable
# Default stays off until you flip it
$ synaptyx company get-sandbox
sandbox_mode: off # off | netns
Network isolation that's honest about its scope.
This is netns-based egress confinement: outbound network access is denied by default inside a sandboxed session. It is not a full syscall sandbox - we describe exactly what it does and nothing more.
Compare
| Synaptyx | No isolation | Container-only | |
|---|---|---|---|
| Per-session network namespace | netns mode | no | shared by default |
| Egress denied by default | yes | no | no |
| Per-company policy | off | netns | no | image-level |
| Default posture | off · opt-in | open | open |
| Internal allow-list | roadmap | no | no |
FAQ
No - and we won't claim it is. Today it's network-namespace egress confinement: sessions run in their own netns where outbound network access is denied by default. It is not seccomp/syscall sandboxing.
No. Sandbox mode is off by default and set per company. You opt in by switching the policy to netns; until then sessions run as they do today.
In netns mode egress is denied by default. A scoped internal allow-list for approved destinations is on the roadmap; today the safe assumption is no outbound from a sandboxed session.
No - it complements them. Egress isolation limits what an agent can reach over the network; the audit trail records what it did and budgets cap what it spends. Use them together.
Ready to isolate your agent sessions?
Request access in minutes - or talk to us about your isolation requirements.