Update docs

docs/README.md

@@ -1,26 +1,26 @@
 # Fence Documentation
 
-Fence is a sandboxing tool that restricts **network** and **filesystem** access for arbitrary commands. It's most useful for running semi-trusted code (package installs, build scripts, CI jobs, unfamiliar repos) with controlled side effects.
+Fence is a sandboxing tool that restricts network and filesystem access for arbitrary commands. It's most useful for running semi-trusted code (package installs, build scripts, CI jobs, unfamiliar repos) with controlled side effects.
 
 ## Getting Started
 
-- **[Quickstart](quickstart.md)** - Install fence and run your first sandboxed command in 5 minutes
-- **[Why Fence](why-fence.md)** - What problem it solves (and what it doesn't)
+- [Quickstart](quickstart.md) - Install fence and run your first sandboxed command in 5 minutes
+- [Why Fence](why-fence.md) - What problem it solves (and what it doesn't)
 
 ## Guides
 
-- **[Concepts](concepts.md)** - Mental model: OS sandbox + local proxies + config
-- **[Troubleshooting](troubleshooting.md)** - Common failure modes and fixes
-- **[Using Fence with AI Agents](agents.md)** - Defense-in-depth and policy standardization
-- **[Recipes](recipes/README.md)** - Common workflows (npm/pip/git/CI)
-- **[Config Templates](templates/)** - Copy/paste templates you can start from
+- [Concepts](concepts.md) - Mental model: OS sandbox + local proxies + config
+- [Troubleshooting](troubleshooting.md) - Common failure modes and fixes
+- [Using Fence with AI Agents](agents.md) - Defense-in-depth and policy standardization
+- [Recipes](recipes/README.md) - Common workflows (npm/pip/git/CI)
+- [Config Templates](templates/) - Copy/paste templates you can start from
 
 ## Reference
 
-- [README](../README.md) - CLI usage + configuration reference
+- [README](../README.md) - CLI + library usage
+- [Configuration](./configuration.md) - How to configure Fence
 - [Architecture](../ARCHITECTURE.md) - How fence works under the hood
 - [Security Model](security-model.md) - Threat model, guarantees, and limitations
-- [Security Policy](../SECURITY.md) - Vulnerability reporting policy
 
 ## Examples
 

docs/security-model.md

@@ -1,8 +1,8 @@
 # Security Model
 
-Fence is intended as **defense-in-depth** for running semi-trusted commands with reduced side effects (package installs, build scripts, CI jobs, unfamiliar repos).
+Fence is intended as defense-in-depth for running semi-trusted commands with reduced side effects (package installs, build scripts, CI jobs, unfamiliar repos).
 
-It is **not** designed to be a strong isolation boundary against actively malicious code that is attempting to escape.
+It is not designed to be a strong isolation boundary against actively malicious code that is attempting to escape.
 
 ## Threat model (what Fence helps with)
 
@@ -21,16 +21,16 @@ Fence is useful when you want to reduce risk from:
 - **Allowlisting by domain**: you can specify `allowedDomains` (with wildcard support like `*.example.com`).
 - **Localhost controls**: inbound binding and localhost outbound are separately controlled.
 
-Important: domain filtering does **not** inspect content. If you allow a domain, code can exfiltrate via that domain.
+Important: domain filtering does not inspect content. If you allow a domain, code can exfiltrate via that domain.
 
-#### How allowlisting works (important nuance)
+#### How allowlisting works
 
-Fence combines **OS-level enforcement** with **proxy-based allowlisting**:
+Fence combines OS-level enforcement with proxy-based allowlisting:
 
-- The OS sandbox / network namespace is expected to block **direct outbound** connections.
+- The OS sandbox / network namespace is expected to block direct outbound connections.
 - Domain allowlisting happens via local HTTP/SOCKS proxies and proxy environment variables (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`).
 
-If a program does not use proxy env vars (or uses a custom protocol/stack), it may **not benefit from domain allowlisting**. In that case it typically fails with connection errors rather than being "selectively allowed."
+If a program does not use proxy env vars (or uses a custom protocol/stack), it may not benefit from domain allowlisting. In that case it typically fails with connection errors rather than being "selectively allowed."
 
 Localhost is separate from "external domains":
 
@@ -57,7 +57,7 @@ Localhost is separate from "external domains":
 
 ### Practical examples of proxy limitations
 
-The proxy approach works well for many tools (curl, wget, git, npm, pip), but **not by default** for some stacks:
+The proxy approach works well for many tools (curl, wget, git, npm, pip), but not by default for some stacks:
 
 - Node.js native `http`/`https` (use a proxy-aware client, e.g. `undici` + `ProxyAgent`)
 - Raw socket connections (custom TCP/UDP protocols)

docs/why-fence.md

@@ -6,10 +6,10 @@ Common situations:
 
 - Running `npm install`, `pip install`, or `cargo build` in an unfamiliar repo
 - Executing build scripts or test runners that can read/write broadly and make network calls
-- Running CI jobs where you want **default-deny egress** and **tightly scoped writes**
+- Running CI jobs where you want default-deny egress and tightly scoped writes
 - Auditing what a command *tries* to do before you let it do it
 
-Fence is intentionally simple: it focuses on **network allowlisting** (by domain) and **filesystem write restrictions** (by path), wrapped in a pragmatic OS sandbox (macOS `sandbox-exec`, Linux `bubblewrap`).
+Fence is intentionally simple: it focuses on network allowlisting (by domain) and filesystem write restrictions (by path), wrapped in a pragmatic OS sandbox (macOS `sandbox-exec`, Linux `bubblewrap`).
 
 ## What problem does it solve?