Who may do what.
Revoked on the very next request.
People, groups, service accounts and agents get built-in roles on an organization, a folder or a project. Every check runs at the latest version of your access rules, so a removed role stops working on the next request. Agents act within a ceiling and can never approve, and every action leaves an audit entry with who did it, and for whom.
One order for every check.
Every decision gets an ID.
Every API call, from the console, the CLI or an MCP client, passes the same steps in the same order. A refusal names the step that refused it and carries a decision ID you can troubleshoot later, even after the rules changed.
Built-in roles.
No role reads a secret value.
Bind a role to a person, a group, a service account or an agent on the organization, a folder, a project or one resource, with an optional condition and an expiry. New members get Developer; an owner can make Admin the default.
| Role | May | May not |
|---|---|---|
Owner roles/owner | Everything in the organization, billing included | Read secret values |
Admin roles/admin | All resources, the sign-in policy and SSO; approve agent plans | Change owners; read secret values |
Developer · default roles/developer | Create, change and delete clusters, data, network and monitoring resources; write secret values; approve agent plans in their projects | Members, roles and billing; delete protected resources |
Responder roles/responder | Read everything in scope; acknowledge and resolve incidents; silences and maintenance windows | Change resources |
Viewer roles/viewer | Read everything in scope | Any change |
IAM admin roles/iam.admin | Members, invitations, groups and roles; given with Owner to whoever creates the organization | Grant a role it does not hold |
Billing admin roles/billing.admin | Invoices, payment methods, spend caps and usage | Resources |
Servers admin roles/servers.admin | Sites, servers, pools, provider accounts and Frazer Link settings | Members, billing |
Audit viewer roles/audit.viewer | Read the audit log, IAM, sessions, tokens and policies | Any change |
Custom organizations/…/roles/… | Your own set of permissions on an organization or a project | – |
Built-in roles never include IAM administration, impersonation, token minting or secret access; those are always granted on their own.
Agents can ask.
Only people decide.
A change an agent plans, a change in production and a change to a protected resource wait as an approval. Approving it applies exactly that plan; if the target changes first, the plan is void.
- People only
- Agents, service accounts, MCP tokens and personal access tokens can ask. They never approve.
- No self-approval
- In production a second person must approve; the person an agent acts for does not count.
- Pinned to the plan
- A vote binds to the exact plan and the target’s version, with a passkey or second factor from the last 10 minutes.
- One rejection ends it
- Pending for 24 hours by default. Once approved, Frazer applies it at once, exactly once, as the requester.
One login.
Step up when it matters.
One account belongs to every organization you work in. Approving, creating a token or deleting a project asks for a passkey or second factor from the last 10 minutes, in the console and in the CLI.
- Email and password
- 15 characters or more, checked against known breaches, with no forced rotation.
- Google and GitHub
- Linked to an existing account only after you sign in to it the usual way.
- Passkeys
- Discoverable credentials with user verification; they count as two factors.
- Authenticator app
- Time-based codes, plus 10 recovery codes; using one replaces the set.
- SSO and SCIM
- Per-organization OIDC or SAML, verified domains, groups mapped to roles, SCIM deprovisioning.
$ frazer login # opens your browser; the CLI's key stays in the OS keychain
$ frazer login --no-browser # over SSH: a code to confirm on another device
$ frazer login --step-up # a passkey or second factor, good for 10 minutes
$ frazer auth print-access-token # a 15-minute token for a script# Approve from the terminal: people only, with a fresh step-up
$ frazer login --step-up
$ frazer approvals list --can-decide
$ frazer approvals approve apr_01JA3KQ7
# The requester's side: follow it until it is applied
$ frazer approvals wait apr_01JA3KQ7// A deny policy on the organization
// denied permissions: *.delete
// condition (CEL), checked on every request:
principal.kind == "agent"
&& resource.matchTag("frazer.ai/env", "production")Access you can explain.
Down to each decision.
One login, many organizations
Belong to Acme and Pellwyn with one account; each sees only its own members.
Groups that expire
Nested up to five deep, with expiring memberships and a reminder 7 days and 1 day before.
Service accounts without keys
Keys are off by default; a CI job, such as one on GitHub Actions, signs in with its own identity.
Agents as principals
A ceiling role, the person’s current rights as a limit, and one switch that suspends every agent.
Explain any denial
Every decision has an ID. Replay it later, even after the rules changed, to see what decided it.
Access diff before you apply
Every IAM change shows who gains or loses which permission, with a replay of the last 90 days.
Just-in-time access
Roles granted for up to 8 hours on approval; unused standing access becomes eligible instead.
Enterprise SSO
OIDC, or SAML through a sidecar; JIT accounts on first sign-in and SCIM as the source of truth.
Guardrails with defaults.
Stated, not implied.
Who may do what
- Owner
- Everything, billing included. Every organization keeps at least one; the last cannot be removed.
- IAM admin
- Invites people and grants roles, but never a role it does not hold itself, group memberships included.
- Admin
- Sets the sign-in policy: required MFA, allowed methods, session length, token lifetimes, the default role.
- Agents
- A ceiling role, Viewer by default, limited by the person they act for. Never approve, never administer IAM.
What is logged
- Every action: the actor, the person an agent acts for, the client, the approval and the result.
- Every denial and every IAM change in full, each with a decision ID.
- Kept 400 days, with a write-once copy in object storage.
- Every vote, decision and apply of an approval, with both identities.
- Sign-ins from a new device, new tokens and changed factors are emailed to you, with a This wasn’t me link.
At the cap
- Step-up: a passkey or second factor from the last 10 minutes to approve, create a token or delete a project.
- Personal access tokens must expire, at the latest after 1 year; service-account keys after 90 days.
- Sign-in: a proof-of-work challenge after 5 failures, a 15-minute lock after 10 that still lets passkeys in.
- Approvals: pending 24 hours by default; the apply must start within 15 minutes of the last vote.
- Kill switch: Suspend all agents stops every agent token on the next request.
No fee for identity.
SSO included, never upsold.
Roles, groups, the audit log, enterprise SSO and SCIM come with every organization. You pay for what runs, never for who signs in.
See every priceIdentity and access, answered.
Can an agent approve its own change?
No. An agent, a service account, an MCP token or a personal access token can ask, never approve. A vote counts only from a person in the console or the CLI, with a passkey or second factor from the last 10 minutes, and in production it must come from someone other than the person the agent acts for.
How fast does removing someone’s access take effect?
On the very next request. Every IAM change bumps your organization’s revision in the same transaction, every check runs at the latest revision, and decisions are never cached.
Can people read secret values?
Not by default. No basic role reads a secret value, owners included. People write a new version with a reason and see its metadata: version, author and time. Workloads read the values. A person reads one only with an explicit Secret Accessor grant: each read needs step-up 2FA and is audited, production can require an approval, and a project policy can forbid all human reads.
Do you support SSO and SCIM?
Yes. An admin verifies your domain with a DNS TXT record and adds an SSO connection: OIDC directly, or SAML through a sidecar that turns it into OIDC. People from that domain then sign in through your identity provider, their account is created on first sign-in and its groups map to roles. When SCIM is connected it is the source of truth: deprovisioning removes the membership and revokes that organization's sessions and tokens.
How does CI sign in without stored keys?
Through workload identity federation. A GitHub Actions job exchanges its own OIDC token for a 15-minute Frazer token, and a condition on its claims, such as the repository and the branch, decides which jobs may. Service-account keys are off by default.
What does a denied request tell me?
Which step refused it, the permission and the resource, and a decision ID. Troubleshoot that ID later, even after the rules changed: you see the outcome replayed at that revision and the outcome now. An IAM viewer also sees the rule that decided and the smallest role that would allow it.