Adjust for clarity

about/security/least-privilege-access.mdx

@@ -13,21 +13,13 @@ The practical goal isn't "as little access as physically possible" - it's a narr
 
 ## What tight scoping actually buys you
 
-- **Smaller blast radius.** If an account is compromised, the attacker inherits only what that account could reach - not the whole organization.
-- **Fewer moving parts per environment.** Fewer people with standing access to a given system means fewer unexpected changes and a more predictable environment.
-- **Faster incident response.** When access is scoped by role, you can immediately narrow "who could have done this" to the handful of people who actually had the ability to.
-- **Clearer ownership.** Access mapped to job function makes it obvious who's responsible for what, instead of everyone having a bit of everything.
-- **Easier onboarding and offboarding.** Assigning and removing a role is simpler than auditing an individual's sprawling permission history.
-- **Regulatory alignment.** Many compliance frameworks specifically expect access to be scoped to job function - this is one of the easier boxes to check when it's built in from the start rather than bolted on.
+If an account is compromised, tight scoping means the attacker inherits only what that account could reach - not the whole organization. It also means fewer people hold standing access to any given system, so there are fewer unexpected changes and a more predictable environment overall. When an incident does happen, scoping by role lets you immediately narrow "who could have done this" to the handful of people who actually had the ability to, instead of auditing everyone.
+
+There's an ownership benefit too: access mapped to job function makes it obvious who's responsible for what, instead of everyone having a bit of everything. Onboarding and offboarding get simpler, since assigning or removing a role beats auditing an individual's sprawling permission history one entry at a time. And a lot of compliance frameworks specifically expect access to be scoped to job function - this is one of the easier boxes to check when it's built in from the start rather than bolted on afterward.
 
 ## How narrow scope limits real attacks
 
-Most breaches don't start with an attacker breaking into everything at once - they start with one foothold, then depend on that foothold being able to reach more than it should. Tight scoping directly blunts this:
-
-- **Escalation attempts stall out.** Whether an attacker is trying to climb from a low-privileged account into an administrative one, or hijack a peer's similarly-scoped credentials, there's simply less to climb into if roles are narrow to begin with.
-- **A single stolen credential goes less far.** Passwords get phished, reused, or leaked in unrelated breaches constantly. If that credential only unlocks one role's resources, the damage is contained.
-- **Malware can't pivot as easily.** Software that hijacks a session or a device inherits whatever that session could reach - nothing more.
-- **Insider risk shrinks.** A disgruntled or careless employee, whether acting deliberately or by mistake, can only affect the systems their role actually touches.
+Most breaches don't start with an attacker breaking into everything at once - they start with one foothold, then depend on that foothold being able to reach more than it should. Tight scoping blunts this at every step. An attacker trying to climb from a low-privileged account into an administrative one, or hijack a peer's similarly-scoped credentials, simply has less to climb into if roles are narrow to begin with. A single stolen credential goes less far, too: passwords get phished, reused, or leaked in unrelated breaches constantly, and if that credential only unlocks one role's resources, the damage is contained. Malware that hijacks a session or a device inherits whatever that session could reach and nothing more. And insider risk shrinks - a disgruntled or careless employee, whether acting deliberately or by mistake, can only affect the systems their role actually touches.
 
 ## Applying least privilege with Pangolin
 

about/security/zero-trust-networking.mdx

@@ -9,26 +9,21 @@ Zero trust networking starts from an uncomfortable assumption: the network your
 
 For a long time, network security was designed like a building: a hardened perimeter - the firewall - kept threats out, and everything inside that boundary was implicitly trusted. VPNs extended that same trusted interior out to remote workers. It's sometimes described as a hard shell around a soft interior.
 
-That model breaks down once you account for how internal networks actually get compromised. Well-documented breaches at major technology companies have shown attackers reaching deep into "internal" infrastructure once they cleared the perimeter once. Add unencrypted internal DNS traffic and employees working from coffee shop Wi-Fi, and the idea that anything inside the firewall is automatically safe stops being credible. If the perimeter is the only thing enforcing security, one gap anywhere in it compromises everything behind it.
+That model breaks down once you account for how internal networks actually get compromised. Well-documented breaches at major technology companies have shown attackers reaching deep into "internal" infrastructure once they cleared the perimeter. Add unencrypted internal DNS traffic and employees working from coffee shop Wi-Fi, and the idea that anything inside the firewall is automatically safe stops being credible. If the perimeter is the only thing enforcing security, one gap anywhere in it compromises everything behind it.
 
 ## What replaces trusting the wire
 
