Role-based access control for secrets

Keel decides access in two steps: what your role allows, and which environments you have been given. Both must pass before a value is read.

Roles

Owner and admin can manage members, invitations, environments, and integrations, and can read the audit log. Both have access to every environment.
Member can read, create, update, and delete secrets in environments they have been granted.
Viewer can read secrets in environments they have been granted and cannot change anything.

Environment access

Members and viewers start with no environment access. An admin grants Development to the contractor, Staging to the QA engineer, and Production only to the people who deploy. A grant never raises a role, so a viewer with a Production grant is still read-only. Production is not special-cased: every environment is deny by default for members and viewers.

Enforced on the server

The check runs in the API before any secret is read or decrypted, not in the interface. Environments you cannot access are omitted from project responses, and denied attempts are recorded in the audit log.

Inviting people

Invitations are bound to an email address, and the invitation token travels in the link fragment so it does not appear in server request logs. Pending invitations can be revoked.

Frequently asked questions

Can I restrict someone to a single secret?: Not at the moment. Access is set per role and per environment, not per individual secret.
Do admins see Production by default?: Yes. Owners and admins have implicit access to all environments, because they can grant themselves access anyway.
Is single sign-on supported?: Sign-in is handled by Clerk. Keel itself does not add its own SSO configuration.