--- title: "Identity and access: roles, sign-in, approvals and audit · Frazer" description: "One login across organizations with passkeys and two-factor sign-in, built-in roles for people, groups, service accounts and agents, approvals only people can give, and an audit entry for every action." url: https://frazer.ai/iam index: https://frazer.ai/llms.txt tokens: 2904 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Identity and access: roles, sign-in, approvals and audit · Frazer **Identity and access** frazer.ai # 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. [Create an organization](https://frazer.ai/start?product=iam) [Read the docs](https://frazer.ai/docs) *The IAM page of the project acme-production in the demo organization Acme. Eight principals have a role: two groups, three people, an agent acting for Kenji S. with a Developer ceiling, a service account for releases and the cluster's own identity. Below, the access settings, with approvals in production turned on, and the project's audit log of the last seven days.* The IAM page of a project: every principal, its role and source, and the audit log product UI, demo organization 01 · How it works Fig. 1 ## 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. **Fig. 1** The order in which Frazer decides a request 02 · Roles ## 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. Built-in roles: what each one may do and may not do | 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. 03 · Approvals Fig. 2 ## 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. *An approval in the demo organization Acme: Claude Code, acting for Kenji S., asks to delete the staging database acme-reports-old. It waits because destructive tools always wait for a person. The plan lists five steps, from a final backup to keeping the volume for 7 days, and the buttons Deny and Approve and apply ask for a fresh passkey or second factor.* **Fig. 2** An approval waiting for a person product UI, demo organization 04 · Sign-in ## 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") ``` 05 · What you get ## 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. 06 · Controls ## 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. 07 · Pricing ## 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 price](https://frazer.ai/pricing#lines) Every organization **Included**: SSO (OIDC, SAML), SCIM, MFA, roles and audit logs Fee **$0**: no SSO or SCIM tier to unlock Approvals, just-in-time access **Included** Questions ## Identity 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. ## More in Operate and secure - [**Frazer Monitoring** Metrics, logs, traces](https://frazer.ai/monitoring) - [**Security Center** Posture, threats, evidence](https://frazer.ai/security) - [**Billing and budgets** Caps that pause](https://frazer.ai/billing) ## Give every person and agent a role. Take it back on the next request. [Create an organization](https://frazer.ai/start?product=iam) [Read the docs](https://frazer.ai/docs)