For IT teams
Access granted knowingly. Evidenced automatically.
You're the team that gets asked for access in a DM and audited on it eighteen months later. Requester puts the owner's sign-off, the business justification, and the intended end date on the record — then triggers the provisioning itself.
Free plan, no card required. Submitters are always free.
What IT gets
- Isolation
- Row-level security on every workspace table
- Tokens
- Hashed at rest, single-use, expiring, revocable
- Provisioning
- action:webhook as a workflow step, awaited
- Evidence
- Actor, timestamp, IP, user agent per decision
- Exit
- Full workspace export as one JSON file
Granting takes two minutes. Proving it took two minutes takes two weeks.
The asymmetry between how easy access is to grant and how hard it is to evidence is the entire reason access reviews are painful.
Requests arriving in DMs
- No justification captured, so nobody can judge whether the access is still needed.
- Whoever had admin rights granted it — not necessarily the system owner.
- Access level defaults to whatever was fastest, which is usually too much.
- At review time you're reconstructing intent from a chat export.
Requests as routed records
- Business justification and intended end date required at the point of asking.
- The system owner approves via a reviewer group that survives people leaving.
- Sensitive systems branch to security automatically, based on a field answer.
- Every grant has an actor, a timestamp, and a reason attached to it.
Four things you stop doing by hand
Deciding who should approve
Reviewer groups per system mean the right owner is asked automatically, and a leaver doesn't break every request at once.
Provisioning after the fact
The webhook step fires on approval and the workflow waits on it, so the record and reality stay in sync.
Assembling evidence for reviews
Filter by system, save the view, export it. The grant history is a query rather than a project.
Explaining the access level
A dropdown instead of a text box means least privilege is the default path, not the disciplined one.
Beyond access, the rest of the IT front door
Access requests
Tool, licence, and permission requests with owner sign-off and a provable grant history.
Learn moreHardware & equipment
Laptop and equipment requests routed by cost, with finance joining above the threshold.
Learn moreExternal & contractor intake
A public link so contractors can request access without you provisioning an account first.
Learn moreThe parts you’ll be asked about in a security review
Row-level security
Enforced by the database on every workspace table, not by application-layer filtering.
Learn moreTokenized surfaces
Hashed storage, single-use consumption, expiry, revocation, and rate limiting on public endpoints.
Learn moreStructured logging
Sensitive values redacted in logs by default rather than as an afterthought.
Learn moreAPI & webhooks
Per-workspace API keys, lifecycle event webhooks, and outbound webhook workflow steps.
Learn moreNobody struggles to list who has access. They struggle to say why — and that answer only exists if you captured it at the moment of asking.
What IT teams ask
- Is this a helpdesk or a ticketing system?
- Neither, precisely. It's the approval and request layer — the part before a ticket, where someone asks for something and a person with authority says yes. If you already run a helpdesk, use the event webhook to open tickets from approved requests rather than replacing it.
- How is workspace data isolated?
- Row-level security on every table holding workspace data. Queries run as the signed-in member and cannot return another workspace's rows — the isolation is enforced by the database, not by application code that could be bypassed.
- How do the public links work without being a hole?
- Tokens are stored hashed, consumed single-use where the flow requires it, and support expiry and revocation. Public endpoints are rate limited, and invalid, revoked, and expired tokens all render identically — a public page never confirms that something exists.
- Can approval trigger the actual provisioning?
- Yes, via the webhook workflow node. The approved request calls your provisioning endpoint as a step and waits on it, so the record reflects what was actually created rather than only what was authorised.
- What happens to our data if we leave?
- You export it. The full workspace export is one JSON file with teams, templates, fields, requests, answers, comments, history, decision narratives, members, and guest approvers. There's no retention hold and no support ticket required.
Start the grant history you’ll want at your next review.
One access request form, one owner approval step, and every grant from here on carries a reason and a name. Free to start.