Identity and access

Access to Verdictan has two parts. Sign-in proves who a person or application is. Roles and IAM policies decide what they may do. Signing in through your identity provider does not give anyone permissions by itself: a member can be allowed to read request history and still not be allowed to change a gateway configuration.

Members and TeamsInvite teammates, group them into teams, and remove access.Roles and IAM PoliciesAllow a job function, such as request review, with a role.SSO and SCIMSign in with your company identity provider and sync members from your directory.MFA and PasskeysAdd an authenticator app or a passkey to an account.OAuth ClientsLet an application act with a user's permission.Permissions ReferenceFind the action name that a role must allow.

Select your task

Task	Page
Invite a teammate or organize a group	Members and Teams
Allow a job function, such as request review	Roles and IAM Policies
Use your company's sign-in system	Single sign-on (SSO)
Create and suspend members from a company directory	SCIM provisioning
Add an authenticator or passkey to an account	MFA and Passkeys
Let an application act with a user's permission	OAuth Clients
Let an automated process manage Verdictan resources	API token management

How permissions work

An IAM policy lists allowed or denied actions. A role holds the policies for one job. You assign a role to a team or directly to a member.

For example, an evidence-reviewer role can hold a policy that allows events:read. Members of a team with that role can read events in the allowed scope.

Verdictan denies every action that no policy allows, and a matching deny wins over an allow. Access can come from more than one team or direct assignment, so removing one role does not always remove the access.

In the API, anything that requests access, whether a person, a token, or an application, is a principal. IAM policies control access to Verdictan resources. Gateway policies are a separate system that controls model requests.

Use the right credential

Who connects	Credential
A person in the Console	Their sign-in session, with your SSO or MFA requirements
A person in the CLI	Their verdictan auth login profile
A process that manages resources	An API token with the permissions it needs
A gateway	Its gateway runtime token
An application that sends model requests	An application token, also called a client API token
An application that acts for a user	An OAuth access token with approved scopes

Never share a person's account with automation, and never put a gateway token in an application. See API token management.

Set up access for a team

1. List the jobs that need access, such as request review and configuration management.
2. Create a role for each job.
3. Assign the roles to teams.
4. Invite members and add them to their teams.
5. With an account that is not an owner, do one allowed action and one action that no policy allows.
6. Set up MFA.
7. If your organization uses SSO or SCIM, set them up. Test sign-in and recovery first, as the SSO guide describes.

Review access

After you change a role or remove a member, check both direct and team roles. Look for invitations, tokens, and application registrations that nobody uses. Keep Owner for the owners of the organization.

Trail shows administrative changes. With SSO or SCIM, also check the group mappings, because the next directory sync can change access again.

Next steps

Start with Members and Teams, or look up an action in the Permissions Reference.