In this note
An accounts-payable reviewer approves a proposed invoice correction. Before the tool applies it, someone removes the caller's permission. The approval is still in the record. The caller can still send the request. The service must refuse the change.
I'd put that check in the service receiving the write. A prompt telling the agent to respect permissions leaves the enforcement in the wrong place. Another caller, a retry, or a direct tool invocation can reach the same service without following the agent's earlier conversation.
Separate the proposal from the change
Keep four things separate: what the automation proposes, who approved that proposal and for how long, whether the receiving service permits it now, and what the source system says happened. An agent's summary cannot supply a missing approval or prove that a record changed.
In this hypothetical invoice case, the proposed action releases a duplicate-invoice hold. The approval stores the proposal's digest, a fingerprint of its contents. Change the proposal afterward and the fingerprints no longer match. The service must reject the changed request; a general 'looks good' cannot authorize whatever the automation sends later.
Matching fingerprints only show that the contents match. The software must also verify who approved it, whether they have the required role, whether approval is still valid, and whether policy requires a different person from the requester. A made-up approval ID or copied screenshot cannot pass those checks on its own.
Have the receiving service look up the stored proposal and approval. It must not trust a caller saying they exist. The approval needs to identify the target, change, and any amount or limit. Approval for one correction does not automatically cover a second correction to the same invoice.
Read the failed cases before trusting the happy path
| Case | Observed behavior and limit |
|---|---|
| Approved, authorized request | One hold release is saved and checked in the local implementation. |
| Direct tool call without approval | The service that applies the correction refuses the request; no hold is released. |
| Approval belongs to a different proposal | The workflow asks for review before calling the receiving service; no request reaches it and no hold is released. |
| Caller loses permission after an earlier check | One request reaches the receiving service. Its fresh permission check refuses it; no hold is released. |
| Approval has expired | The workflow refuses before calling the receiving service; no request reaches it and no hold is released. |
These are reported results from local teaching tests, not a live finance system. The download records the cases; it does not supply the software. The expired-approval and mismatched-proposal cases stop in the workflow before it calls the receiving service. Those tests cannot show whether the service would refuse a direct call that bypasses the workflow. The missing-approval test calls the service directly, and the revoked-permission case reaches it after an earlier check succeeded. Both test the service's own enforcement.
Check the saved records as well as the error message. A service could return an error after already making the change. For each denied test, verify that no forbidden change was saved. Here we inspect local test state. In a real integration, use permitted checks in the actual source system. A log saying denied is little comfort if the ledger changed.
Recheck current authority at the receiving service
The receiving service needs to know who started the work, which person or service is calling now, which customer's record is involved, and what action is requested. The action must fit all applicable permissions. A powerful tool account cannot lend its extra permissions to the agent. A caller cannot switch customers by editing an argument. Get identity and access facts from trusted service context, not the model's description.
Check the invoice version too. Someone may have resolved the hold after approval. In that case, refuse the old proposal or send it for investigation. A read followed by an unconditional write still leaves a race: the record can change between them. The receiving system must enforce the expected version as part of the write itself.
Check that this exact tool build is approved for use with the current release, and give its owner a way to disable it. A familiar name, installed skill, or working connection does not grant permission to change records. If required permissions or record state cannot be confirmed, leave the proposal pending with a responsible person and an approved manual alternative.
Tell the responsible person what prevented the change. Expired approval calls for another review; revoked access calls for an access decision; a changed invoice calls for a fresh check. Asking the model to retry won't fix those conditions. Retain the rejected request with access limited to people allowed to investigate it.
Plan duplicate protection and readback before enabling writes
Assign the intended correction an operation ID before sending it. Reuse that ID when a request is delivered twice or retried after a timeout. The service must prevent the actual change from happening twice, including when requests arrive together. Putting an ID in a request header is not enough unless the receiving system enforces it.
Decide what saved result would prove success. Here, an authorized reader must find the correct invoice and operation, the resolved status, and the expected number of resolutions. A receipt with the right fields doesn't prove those facts. Read them from the source system using current permitted access.
If you cannot check the saved result, completion is unknown. Don't report success or repeat a change that may already have happened. This teaching service refuses the write upfront if the caller lacks permission for the required verification. Another design could use a separately authorized verification service, but it still needs a reliable check and someone to investigate unknown results.
Choose one write and try to bypass its checks
Choose one proposed action and fill in the worksheet: the record, allowed change, exact approval, current-state check, operation ID, and source-system confirmation. In an approved test environment, try missing approval, changed content, revoked access, an old record version, duplicate requests, and unavailable confirmation. Keep the failed attempts alongside the successful one.
Keep real writes disabled until the system owner accepts the results and unresolved cases have a safe response. The local cases do not test your identity system, transactions, concurrent requests, retention rules, or approval policy. Start by naming the service responsible for each check and the saved result that would show a forbidden change slipped through.