Define a network-enforcement acknowledgement adapter for task capability transitions

[dinpd]

Parent: #78
Depends on: task capability-state contract issue under #78

Outcome

Define and demonstrate a vendor-neutral adapter by which an external network enforcement point can apply a task capability-state transition and acknowledge the exact version before AgentPass releases protected data.

Scope

• Adapter request/response contract.
• Binding to tenant, task graph, ceiling digest, transition ID, state version, destinations/protocols removed, audience, expiry, and nonce.
• Authentication and replay expectations.
• Apply, acknowledge, reject, timeout, close, and unsupported outcomes.
• Persistent-connection reauthorization or closure semantics.
• Mock adapter and one Cloudflare-oriented integration example or mapping.
• Evidence and privacy requirements.

Non-goals

• Building a universal proxy, VPN, firewall, or network gateway.
• Inspecting encrypted application payloads inside AgentPass.
• Assuming network controls understand tool arguments or application semantics.

Acceptance criteria

• The contract binds acknowledgements to the exact task and transition version.
• Replayed, stale, expired, wrong-audience, or mismatched acknowledgements are rejected.
• Required-but-unavailable enforcement blocks protected-result release.
• Persistent connections are explicitly closed, reauthorized, or declared unsupported.
• The mock adapter supports success, rejection, timeout, partial application, and stale-version tests.
• Documentation distinguishes harness semantics from network-visible destination/protocol semantics.
• Portable evidence records outcomes without network credentials, packet contents, or protected payloads.

Security considerations

An acknowledgement is authoritative only under configured component identity and audience policy. The model, tool server, or caller cannot self-assert successful network enforcement.