Explore: an inbound permission surface so external tools submit their side effects to the harness policy engine

Area to explore, paired with stacklok/contextlok#2 (shipping packaged CLIs as wasm modules). The two ideas compose into something bigger than either alone: dynamically adding tools to the harness per session, with every external call the tool makes going through the same policy engine as the agent's own tool calls.

The idea

Today the harness approves programs, not effects. Once ohtli close is allowed, every subprocess ohtli spawns is invisible and pre-authorized by transitivity. The proposal is an inbound permission surface: an env-injected endpoint plus credential (something like MECATL_PERMISSION_ENDPOINT) that a subprocess can post a permission request to, adjudicated by the machinery mecatl already has for its own tool calls: deny/ask/allow scopes, the layer-2 risk classifier, HiL pause and resume over the stream, and the headless ask-reviewer. The classifier and HiL become a generic mechanism that nests under other processes at arbitrary depth. Tools fall back to standalone behavior when no endpoint is present.

Why wasm turns this from etiquette into enforcement

For a native tool the protocol is cooperative: nothing stops it from just not calling the API. Under contextlok's wasm design, a packaged tool can only reach the outside world through host functions (wasip1 has no process spawning and no network), so the contextlok runtime forwards every exec, and any future network host function, to the harness with no per-tool integration and no bypass. Mediation is structural. Nested processes inherit it, since their execs route through the same chokepoint.

The net effect: a session that installs a package has dynamically extended the harness with new tools, and those tools' subprocess and network activity is policed by the same engine as the agent's, without the tool being trusted or even inspectable. This directly compensates for the wasm inspectability loss noted in contextlok#2: you cannot read the blob, but you no longer need to trust it.

What the design has to get right

• Vocabulary. Submitted requests should be expressed in the shape existing rules already match (a Bash-style command string for execs), so allow/deny scopes apply without a parallel rule language. Network requests need an equivalent shape.
• Attribution. A request should carry the invocation chain (ohtli close -> git push origin main) so the classifier and the human see the nesting context, not a bare command from nowhere.
• Prompt fatigue. ohtli makes dozens of git calls per operation; per-exec HiL is unusable. This only works because scopes can auto-allow the read-only tail (rev-parse, cat-file, diff) and reserve asks for mutations and network. The classifier is the escalation path, not the hot path.
• Wire shape. Nearest prior art is MCP elicitation and ACP's permission-request flow; model on one of those rather than inventing.
• Trust boundary honesty. For anything not running under the wasm runtime this remains cooperative, and the docs should say so plainly.

No implementation files or tests are named. Start by tracing the existing permission rules, layer-2 classifier, HiL stream pause/resume, and headless ask-reviewer, then compare MCP elicitation and ACP permission flows. Done means a documented design for request vocabulary, invocation attribution, nested mediation, prompt scoping, and the cooperative-versus-wasm trust boundary.