🔒 Enforce portable no-tool workflow Agent sessions

[taras]

Story

As a workflow host, I want every supported ACP adapter to prove that a workflow Agent session exposes no native tools, terminal, filesystem client, MCP server, or direct network capability, so the XMD-mediated observation model becomes an enforced provider guarantee rather than cooperative behavior plus denied permission requests.

Context

The first supervised workflow intentionally does not wait for this guarantee. Its Agent:

• receives no Workspace materialization or ACP additionalDirectories;
• starts with an empty disposable cwd and no configured MCP servers;
• requests allowedTools: [] where the adapter supports it;
• runs under deny-all permission policy;
• asks for Workspace observations as constrained generated XMD; and
• fails explicitly when it attempts a native tool.

That is sufficient to exercise the product workflow without claiming portable adapter-level no-tool enforcement. This issue owns the later hardening step.

Contract

The workflow host requests one closed no-tool session mode from the Agent provider. Before the first Prompt, the provider proves that the selected adapter can enforce all of the following:

• no agent-native or client-provided tools are available;
• terminal and filesystem client capabilities are not advertised;
• no MCP servers are attached;
• no Workspace or host path is exposed as cwd or an additional directory;
• the same ceiling survives retained-session load, resume, and reconnect; and
• unsupported adapters fail before Prompt execution.

A permission policy that denies a tool after the model selects it is not proof that the tool was unavailable. A system prompt asking the model not to use tools is not enforcement.

The capability is adapter-neutral at the XMD provider boundary. An ACPX implementation may require a new embedded-runtime capability report or session option, but this issue does not authorize an upstream ACPX issue, pull request, dependency pin, or release by itself.

Acceptance

• The provider API can request a no-tool workflow session without exposing ACPX-specific types to core.
• Every shipped adapter either proves the complete ceiling before Prompt or refuses the session.
• Empty allowed-tool configuration is distinguished from an unspecified configuration.
• Terminal, filesystem, MCP, cwd, environment, and reconnect behavior are covered.
• A mutation proving that a tool was merely denied after selection fails the suite.
• Existing caller-selected Agent permissions under ordinary xmd run remain unchanged.
• Architecture and ACP/workflow specifications distinguish the initial cooperative MVP from this enforced guarantee.

Sequencing

This is a hardening follow-up. It does not block #302, #369, #301, #299, or delivery of PR #181 under the accepted MVP contract.

Out of scope

• Giving the Agent direct read-only Workspace access.
• ACP additionalDirectories.
• Replacing constrained generated-XMD admission.
• Authorizing upstream ACPX work without a separate decision.