Set once, inherit everywhere

◐ in progress

Set identity rules at the level that makes sense and let them follow the connection hierarchy.

Identity rules use the same hierarchy as the rest of connection policy. Set one on a client, a project, or an environment, and every connection filed beneath it picks the rule up.

How the effective policy is worked out

A connection's policy is its own settings folded together with the settings of the client, project, and environment it belongs to. The fold has one rule, and it is deliberately blunt:

A group can only ever tighten. If any level asks for a gate, the gate applies. No client, project, or environment can switch a protection off for a connection that asked for it - the permissive settings are connection-only by design.

It means the answer never depends on the order the levels are read in, and a policy you set on “Acme Corp” cannot be quietly undone three levels down. The trade is that turning a gate off is a local edit: you remove it where it was set, rather than overriding it lower down.

The dimensions are independent

Client, project, and environment are not a single chain - a connection carries all three at once, and any of them can contribute a rule. That is what makes “everything for this customer” and “every production database, whoever owns it” both expressible without duplicating rules:

client   Acme Corp     verify to connect
env      Production    verify to write
--
connection  acme-prod-01  → both gates apply
connection  acme-dev-01   → connect gate only
connection  other-prod    → write gate only

The connection-management dialog shows the resolved answer for each connection, so you can see what a rule turned into rather than deducing it.

In progress: this resolution is live today for the SQL guardrails - read-only, rollback wrap, confirmation, AI review, and the production flag all fold exactly this way. The identity flags are stored and edited per entity and join the fold as the native prompts land.