Give your team exactly what they need. Nothing more.
Members are invited, never self-registered. Each one gets a second factor, a set of permissions per area, rights per environment, and — if you want them — rules for when and from where they may sign in. Your vendor can build, test and deploy to UAT every day without ever gaining the ability to push to Live, seal a server, or extract a byte of source.
Three tiers. Zero shortcuts.
Permissions are evaluated on every request across three independent tiers — global platform operations, per-project capabilities, and per-environment rights. Least privilege is the default: a member sees exactly what they were granted, down to individual actions such as pushing to production or exporting source.
Per area
Projects — listing, creating, editing and deleting, pushing and promoting builds. Environments — creating them, registering servers, resetting. Users — adding members, changing permissions, removing accounts. Settings — account configuration and licensing. Full admin — everything, including Enclave.
Per environment
No push between Development, UAT and Live without explicit rights. A vendor who deploys to UAT all day is not thereby able to deploy to Live.
Gated twice
Permissions gate the interface and the API independently. A member without a right does not see the button — and the server rejects the call anyway, so hiding a button is never the only thing standing between someone and an action.
Full admin for the irreversible
Sealing and unsealing a server, and terminating the account, require full admin. Those are the two operations that cannot be undone from anywhere else.
Disable, or remove
A disabled member cannot sign in and their open sessions are rejected mid-flight rather than surviving until expiry; their history stays in the activity log. Removing a member frees the seat.
No user enumeration
Invitation-only onboarding. Login responses never reveal whether a username exists, and failed attempts trigger progressive per-IP lockout.
Decide when, and from where, each member may sign in
Per-member restrictions go beyond the password: working-hours windows with a timezone, allowed days of the week, IP allow-listing by address or CIDR range, and automatic session timeout. They are evaluated at sign-in and are independent of what the member may do once inside — useful for a contractor who should only reach the account during an engagement, or an account that should only be used from an office network.
- Tokens are bound to the address they were issued to; stolen, they fail from anywhere else.
- Tokens rotate on every new login; single-session enforcement is a switch.
- Changing a password signs out every other session immediately.
Two-factor for everyone
A second factor is required on every account, at every privilege level, and there is no way to opt a member out of it. Which one is their choice, and they can register more than one.
Email codes
A six-digit code to the inbox. Always available with no setup — the floor, and the fallback if another factor fails.
Authenticator app
Google Authenticator, Authy, 1Password and similar. Works offline and moves between machines.
Touch ID
The fingerprint on this Mac. Nothing to carry or type — except for a seal or an unseal, which need a code the server can verify.
USB security key
A USB drive turned into a WebAuthn hardware key. It must stay plugged in; pulling it locks the app immediately.
A fresh challenge for the privileged
Administrative and Enclave operations ask again. A stolen session token cannot toggle server state.
Every sign-in on the record
Sign-ins, failed sign-ins and account changes land in the activity log with the actor, the time and the originating address.
ActivityDevelop with external teams without exposing the codebase
Tell us who needs to do what — your engineers, a vendor, an outsourced operations team — and we will show you the permission set that gives each exactly that.