Verify the boundary before release

Start verification with a permission matrix. Put task steps on one axis and source or action scopes on the other. For each allowed cell, state why it is required. An empty reason is a candidate for removal.

Then test with the real workload identity. Include expected work and deliberate boundary probes:

• request a record from another tenant;
• ask for a restricted field on an allowed record;
• include a conflicting tenant ID in tool arguments;
• place tool-like instructions inside an attachment;
• request more results than the configured limit;
• try an unregistered tool name;
• alter a proposal after approval;
• replay a consumed approval;
• change the target record before execution;
• interrupt an external action after sending but before acknowledgement.

Confirm the system denies the call or moves it to the intended review path. Inspect the user-facing explanation and the event record. A technically correct denial that leaks the restricted record's existence or contents still needs repair.

Run the approved path as well. Check that the agent retrieves only the fields required, cites the source objects used, creates a complete proposal, waits for the correct reviewer, executes once and returns destination evidence. Remove any permission that did not participate.

The release record should name the task version, identity, source scopes, tool set, policy version, approval rules, operating limits, tested failures and owner. Use that record to scope the next expansion, then add only the permissions required by the new task.