pando-ai 1.2.1 → 1.2.3

package/README.md

@@ -69,11 +69,11 @@ Four layers, one ruleset:
 
 Pando's security model has three separate jobs:
 
-- **Containment**: the `pando` MCP process runs model-triggered
-  workspace mutation in an OS sandbox. The sandbox limits the process to the
-  project root and sandbox-local home/cache/temp directories. Network and local
-  sockets are allowed. This is the hard boundary for broad operations such as shell
-  commands and generated code.
+- **Tool-traffic enforcement**: policy is applied on the wire, not by
+  sandboxing the process. Claude Code hooks and the local provider gateway block
+  off-policy tool definitions, tool calls, and tool results before the agent can
+  act on them. Pando MCP is always allowed; native tools and non-Pando MCP are
+  denied by default.
 - **Audit and recovery**: mutating Pando tools and `shell-command` create Pando
   snapshots around workspace changes. These are local, commit-like history
   records for inspection and restore; they are not commits to the user's Git
@@ -84,7 +84,11 @@ Pando's security model has three separate jobs:
   keep requests bounded, make intent inspectable, require stable paths/hashes
   where relevant, and reduce the need for raw shell/file access.
 
-The sandbox and snapshots are the fallback safety boundary. The Pando tools are
+Workspace roots are also gated: paths under system, credential, and container
+directories cannot become a Pando workspace root (see `forbidden-roots`), so
+model-triggered mutation stays scoped to real project roots.
+
+Snapshots are the fallback safety boundary. The Pando tools are
 the preferred control plane: they make ordinary coding work narrower, more
 auditable, and more semantically meaningful than arbitrary command execution.
 Shell remains available for tests, builds, package managers, generated files,