Separate reading from acting
Retrieving an approved knowledge article, drafting a response, updating a record, and making a customer commitment are different permissions. Give each action an explicit boundary and owner. Require additional approval where an incorrect action is difficult to reverse. Treat external messages and retrieved documents as inputs to evaluate, not instructions that can expand the system’s authority.
Enforce company boundaries below the interface
Hiding a company in a menu is not access control. For a multi-company portal, the database must restrict which records an authenticated member can read or change. Supabase combines table grants with row-level policies; both need to match the intended access. Test denied requests as well as allowed ones. Administrative credentials belong in protected server-side environments, not the browser.
Design the exception path
Define what happens when a source is unavailable, conflicting, incomplete, stale, or outside the system’s authority. Route the request with enough context for a person to finish the work. Make the fallback visible to operators, and avoid claiming completion merely because a model produced an answer. Test the experience with realistic failure cases before expanding usage.
Assign the work after launch
Name the people responsible for source access, operational monitoring, incident response, changes, evaluation, and business acceptance. Record the rollback path and the conditions that trigger it. Review new capabilities as changes to the operating system, not as automatic upgrades to its authority. Document these responsibilities in the project review.
Implementation reference: Supabase row-level security and table grants ↗