Define authority boundaries for adapting non-WASI tools to P3

[lthibault]

Context

Wetware P3 Cells operate inside the WASI and capability model. Many existing agent and tool ecosystems instead assume native processes, stdio, sockets, filesystem access, credentials, or ambient host integration.

Wrapping such a tool does not make the wrapped implementation object-capability-safe. Wetware needs an explicit boundary that states which authority Wetware controls and which ambient authority remains behind the adapter.

Problem

The repository does not define a current adoption architecture for non-WASI tools. An adapter can otherwise become an ambient escape hatch that exposes host process, filesystem, network, or credential authority to a Cell.

Desired outcome

Define bounded adapter shapes for common non-WASI tools. Specify the identity, method policy, resource policy, lifecycle, and audit boundary for each shape.

Use a local stdio MCP adapter as the first thin slice. The first slice must expose a bounded capability to a P3 Cell without delegating the adapter process's ambient host authority.

Deliverables

• A threat-modelled integration matrix covering MCP servers, local CLI/native processes, containerized services, remote HTTP APIs, and WASI components.
• One recommended adapter boundary and one explicitly unsupported shape.
• A current API sketch showing where identity, method profiles, resource policy, lifecycle, and audit events attach.
• A runnable local stdio MCP thin slice through the normal P3 Membrane and process lifecycle.
• Documentation that distinguishes authority enforced by Wetware from authority retained by the adapter or wrapped service.
• Focused follow-up implementation issues only after the boundary is established.

MCP thin-slice acceptance criteria

• The host can start or connect to a deterministic local stdio MCP fixture.
• The adapter exposes only an explicit bounded capability to the P3 Cell.
• The P3 Cell does not receive the adapter's raw process, filesystem, socket, environment, or credentials.
• MCP request, response, error, cancellation, EOF, and adapter teardown behavior are defined and tested.
• The supplied capability can be attenuated and delegated through the current Membrane path.
• The integration test requires no external LLM or public service.

Non-goals

• Restoring deleted MCP endpoints or Glia architecture.
• Claiming arbitrary native tools become capability-safe when wrapped.
• Supporting every non-WASI integration shape in the first implementation.