An agent can propose a plausible action without having permission to execute it. A useful guardrail checks who may act, what was approved and whether the permission still applies when a tool is called. Model confidence can inform review priority. It cannot authorize a credit, deletion or other consequential operation.
This guide extends the service-sector hyperautomation overview with a runnable, synthetic service-credit workflow. It uses Python's standard library and two local SQLite databases. Fixed proposals stand in for model output; a fake provider stands in for a credit API. It uses no customer data, model credentials or external services. The example establishes local execution behavior, not a production deployment or an LLM quality benchmark.
Separate proposals from authority
The model's output is an untrusted proposal. Parse only the supported fields, reject unsupported actions and validate the tenant, case and account against trusted application records. Do not take a role, policy version, approval flag or idempotency key from model output.
Authorization must be checked at each operation, including receipt lookup. The companion uses an in-process fixture directory to supply principals and permissions. It does not implement login, session verification, identity-provider integration or network authentication. Replacing that directory with a string supplied in an HTTP request would remove the demonstrated protection.
The example's policy requires a human approval for every service credit. That is an explicit teaching policy, not a universal monetary threshold. Another workflow may permit a bounded automated action under an approved deterministic policy. In either case, authority comes from the policy and trusted identity, never the model's score. See OWASP's authorization guidance.
Bind approval to an exact action
The reviewer needs to see the destination account, amount, currency, case and policy version. The workflow stores a fingerprint of those material values and an approval expiration time. Requesting and approving are separate permissions, and the requester cannot approve their own action in this example.
Changing the amount or destination cannot reuse the old approval. The fixture rejects such changes and has no amendment or approval-renewal operation. A production design needs a separate review path for changes, preserving the history of any action already attempted. The executor reloads the stored action, checks its fingerprint and verifies current permissions and approval immediately before a new mutating dispatch. At the expiration instant, approval is already invalid. Revoking a reviewer or executor's authority also prevents a later dispatch.
The point of the approval screen is a specific decision a reviewer can understand and challenge. Showing only a model summary hides the values that will be sent to the tool. OWASP's transaction-authorization guidance describes binding authorization to transaction data and enforcing the steps in order.
Keep workflow and provider state separate
The companion has a workflow database for actions, approvals, dispatch attempts and audit records. A second database represents the provider's credit ledger. They do not share a transaction. Committing an attempt in the workflow cannot atomically commit a credit at the provider.
The workflow allocates its own stable provider idempotency key for each action. The fake provider returns the original receipt for a repeated key with identical material parameters, and rejects a conflicting payload. Separately, a tenant-and-case business rule prevents another caller request from creating a second service-credit action for the same case.
These are different checks. A provider can deduplicate one key while still accepting two different keys for the same business request. A local duplicate check can reject a second action while the first action's external outcome remains unknown.
| Observation | What the workflow may do | What it must not infer |
|---|---|---|
| A transient error occurs before any provider effect | Retry within its bounded policy after rechecking permission and approval | That every transport error happened before a commit |
| The provider commits but its acknowledgement is lost | Keep an uncertain outcome and look up the original key using read authority | That a missing response means no credit was issued |
| The same key and parameters arrive again | Return the existing receipt in the fake provider | That a fresh key would also be deduplicated |
| Approval expires before another dispatch | Deny a new mutating call; permit a separately authorized receipt lookup | That expiration reverses an existing credit |
| Receipt lookup returns nothing | Allow a later retry only with the same-key guarantee, remaining attempt budget, backoff and a fresh approval check | That a real provider has no delayed or in-flight request |
An approval check cannot recall a request already in flight. Production controls must address that interval explicitly, for example by enforcing an expiry or precondition at the receiving service when it supports one. The example's sequential local calls do not establish those guarantees across a network.
Provider contracts differ. Stripe documents its retention and replay rules; AWS explains why caller intent matters when retrying. Neither source guarantees the behavior of a different tool. Confirm retention, lookup consistency and parameter matching before adopting a retry policy. Without a suitable provider contract, an ambiguous outcome may need manual reconciliation instead of another write.
Run the synthetic workflow
Download the service-credit workflow and tests, extract it into a new directory and follow its README. The package requires Python 3.10 or later and uses only its standard library. It creates disposable local databases, makes no network calls and requires no package installation.
The demo walks through the approval and lost-acknowledgement case. The tests exercise failures as well as successful execution. Run both from the extracted package directory.
python3 run_demo.py
python3 -m unittest -v
The lost-acknowledgement demo recovers one synthetic credit of 2,500 USD minor units after reopening at the approval deadline. It reports one dispatch attempt and zero mutating calls after reopening. The suite passed 32 tests on Python 3.13.7 with SQLite 3.50.4 on 17 September 2026. These are fixture results, not transaction volumes or a customer outcome.
The package's test record identifies the actual Python and SQLite versions used. The minimum declared version is a requirement, not a claim that every supported runtime was tested. Inspect the provider ledger as well as the workflow's final status when evaluating a duplicate-call test.
| Control | Failure evidence to inspect |
|---|---|
| Tenant and action authorization | Wrong-tenant, unauthorized and revoked-principal attempts make no new provider effect |
| Approval binding | Changed material parameters or policy invalidate the stored approval |
| Expiration | The exact deadline rejects dispatch, including a retry after time advances |
| Business deduplication | Repeating a case does not allocate a second credit action |
| Provider idempotency | Replaying a key returns one receipt; conflicting arguments fail |
| Recovery | A committed credit with a lost acknowledgement is reconciled without creating another credit |
| Retry limits | Retryable pre-effect failures stop at the configured attempt budget and respect the fake clock |
| Audit records | Denied, approved, dispatched, uncertain and reconciled events remain connected without raw complaint text |
The tests cover a local synthetic process and its documented failure model. They do not prove simultaneous distributed-worker safety, availability, resistance to a compromised database administrator or compatibility with a real payment API. Read the README's scope before adapting the example.
Test model quality separately
An execution-policy test can pass even when a model extracts the wrong amount. The reviewer might also accept that wrong proposal. Test the interpretation step with representative, access-controlled examples and independently checked expected results.
Include ambiguous complaints, contradictory account details, unsupported requests and instructions embedded in customer content. Measure extraction errors and inappropriate recommendations separately from schema validity. Test whether the workflow refuses unauthorized tool calls even when the proposed content looks convincing.
Choose evaluation coverage and release thresholds from the actual risk and observed failure patterns. A fixed number of test cases does not establish safety. Record the model and prompt versions, dataset selection and exclusions, human labeling process and unresolved failures. This companion calls no model and supplies no model-accuracy or prompt-injection benchmark.
Record decisions without copying every input
An audit event should connect the action, policy version, trusted actor reference, approval, attempt, time and outcome. Keep the provider receipt reference needed for reconciliation. Avoid raw customer correspondence, access tokens, credentials and unrestricted model responses in ordinary logs.
The companion records selected structured fields and reason codes. Its SQLite audit records are durable local records, not tamper-evident evidence. Production retention, restricted access, export, monitoring and integrity controls require separate design and verification. OWASP's logging guidance covers information to exclude and the protection of log data.
Keep operational outcomes distinct. A proposal accepted by a reviewer is not an executed credit. A timed-out call is not necessarily a failed credit. A reconciled receipt is evidence of a provider effect, even if the workflow discovered it after approval expired.
Disabling an agent or reverting application code can stop future work. It does not undo a completed credit, external message or deletion. Any compensating action needs its own business rules, authority and audit record.
Choose the implementation scope
For one process, Agentic AI Systems addresses the tools, review experience and execution controls that need to work together. A useful engineering enquiry identifies the source system, permitted actions, approval owner and unresolved failure cases.
When several workflows need shared model routing, budgets and operational visibility, AI Platform & Orchestration addresses that shared platform. Each workflow still owns its action-specific authorization and reconciliation rules. The service-sector article provides background on the kinds of service work that can be examined before implementation begins.