diff --git a/README.md b/README.md
index 19689bf..541822e 100644
--- a/README.md
+++ b/README.md
@@ -20,6 +20,7 @@ You can use Fence as a Go package or CLI tool.
 ## Documentation
 
 - [Documentation index](docs/)
+- [Configuration](docs/configuration.md)
 - [Security model](docs/security-model.md)
 - [Architecture](ARCHITECTURE.md)
 - [Examples](examples/)
diff --git a/docs/README.md b/docs/README.md
index c53e0a2..57f756e 100644
--- a/docs/README.md
+++ b/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
 
diff --git a/docs/security-model.md b/docs/security-model.md
index 60be811..7858a67 100644
--- a/docs/security-model.md
+++ b/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)
diff --git a/docs/why-fence.md b/docs/why-fence.md
index 3429018..d56129d 100644
--- a/docs/why-fence.md
+++ b/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?
 
diff --git a/examples/README.md b/examples/README.md
index bec568c..7d5e8e6 100644
--- a/examples/README.md
+++ b/examples/README.md
@@ -11,5 +11,5 @@ If you're looking for copy/paste configs and "cookbook" workflows, also see:
 
 | Example | What it demonstrates | How to run |
 |--------|-----------------------|------------|
-| **[01-dev-server](01-dev-server/README.md)** | Running a dev server in the sandbox, controlling **external domains** vs **localhost outbound** (Redis), and exposing an inbound port (`-p`) | `cd examples/01-dev-server && fence -p 3000 --settings fence-external-blocked.json npm start` |
+| **[01-dev-server](01-dev-server/README.md)** | Running a dev server in the sandbox, controlling external domains vs localhost outbound (Redis), and exposing an inbound port (`-p`) | `cd examples/01-dev-server && fence -p 3000 --settings fence-external-blocked.json npm start` |
 | **[02-filesystem](02-filesystem/README.md)** | Filesystem controls: `allowWrite`, `denyWrite`, `denyRead` | `cd examples/02-filesystem && fence --settings fence.json python demo.py` |