Trust Boundaries Around an Untrusted Agent
OpenWiki asks an agent to read repository material and write documentation, but that does not make repository material trustworthy or the agent harmless. The central problem here is how to let a fallible, potentially prompt-injected worker investigate one page without granting uncontrolled access to the repository or leaving partial edits behind. OpenWiki's read boundaries, write boundaries, ownership rules, snapshots, and interruption states give an operator a way to predict what will happen when the input is hostile or the worker fails.
The overreach problem has several causes
A repository can contain instructions that look like ordinary documentation but are actually attempts to redirect an agent. It can also contain generated files, secrets, Git metadata, symbolic links, or paths whose meaning changes after normalization. Even without a malicious author, a model can misunderstand its assignment and write to the wrong file. These are different symptoms of the same architectural risk: a model is being asked to operate on a filesystem whose contents it does not control.
OpenWiki responds with layers rather than one broad permission. The first layer is the repository's .openwikiignore boundary. An ignored path is hard-denied for reads, writes, and edits. Discovery tools such as listing, globbing, and searching filter ignored entries so the model does not learn about them accidentally. When any ignore rule is active, arbitrary shell execution is restricted to a small allowlist, because a general shell command cannot be proven not to read an ignored path. The safe alternative is to use the gated file tools, which apply the same boundary to each operation.
The second layer is docs-only confinement. Repository init and update work through a backend configured so that writes, edits, and deletes must remain below openwiki/. A page worker can be narrowed further to its assigned page. This is a write boundary, not a claim about which repository files are relevant to the explanation. The worker may read source files needed for research, but it cannot turn a documentation task into an arbitrary code or configuration edit.
The third layer is state ownership. openwiki/.claims is not ordinary documentation, even though it lives below the wiki directory. It is an implementation-owned sidecar area. Generic reads and discovery hide it, writes and edits refuse it, and shell commands that refer to it are rejected in repository mode. Claim persistence happens through the lifecycle core, where the system can validate ownership, evidence, and page-version relationships. If a model could directly edit the sidecar, it could make a page appear grounded without passing the reconciliation and durability checks.
Path canonicalization is what makes these layers meaningful. OpenWiki normalizes separators and path segments before testing them, so an input such as a path that appears to leave and then re-enter openwiki/ cannot bypass the docs-only check. It also refuses broad root globs and globs that target .git metadata, steering repository discovery toward explicit directories and searches. The boundary is therefore based on the resolved path and operation, not on the model's intent or the spelling it chose.
The distinction between filtering and denial is purposeful. A discovery call can omit an ignored entry because revealing that entry would already weaken the read boundary. A direct read or write of the same path returns an explicit refusal, so a worker cannot treat an empty search result as permission to guess or recreate the hidden file.