Every setting in goca is a row in one table, and "current" means the row with the highest version. The table refuses UPDATE and DELETE — but not INSERT. So anyone with SQL access could add a row with a higher version and have it silently become the live setting, skipping validation, the audit log, the role check and multi-person approval alike.
Sealing closes that. Each document gets a signature computed from a key derived from GOCA_MASTER_SECRET — a key that never enters the database. Reads check it; a hand-typed row has no valid signature and is refused rather than obeyed. Changing a setting then requires the master secret, not merely database access.
Know three things before arming it. There is no way to switch it off — deliberately. A document that fails its signature refuses to load, and that is the safe direction: a tampered access binding fails the login rather than falling back to "no binding", which would mean unrestricted. And check the status afterwards: armed-with-unsigned-documents is the one state that should never occur — either arming was interrupted (re-arm), or something is inserting rows around the API, which is exactly what sealing exists to catch.
Now I can make "SQL access" stop meaning "configuration access".