Post-Release Control Verification

Controls tested before launch only prove the agent was safe on that day. Every release, deployment, permission change, or org update can silently widen what topics trigger, what actions run, and what records the agent may write.

Action filters and write permissions are configuration, and configuration drifts. A new flow, an updated profile, or a deployed action can bypass rules the agent was originally mandated to follow, with no error message to warn you. The only reliable defense is to re-verify controls after every change, not only before launch.

Treat every change as a control event

• The mandate defines allowed actions and write scope; verification compares live configuration against it, not against memory.
• Org changes outside the agent project, such as profile, permission set, or sharing updates, also change effective agent authority.
• Silent expansion is the default failure mode: nothing breaks, but the agent can suddenly do more than approved.
• Verification after change is cheaper than incident response after an unauthorized write.
• Verification results belong in the release record so the team can prove control status at any point in time.

Re-verify controls after every change

1. Add a post-release step to the deployment checklist that re-tests action filters, variables, and write permissions against the documented mandate.
2. Run the standard test suite, including blocked-action and out-of-scope write cases, after each deployment before marking the release complete.
3. Review permission sets, profiles, and connected flows touched by the release for unintended changes to agent access.
4. Log each verification with date, release version, tester, and result so audits can trace control status over time.