How do I bind an approver and scope to an agent tool call, its result, and a timestamp?

What should I check, step by step?

1. Identify the human approver from your identity provider (subject, email, or employee id your IdP already asserts). Do not accept a free-text "approved by" string the agent typed.

2. Freeze the granted scope on the same row: grant_id or approval_id, allowed actions/targets, policy_version, and expiry. Re-read it at execute time; do not copy it from the agent's paraphrase.
3. Canonicalize the tool call: server/tool name, tool_call_id, and SHA-256 of sorted JSON arguments (redact secrets before hashing). Hash the same way at approve time and at seal time.
4. After the tool returns, compute a result digest (SHA-256 of canonical success payload or of {isError, error_class}). Never seal "success" without a digest, and never let the model supply the digest.
5. Stamp wall-clock time from your server or NTP-synced gateway (ISO-8601 with offset). Reject agent-supplied ran_at unless you treat it as advisory only and keep your own observed_at.
6. Write one append-only record outside the session that joins: approver_id, scope/grant fields, tool+args hash, result digest, observed_at. Refuse to mark the action "approved" if any field is null.
7. Call request_human_approval with summary plus action { tool, arguments_sha256, scope_grant_id, policy_version }; verify_human_approval again immediately before dispatch; then seal the post-result record.
8. Fail closed on missing approver, missing scope, args drift, missing result digest, or clock skew beyond your policy. Log the denial the same way you would log a success.

Why the five fields have to travel together

MCP tools guidance: clients SHOULD show tool inputs before calling the server, prompt for confirmation on sensitive operations, and log tool usage for audit. Showing and logging still leave a gap if the yes is stored without the result digest and a trusted timestamp — an auditor cannot tell which output the human authorized, or when.

• OpenAI Agents SDK human-in-the-loop keeps approval state on the server for browser UIs and warns that RunState.fromString does not authenticate the snapshot: authenticate the reviewer, authorize against pending calls, and consume the decision atomically. Your sealed record should similarly bind identity + pending call, not a client-uploaded confirmed=true flag.
• OWASP Logging Cheat Sheet: each security event needs when, where, who, and what. For agent tool calls, "what" must include both the invocation (tool + args hash) and the outcome (result digest); "who" must be the IdP principal who approved, not the model.
• How to record MCP tool calls at the gateway with scope-grant binding covers capturing every call under the live grant. How to build an agent audit trail tied to grant, spend cap, and revocation covers the authority snapshot across many actions. This page is the single-invocation seal: approver + scope + call + result + time in one row.

Approve the call, then seal the result

request_human_approval before dispatch with the tool name and arguments_sha256 (and grant/scope ids) in the action object. Show the human the real arguments, not the model's summary.

• After tools/call returns, hash the result on the gateway or runner. Write the five-field record in the same durable transaction that marks the approval consumed (or that advances your audit cursor).
• record_ai_run can store a signed receipt of the run summary (model, prompt/output hashes, params that name tool_call_id, args_sha256, result_sha256, approver_id, grant_id, observed_at). verify_ai_run is free. The receipt proves what you recorded, not that the side effect was safe.
• precall_check before unfamiliar MCP servers reduces rug-pull risk; it does not replace binding the human yes to this call's args and result.

What can go wrong?

Approval lives in chat ("looks good") with no args hash, so the agent changes targets after the yes.

• You store tool name + timestamp but omit the result digest, so a later rewrite of the tool output still looks "approved".
• Approver is a display name the agent invented; IdP subject was never checked.
• Gateway grant-binding logs the call under a scope, but no human principal is on the row — useful for capture, incomplete for "who approved this exact outcome".
• Agent supplies ran_at from its session clock; after an incident the times no longer match your SIEM.