Give an agent a task. Keep authority in your systems.

A language model can interpret a request, identify relevant material and produce a candidate action. Its output remains untrusted input to the component that could create a business effect. In this example, the model proposes a supplier-review draft. A separately implemented policy checks the actor, legal entity, action name, input schema, allowed fields and source references before any write is considered.

A typed tool schema reduces ambiguity but does not establish business permission. A perfectly valid request to update a beneficiary would still be impermissible in this workflow. The executor therefore has a narrow tool catalogue and an integration identity limited to the permitted draft operation. The model has no independent route to a payment endpoint, arbitrary network destination or new permission grant.

This design places the decision where it can be inspected and tested independently of prompt wording. Changes to a model or its instructions may alter proposal quality, but they should not expand the integration’s authority. The separation follows the independent downstream enforcement and limited-agency principles discussed by OWASP.

Technical basis: OWASP: excessive agency and downstream action controls ↗

Retrieval-augmented generation supplies selected source material to a model. The security boundary exists before that material enters the prompt. For this reference design, the retrieval service resolves the authenticated requester and entity, applies the intended source permissions, and returns only eligible passages. Filtering unauthorised passages from the final answer would be too late: the model or its surrounding systems may already have processed them.

Each returned passage should retain an identifiable source, version and location. The reviewer needs to distinguish an approved contract clause from a newer unapproved submission. A vector similarity score describes retrieval behaviour; it is not a confidence percentage that a contractual conclusion is true. Source permission changes and deletions need an explicit propagation path through indexes and caches.

Technical basis: OWASP: RAG access control, ingestion and source integrity ↗

In the supplier example, the retrieval result might contain an approved clause and a conflicting incoming document. The proposal should preserve the conflict and point the reviewer to both locations. The system must not silently merge the two into an invented authoritative field. If an entity boundary or current source permission cannot be established, the workflow should stop retrieval for that material and return an explainable exception.

A generic “Approve” flag does not define what a reviewer agreed to. The proposed contract binds the decision to the authenticated requester, acting entity, operation type, exact proposed field changes, relevant resource version, policy revision and expiry. The review screen must show the business meaning of those fields and the evidence used. Replacing a document reference or destination after approval invalidates the decision.

The approver must separately have authority to approve that operation for that entity. Their identity and decision belong in a protected approval record. For workflows requiring separation of duties, the requester and approver cannot satisfy the rule merely by using different display names. The executor checks the relevant identity relationship and current authority immediately before the intended effect.

If JSON is hashed or signed, both sides need the same canonical byte representation. Property order, number handling and serialisation differences can otherwise change a digest without changing the apparent business content. RFC 8785 defines one JSON canonicalisation scheme; a chosen implementation must match the data types and constraints in use. A content hash binds bytes, not permission or authenticity by itself.

Technical basis: RFC 8785: JSON Canonicalization Scheme ↗

The contract also needs freshness. Suppose a reviewer approves a draft against contract version 7 but version 8 changes the relevant term before execution. The system should detect the changed precondition and request a new decision rather than reuse the old approval. Cross-system freshness limits and any permitted execution window must be part of the documented operating policy.

A timeout may occur before a downstream system receives a request, during processing, or after it commits a record but before the reply arrives. These cases cannot be distinguished from the timeout alone. The execution service needs a stable operation identity and a durable record of its state, so that a repeated delivery does not automatically become a new business action.

For the supplier draft, the proposed idempotency key identifies one authorised business operation, scoped to the relevant entity and integration. Repeating the same operation with the same bound payload should retrieve or reconcile its result. Reusing the key with different content must be rejected. An idempotency key must be honoured by the system that creates the effect, or supported by a reconciliation method capable of finding the existing effect; storing a key only in the calling agent is insufficient.

Technical basis: AWS Builders’ Library: retries and idempotent API contracts ↗

A local operation record and a remote write usually do not share one transaction. A crash between them leaves a reconciliation problem. If the downstream service supports neither idempotency nor a reliable lookup, automatic retries cannot promise a single effect. The reference workflow then holds the operation for reconciliation instead of blindly resending it. The owner should understand this integration limitation before granting more consequential tools.

An evaluation set should represent the tasks the owner actually needs: supported and unsupported questions, conflicting documents, revoked source access, cross-entity requests, invalid approvals, tool failures and misleading instructions embedded in retrieved material. Keep development examples separate from the release set, record how cases were selected and version the data, model, prompt, tool and policy configuration tested.

Measure retrieval eligibility and relevance, accuracy of critical fields, support for material statements, appropriateness of abstention, completion of the intended task, reviewer effort and confirmed business outcomes. Report the denominator and failure categories for each metric. A high average answer score can hide one unauthorised disclosure or a repeated write; security acceptance gates must therefore be examined independently of usefulness averages.

For non-deterministic behaviour, repeat sensitive cases and describe the observed variation. Zero observed failures in a finite set does not prove that a failure is impossible. The appropriate sample size and thresholds depend on the task, expected use and consequence. In this reference design, any observed unauthorised action blocks release pending investigation, while quality failures lead to a scoped decision about whether the workflow is useful enough to deploy.

Evaluate languages and document conditions separately. A result on clean English contracts does not establish performance on Greek scans, tables with missing pages or handwritten annotations. A private office may also value lower disclosure risk and clearer exceptions over maximum automation. Those priorities should shape the evaluation contract, not be inferred after a pilot has been scored.

The operation record should link the authenticated actor, source versions, proposed contract, approval decision, policy revision, execution attempts and confirmed or unresolved result. It should allow an operator to answer what was authorised and what actually happened without retaining every document or unrestricted prompt in routine logs. Access, redaction, retention and incident-handling rules apply to these records as well as to the original sources.

Changes to models, prompts, connectors, source permissions and business rules should trigger the relevant regression set. A kill switch for consequential tools can stop new effects while preserving evidence needed to reconcile pending work. Recovery should distinguish reversing an already committed business operation from merely rolling back application code; those actions may have different owners and prerequisites.

The final handover would identify the process owner, approver roles, technical operator and incident contact; document the permitted actions and known integration limitations; and state the conditions for expanding scope. That gives a large organisation or private office a concrete basis for deciding whether the proposed autonomy is appropriate for its systems and responsibilities.