Least privilege, all the way down
Every route checks a declared permission before it runs, drawn from 32 scopes. An API key carries a subset of them and an optional expiry — never the keys to your whole workspace.
32 permission scopes, API keys limited to a subset of them, an encrypted secret vault, and rate limits you set yourself.
What you get
- Permission-scoped API keys — Create a key that can trigger a workflow but cannot read a secret or invite a user. Each key carries its own explicit list of permissions and an optional expiry, so a third-party integration is never handed more than the one thing it came for.
- Role-based team access — Invite teammates into a workspace with a role, and every endpoint checks the permission it declared before running. Deploying, revealing a secret, approving a paused run and unlocking retries are all separate rights you can grant independently.
- Encrypted secret vault — Store signing secrets and credentials per workspace and reference them from a workflow by name. Listing a secret and revealing its plaintext are two different permissions, so an engineer can confirm a credential exists without ever being able to read it.
- Rate limits you control — Configure throughput ceilings per workspace and per outbound domain, so one noisy integration cannot exhaust the capacity your production workflows depend on, and a misbehaving partner API cannot pull your whole account down with it.
Platform capabilities
- 32: Permission scopes
- Fail-closed: Behaviour of a route with no permission declared
- 2: Separate rights to list a secret vs. read its value
Can I create an API key that only does one thing?
Yes. A key is created with an explicit list of permissions drawn from the 32 available scopes, plus an optional expiry timestamp. A key scoped only to trigger executions cannot read secrets, change members or deploy a workflow.
What happens if an endpoint ships without a permission declared?
It denies every scoped credential. Access is opt-in by declaration rather than opt-out, so a route that never declared a permission grants nothing to an API key or a role — a forgotten annotation fails closed instead of quietly exposing an endpoint.
Can someone read a secret's value just because a workflow uses it?
No. Listing secrets and revealing plaintext are separate permissions. A workflow resolves a secret at runtime, and a teammate can confirm it exists and is referenced correctly, without anyone holding the right to display its value.