Netlify access control (picking the protection layer)

This skill ROUTES. Its job is choosing the correct protection layer for loading a site, not implementing app auth. Before recommending anything, disambiguate — three unrelated layers get called "auth":

• Netlify Identity — "who is this user inside my app" (issues nf_jwt). App login, OAuth providers for your users, auth code. → Route to the netlify-identity skill. Not covered here.
• Password Protection / Project visibility — "can this request load the site at all." Platform perimeter. This skill.
• Team/Org SAML SSO — "can you log into the Netlify dashboard." Team member access to Netlify itself.

Sessions are separate. The same provider (e.g. Google) can be an Identity OAuth provider for app users AND a SAML IdP for team members — unrelated wiring.

Footgun: no API, CLI, or MCP for these settings

These settings have no public API, no CLI command, and no MCP tool. Do NOT curl api.netlify.com or read local auth tokens to inspect or change them. Hand the user the dashboard path and checklist. On failure, report what you tried and stop.

Footgun: the double login is real

A Password-Protection / team-login perimeter session and a Netlify Identity app session have no bridge — no shared cookie, no header forwarding, no JWT exchange. Don't burn iterations trying to wire them together. For the combined Password-Protection + Identity pattern and its tradeoffs, see references/two-layer-pattern.md.

For company-wide app-level SSO with a single sign-in (no double login), recommend the Auth0 extension (federating to the corporate IdP) BEFORE the two-layer stack.