-The fix is removing the network itself from the trust decision entirely:
-
-- **Encrypt every connection, always**, regardless of whether the traffic is "internal" or "external." There's no privileged segment where encryption gets dropped because it's assumed to be safe.
-- **Authorize by identity, not location.** What a connection is allowed to reach should depend on who or what established it, not which subnet it originated from.
-- **Contain compromise at the peer.** If a device is breached, restricting which encrypted peers it's authorized to reach means the attacker can't simply pivot to whatever else happens to share that network segment.
+The fix is removing the network itself from the trust decision entirely. Every connection gets encrypted, always, regardless of whether the traffic is "internal" or "external" - there's no privileged segment where encryption gets dropped because it's assumed to be safe. Authorization is based on identity, not location: what a connection is allowed to reach depends on who or what established it, not which subnet it originated from. And compromise gets contained at the peer - if a device is breached, restricting which encrypted peers it's authorized to reach means the attacker can't simply pivot to whatever else happens to share that network segment.
 
 Even if someone gains physical or logical access to the network itself, all they find is encrypted traffic between authorized peers - nothing to sniff, and no ability to move laterally without valid credentials of their own.
 
 ## How this shows up in Pangolin's architecture
 
-Pangolin is built around this model rather than having it added on top:
+Pangolin is built around this model rather than having it added on top. Every tunnel is encrypted by default, with no exceptions: site connectors and clients build their tunnels on WireGuard, coordinated by Pangolin's tunnel manager ([Gerbil](/development/system-architecture#nodes)) on the node side and the shared client stack ([Olm](/development/system-architecture#shared-client-stack-olm)) on the device side. There's no unencrypted "trusted internal" path anywhere in the data plane.
 
-- **Every tunnel is encrypted, by default, with no exceptions.** Site connectors and clients build their tunnels on WireGuard, coordinated by Pangolin's tunnel manager ([Gerbil](/development/system-architecture#nodes)) on the node side and the shared client stack ([Olm](/development/system-architecture#shared-client-stack-olm)) on the device side. There's no unencrypted "trusted internal" path anywhere in the data plane.
-- **Site connectors are deny-by-default proxies.** Installing a [site](/manage/sites/understanding-sites) doesn't expose anything on that network. Nothing is reachable until you explicitly define a [resource](/manage/resources/understanding-resources) and grant a role access to it - the network being reachable is never itself the authorization.
-- **Authentication happens per request, not per network.** Public resources are enforced through forward-auth middleware ([Badger](/development/system-architecture#nodes)) sitting in front of every request, and private resources are only reachable by clients that already hold a valid, role-scoped tunnel - being on the same LAN as a site connector grants nothing on its own.
-- **Access follows the user, not the connection point.** [Roles](/manage/access-control/create-user#roles) determine which resources a client is authorized to reach, and that access control list travels with the identity whether they're connecting from the office, home, or a coffee shop.
+Site connectors are also deny-by-default proxies - installing a [site](/manage/sites/understanding-sites) doesn't expose anything on that network. Nothing is reachable until you explicitly define a [resource](/manage/resources/understanding-resources) and grant a role access to it; the network being reachable is never itself the authorization. Authentication happens per request, not per network: public resources are enforced through forward-auth middleware ([Badger](/development/system-architecture#nodes)) sitting in front of every request, and private resources are only reachable by clients that already hold a valid, role-scoped tunnel - being on the same LAN as a site connector grants nothing on its own.
+
+Access follows the user rather than the connection point. [Roles](/manage/access-control/create-user#roles) determine which resources a client is authorized to reach, and that access control list travels with the identity whether they're connecting from the office, home, or a coffee shop.
 
 ## Rolling this out without a flag day