Validate the proposed action outside the model

Define a small operation

Suppose an assistant helps prepare a supplier comparison. Give it an operation such as creating a draft comparison from specified proposal identifiers. Avoid beginning with a general-purpose HTTP client that can send arbitrary payloads to arbitrary destinations.

The operation's input schema should name the fields the workflow needs. Reject unknown fields and excessive lengths or list sizes. Schema validation catches malformed requests, but it does not decide whether the caller may access those proposals. Keep that distinction visible in the implementation.

Use the server's authenticated session to identify the caller and organisation. Do not accept a generated user identifier as proof of identity. Likewise, resolve proposal ownership from trusted records rather than trusting a tenant field supplied in the tool arguments.

Apply policy before touching the target

The executor should check the operation, object access and destination before making an external call or changing state. If approval is required, load the approval record and compare it with the exact proposal to execute.

receive proposed comparison
validate the input shape
load the authenticated caller
verify access to every proposal
resolve the permitted output workspace
check any required approval against this payload
create the draft with an operation identifier
return a bounded result

This sequence is illustrative. Real code must also handle concurrent permission changes, transactional behaviour and downstream errors. For a consequential operation, revalidate the relevant authority as close to execution as the architecture permits.

Keep rejection understandable

Return a structured denial reason that tells the assistant what it can safely explain. For example, the requested destination may be outside the permitted workspace. Do not include credentials, hidden policy details or unrelated record contents in an error response.

The model should not be able to retry a denied operation through a less restricted alternate tool. Review the complete tool set for equivalent capabilities. Restricting one export operation achieves little if a generic attachment uploader provides the same route.

Keep a denial distinct from an uncertain execution result. If the downstream service timed out after accepting work, retry handling must establish what happened. Treating every error as permission to try again can create duplicate side effects.

Test the executor directly

Call the executor with malicious and malformed arguments without involving the model. Use another organisation's record identifier, an unapproved destination and an approval tied to a different payload. Each case should fail at a named policy check.

Then run the full assistant with external text requesting those same actions. This verifies integration while the direct tests establish that the boundary does not depend on the model recognising the attack. Keep both suites because a prompt update and an executor change can break different parts of the system.