Add a session-scoped secure shadow-execution attestation API for Berd control clients

[tmx8wxtt8t-dot]

Before filing

• I searched open and closed issues for duplicates.
• I checked the current release (v0.6.2) and a later source checkout; the published berdctl contract has protocol version 4 but no session-cancel operation or session-bound policy attestation.
• This is one request: a bounded control contract for secure, non-executing shadow sessions.

Closest existing issue

#114 (ACP capability forwarding) and #244 (session-scoped project inheritance) are related session/control work, but neither provides immutable per-session execution policy, lifecycle settlement, or control-client provenance.

Is this new, or an improvement?

New capability — Berd cannot expose this complete contract today.

The problem, in your terms

An external governance client needs to run a bounded, non-executing shadow turn through Berd and independently verify that the particular session had an immutable deny-all/no-effect policy. Current app-control discovery identifies the app, and the renderer can create/run sessions, but a caller cannot bind a policy to one session, receive the effective policy as attested runtime data, or obtain cancellation settlement and returned-response provenance. Prompt instructions, UI claims, manually denying a request, and global tool settings cannot establish that security boundary.

What you do today

The client stops before dispatch. It can read health/context information but cannot safely invoke or cancel a shadow session under an independently verifiable session policy.

What you'd like to see

Provide additive, renderer-registered control operations (names illustrative):

1. shadow_session_prepare: create or bind one new session to an immutable DENY_ALL / NO_EFFECT policy and return session, harness, provider, runtime, and Berd protocol identities; the effective policy and canonical policy hash; and the resolved timeout.
2. shadow_session_invoke: accept only the prepared session, return a run ID, correlation ID, observable bounded outcome, and response provenance.
3. shadow_session_cancel: return an acknowledgement and a terminal settlement of NO_EFFECT_CONFIRMED or RESPONSE_PROVENANCE_RECORDED.

All operations must fail closed if policy enforcement, attestation, timeout, or lifecycle evidence is unavailable. The policy must be scoped to one session and must not mutate global tool permissions or affect unrelated sessions.

Why this belongs in Berd itself

A skill, extension, reverse proxy, or project-owned wrapper can reject work before dispatch, but cannot prove or constrain the effective policy after a request enters Berd's renderer-selected ACP session. Berd owns the supported control API, session lifecycle, discovery boundary, command registration, and the managed-harness launch point. This needs a first-class, session-scoped surface rather than an out-of-band workaround.

Non-goals

• No changes to global permissions or ordinary interactive sessions.
• No bypass of Berd discovery, authentication, or session security.
• No modification of integrity-pinned managed ACP packages in place.
• No general remote execution API, provider-specific business policy, or UI approval workflow.
• No claim that a prompt restriction alone is enforcement.

Alternatives you considered

• Prompt-only or UI/manual denial: not machine-enforced or attestable.
• Existing tool-permission writer: not bound to a session and can affect unrelated work.
• Custom provider/reverse proxy: cannot prove provider policy or reliably settle cancellation after the managed session boundary.
• Project-side bridge: can fail closed pre-dispatch but cannot attest the downstream runtime contract.

Mockups, prior art, or other context

Acceptance criteria:

• Two simultaneous prepared sessions cannot read or alter each other's policy or lifecycle state.
• Any missing or altered policy attestation blocks invocation.
• A resolved, bounded timeout and outcome are returned for every invocation.
• Cancellation returns an acknowledgement and terminal no-effect or response settlement.
• Runtime/protocol/session/run/correlation/response provenance is returned.
• Existing sessions and global permissions remain unchanged.

[tmx8wxtt8t-dot]

Update from our integration work:

This issue is no longer blocking our project, but the underlying Berd capability gap remains valid.

We resolved our immediate runtime requirement by moving the governed M2 shadow-execution path to a separate Direct Responses runtime, where we were able to enforce and attest the required session-scoped no-tool/no-effect policy, provenance, timeout, cancellation settlement, and fail-closed behavior.

We therefore removed Berd from our project's critical runtime path for now.

However, we have not found evidence that Berd itself currently exposes the session-scoped policy and runtime-attestation contract described in this issue, so we are not considering the Berd-side issue fixed.

We would still be interested in the capability if it becomes available in Berd in the future, at which point we could re-evaluate Berd as an optional runtime integration.