Allow the network domains your agent may reach

By the end of this tutorial you'll know how SSG's default-deny network policy works, how to grant your agent access to a specific domain durably, and how to review what's already allowed.

Hand this to your AI agent

Show me which network domains I've currently allowed for my AI agent, and
if I give you a domain, add it. Do not run `ssg allow` without an explicit
domain from me — with no arguments it opens an interactive TTY checklist
that isn't safe to trigger from a script.

1. Run `ssg list --json` and look for rules whose id starts with
   `allow-domain-`. Summarize which domains are currently allowed.
2. If I give you a domain (for example "I need api.example.com"), run:
   ssg allow api.example.com --non-interactive
   and show me the output. Do not add a domain I didn't explicitly name.
3. Confirm the new rule loaded by re-running `ssg list --json` and
   confirming the new allow-domain-* rule is present.

What your agent will do

• Read your current allowlist with a read-only command.
• Add exactly the domain you name — never a wildcard or broader scope than you asked for — using --non-interactive so it can't accidentally trigger an interactive TTY prompt.
• Confirm the rule actually loaded instead of assuming success.

What you do yourself: decide which domains are actually legitimate for your agent's work. SSG can't make that call for you — approving network access is a judgment call about what your project needs.

Step by step

1. Understand the default

By default, SSG denies network egress your agent hasn't been explicitly granted. See Egress Guard for the plugin that enforces this at the wire level (proxy-based, catches subprocess and MCP traffic too); this page covers the simpler .rules-level allowlist that governs what your agent's own tool calls (WebFetch, WebSearch, and similar) are permitted to reach.

2. Allow a domain from the CLI

ssg allow example.com
ssg allow example.com *.api.example.com    # multiple domains in one call, wildcard supported

This writes (or updates) a rule block in ~/.sigmashake/rules/allowlist.rules. The daemon picks up the change immediately via a rules.db mtime-triggered reload — you don't need to run ssg rule sync afterward.

A domain allow generates a rule shaped like this (example for api.example.com):

rule allow-domain-api-example-com {
  enabled true
  priority 70
  severity info
  ALLOW any
  IF input.url REGEX "^https?://api\.example\.com(?:[:/?#]|$)" OR command REGEX "https?://api\.example\.com(?:[:/?#]|$)"
  MESSAGE "Allowed api.example.com - added from the dashboard."
}

It matches both the request URL field (input.url) and the domain appearing inside a shell command (so curl https://api.example.com/... is covered too), and permits the request from either surface.

3. Allow packages the same way

ssg allow isn't only for domains — the same command handles package installs:

ssg allow lodash --package --manager npm
ssg allow "pip install requests"

4. Interactive mode — clearing a backlog of pending requests

If your agent has already made several requests that got parked as pending ASK items, run ssg allow with no arguments in a real terminal:

ssg allow

This opens a checklist of recent pending items so you can approve several at once. Note: with no arguments and no TTY attached (a script or CI job), this exits with an error immediately rather than hanging — safe to call from automation as long as you always pass explicit domains there.

5. Priority tiers

A normal ssg allow writes at the standard priority. If you need the allow to outrank an existing block or ask guard on that domain:

ssg allow example.com --override

This writes at the override tier (priority 110). Use this deliberately — an override allow beats a DENY that would otherwise apply.

6. Review from the dashboard

The dashboard's Network page (/network) shows two sections: allowed domains and allowed IP addresses (a structurally parallel table backed by its own rules), plus two independent "gate un-listed" toggles — one for domains, one for IPs — that, when on, author a catch-all ASK rule for anything not already covered. Both toggles default off. This is also where you'll see a pending network request land as an ASK item if your agent hits a domain that isn't allowed yet, with an inline "allow" action.

7. Export DB-only rules back to a file

If a rule was added through the dashboard (which writes to the rules database) but never made it into a .rules file on disk, reconcile it:

ssg allow --reconcile

This exports any orphaned, DB-only allow rules back into allowlist.rules so they're file-backed and survive a ssg rule sync round-trip.

Common domains you might allow

These are examples to choose from based on what your agent actually needs — not defaults SSG ships with. Nothing is allowed until you explicitly run ssg allow for it.

Domain	Typical reason
registry.npmjs.org	npm package installs
pypi.org	pip package installs
github.com	git clone/fetch, GitHub API
api.anthropic.com	Claude API calls made directly by your code (not the CLI itself)
crates.io	Rust crate downloads for your own projects

Verify

ssg list --json

Look for a rule whose id matches allow-domain-<your-domain-slugified>. Then trigger the actual network call from your agent and confirm it succeeds — a rule existing and a rule actually matching the traffic shape are two different checks.

If something goes wrong

Symptom	Cause	Next step
ssg allow with no arguments hangs	Non-interactive shell (CI, script) with no TTY	Always pass explicit domain/package arguments in automation, or add --non-interactive to force the error instead of a hang
Domain is allowed but the agent's request still gets blocked or asked	The rule matched the URL/command pattern but a higher-priority DENY/ASK rule still wins	Re-run with --override if you're certain the allow should win, or check ssg list --explain-style output for which rule actually fired
Rule shows in ssg list but not on the dashboard's Network page	The rule was written directly to a .rules file but the daemon hasn't reloaded yet	Give it a moment (mtime-triggered reload is near-instant) or run ssg rule sync
A DB-only allow rule disappears after editing .rules files directly	It was never file-backed	Run ssg allow --reconcile to export it into allowlist.rules

Next

• Egress Guard — wire-level enforcement that also catches subprocess and MCP traffic the tool-call hook never sees.
• Manage the host firewall — a lower-level, host-wide complement to this per-domain allowlist.
• Writing rules — author more advanced .rules by hand instead of via ssg allow.