Expose host routing
Construct the five-field request before policy. Reject unsupported fields from the tool input and the prepared request.
A host can pass a recipient check, then expand or rewrite the mail request inside its provider callback. Build the narrow provider request first. Make that request the proposal the host checks and, where required, approves.
Scope: Both paths use the complete To/CC/BCC mail adapter. The earlier path transforms the mail request after its check; the new path transforms before the check. The sender must use exactly the prepared fields. These local cases do not send mail or authenticate a person.
Each case invokes both Node integrations. The machine report holds their plans, receipts, and exact callback requests.
Construct the five-field request before policy. Reject unsupported fields from the tool input and the prepared request.
The exact To/CC/BCC manifest is checked against trusted host policy. Approval, if required, sees the prepared body and proposal digest.
The host sender receives the frozen prepared fields. Its implementation and provider behavior remain separate trust assumptions.
The host owns routing, policy, authenticated approval, and the mail service. The sender callback must submit the prepared request without adding a destination afterward.
import { createPreparedMailToolExecute } from "./pilots/action-boundary/prepared-mail-tool.mjs";
import { mailTargetResource } from "./pilots/action-boundary/mail-target-manifest.mjs";
const intended = mailTargetResource({ to: "team@example.test" });
const policy = { protocol: "aml-action-policy/1", rules: [{
tool: "send_message", effect: "send", resource: intended.resource,
requires_approval: true
}] };
const execute = createPreparedMailToolExecute({
purpose: "Send release", policy,
prepare: (toolArgs, context) => hostBuildProviderRequest(toolArgs, context),
requestApproval: hostAuthenticatedApproval,
consumeApproval: hostAtomicOneUseClaim,
execute: preparedRequest => hostMailer.send(preparedRequest)
});