Python: binding external approval to final tool arguments across resume

[prototipoff (krivonosoff161)]

I am working on an external exact-action approval adapter and want to pin down its supported integration boundary in Python Agent Framework.

The answer in #6848 identifies declaration-only tools with the request_info/responses handshake, and FunctionMiddleware for in-process interception. #7871 separately discusses session-backed approval rebinding. My question is narrower than those two: which boundary owns the final executable arguments when validation, hidden-argument materialization or runtime kwargs can occur around approval and resume?

The contract I need is:

1. The trusted host prepares the exact document bytes and destination to be reviewed.
2. A separate operator approves that retained action.
3. Execution uses that same retained action, or refuses if the executable action has changed. Resume must not silently authorize newly materialized values.

For a local create-only file action, I already have this host-side boundary in Action Authority 0.3.0, using the Harness writer. There is no Agent Framework/FIDES adapter yet.

Is the recommended route to keep final materialization and execution entirely host-owned behind a declaration-only tool, or is there a supported FunctionMiddleware ordering contract that binds approval to the final arguments across resume? In the FIDES case, that must preserve its policy preflight rather than expand hidden values before authorization.

I am looking for the existing contract or sample to target, not proposing a parallel approval API. This is an integration question, not a vulnerability report; the local-file component does not provide IFC or containment of a compromised host.

— krivonosoff161

[Rodion Kazennov (nefayran)]

I traced this on main (67ba500) and ran the cases below against a fake chat client. Short version: with a session, core binds a tool approval to the arguments the approval request showed, and only to those. Pydantic coercion, runtime kwargs, [var_…] resolution and the tool body sit outside that binding. So for "execute the retained action or refuse", the boundary that owns the final executable arguments is the host, which is your option (a).

What core binds (default settings, with a session)

• When the approval request is raised, it is stored in session state. On resume, the call id, name and arguments come from that stored request, not from the response payload (_tools.py#L3178, spec 004, L480-481). A response that carries other arguments is not refused: they are replaced by the stored ones.
• After parsing and validation, a token of the approved arguments is taken. Inside invoke, the approval-visible arguments are compared with it (_ensure_approved_arguments_unchanged). If a FunctionMiddleware changed them, nothing executes and a replacement approval request comes back for the same occurrence (spec, L487-493). The check sits inside invoke, so there is no middleware ordering to get right.
• Without a session, local approval responses are dropped and nothing runs. With disable_approval_response_binding=True (my run had no session), the response's own call runs, changed arguments included.

What that binding does not cover

• Pydantic coercion and validators. The token is taken after validation: a request shown as '{"amount": "10", "to": " ALICE "}' ran as {10, "alice"} with no second approval.
• Runtime kwargs (ctx.kwargs). A middleware that changed them after approval ran without a re-ask.
• metadata["original_arguments_for_messages"]. Whatever a middleware puts there is what gets compared. LabelTrackingFunctionMiddleware sets it and then expands [var_…] placeholders (security.py#L1900-L1915), so the value a placeholder resolves to is not bound to a plain tool approval. In my run, the stored variable changed between approval and resume, and the tool got the new value.
• The exception on the FIDES side is the approvals that PolicyEnforcementFunctionMiddleware raises itself. Their binding includes the resolved signature, the labels and the session (matches_binding). With an untrusted variable, the policy asked again instead of running.
• The tool itself. A different tool registered under the same name between approval and resume runs the recorded call.

Declaration-only tools (func=None)

• They come back to the host as a function call with user_input_request=True and the raw model arguments. No validation and no FunctionMiddleware run: 0 middleware calls in my run.
• With always_require, the approval round comes first and the stored call then goes to the host.
• The framework never holds executable arguments, so "the same retained action, or refuse" is entirely yours to enforce. The sample to target is agents_with_declaration_only_tools.py.

There is no public API that compares the approved arguments with the final ones; the comparison key is private. If you need it in process, a middleware placed innermost can compare context.metadata["approval_response"] with context.arguments and context.kwargs, and return a new approval request to force a re-ask.

The cases I ran (tool transfer(amount, to), approval shown as {10, alice} unless noted):

case	what ran
session, response carries {9999, mallory}	{10, alice}
no session	nothing
no session, disable_approval_response_binding=True	{9999, mallory}
middleware sets to=mallory	nothing; replacement request shows mallory
same, plus original_arguments_for_messages set	mallory, no re-ask
middleware changes ctx.kwargs	new kwargs, no re-ask
[var_…] approved, stored value changed before resume	the changed value
same with policy middleware, untrusted variable	nothing; new approval request

[prototipoff (krivonosoff161)]

Thanks for tracing the final-argument boundary. I took the declaration-only route and kept the implementation outside the SDK: krivonosoff161/agentic-action-authority#17

The proposal is deliberately limited to one create-only document action. The host captures the final UTF-8 bytes and workflow/request/executor/call identity, presents the retained action for a detached operator signature, and verifies the same binding before execution. A changed occurrence refuses without spending approval. A lost workflow response is handled by readback of the existing effect, not by invoking the writer again.

The accompanying offline example uses the actual Agent/Workflow/function-invocation layer and FileCheckpointStorage. It discards the original workflow after the write, creates a new instance, and resumes from the checkpoint with the recovered function result. The scripted client and signer are explicit test fixtures, not a model-safety test or independent human approval.

The optional adapter targets agent-framework-core 1.23.0. The exact-head CI linked from the PR passed the 14 adapter tests, 112 existing integration tests and 33 overlapping base-only tests on each of Windows and Linux, without skips. It does not modify SDK internals or claim that declaration-only tools inherit FunctionMiddleware/FIDES enforcement. Host-owned key enrollment, stable occurrence-to-task routing and workflow storage remain application responsibilities.

Would a narrowly scoped upstream recipe for final-materialization and lost-response handling be useful, without adding Action Authority as an SDK dependency? If so, I would first open or reuse an issue to agree the sample scope before preparing an upstream PR. Keeping this as an external integration is also a valid outcome.

AI assistance disclosure: the implementation, tests, documentation and this proposal were materially AI-assisted with Codex. Automated results and assistant review are identified separately from human review; I am not claiming Microsoft acceptance.

krivonosoff161