AI database approvals: write the receipt before the action
An AI agent prepares a database-backed decision. A reviewer changes the amount and approves it. The external action succeeds—but the approval record is lost between chat, workflow state, and the destination system.
An immutable log cannot prove a record that was never written. The safer order is simple: admit the decision receipt first, then make action success depend on it.
Bind approval to the exact artefact
The receipt should reference a digest of the reviewed proposal, normalized inputs, data-source and freshness evidence, tenant/environment, policy version, reviewer identity, decision type, rationale, and any diff. If the artefact changes, the old approval must no longer authorize it.
Use audit-ready MCP workflows for the broader evidence chain.
Issue a short-lived decision capability
After durable admission, issue a capability that binds the receipt ID, operation ID, approved parameters, target resource, expiry, and maximum uses. The executor verifies it at dispatch time and atomically consumes the operation before committing the external side effect.
Do not store approval as a conversational boolean. The executable boundary needs structured, independently enforceable data.
Keep proposal, decision, and execution separate
A complete trail has at least three linked records: what the agent proposed, what the human decided or changed, and what the executor attempted and observed. A successful approval is not proof of successful execution; a successful external state is not proof of approval.
Return an explicit tool-result contract with completion status, observation state, retry count, and reconciliation reference.
Test the failure matrix
- receipt admitted, action never dispatched;
- action attempted without an admitted receipt;
- duplicate delivery of the same operation;
- crash after consume but before external commit;
- approval replayed against another tenant, amount, or destination;
- artefact modified after review;
- approval expires while queued;
- executor returns an indeterminate timeout.
The impossible state is action success without an admissible receipt. Other states need explicit reconciliation, not a guessed success or automatic blind retry.
Reconcile without duplicating sensitive data
A periodic job can compare admitted receipts, consumed operations, external idempotency keys, and observed destination state. Log identifiers, digests, versions, timestamps, and status transitions; avoid copying raw result sets or private rationale into every observability system.
Concrete example
A finance agent proposes a refund using approved database views. The reviewer changes 500 to 350 and adds a rationale. The receipt binds the proposal digest, diff, customer scope, currency, destination, and expiry. Payment execution consumes the single-use operation ID. A retry sees the existing receipt and destination idempotency key instead of paying twice.
Acceptance criteria
- The reviewed artefact is immutable or content-addressed.
- Every edit is preserved as a distinct decision.
- The receipt is durable before dispatch.
- The execution capability is scoped, short-lived, and single-use.
- Retries reuse one logical operation ID.
- Indeterminate outcomes enter reconciliation.
- An independent reviewer can connect proposal, decision, and observed action.
Where Conexor fits
Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. Durable receipts help teams keep database evidence, human judgment, execution scope, and observed outcomes connected without trusting the chat transcript as the audit system.
Explore audit logging for MCP workflows
For bounded access, see approved views for AI database agents.