Distinct from Section 2: this is about the rules a specific organization layers on top of (sometimes more strictly than) whatever data-sensitivity or regulatory baseline applies — approved-tool lists, access controls, Skill permissioning, review and approval requirements.
Governance has to be enforced somewhere, not just stated. This connects directly back to Module 5's configuration model: Project instructions, knowledge sources, and connector or Skill permissions are exactly the surfaces where organizational governance standards actually get implemented. A governance policy that never gets encoded into real configuration isn't being followed — it's a document nobody checks against.
Narrow access is the safer default, not the paranoid one. The module's opening example — a Skill "with too much access" — is a permissioning decision, and permissioning decisions are governance decisions. Defaulting to the broadest access "just in case it's needed" inverts the right default; the safer choice is the narrowest access that still lets the task get done.