Roles and IAM policies

An IAM policy lists the actions that a person or application may do in Verdictan. A role bundles policies for one job, and you give access by assigning the role to a team or a member. This page walks through creating a narrow role, for example one that lets reviewers read request events but not change gateway configurations.

IAM policies control access to Verdictan resources. Gateway policies check model requests. They are different things.

Before you start

You need policies:read, policies:write, roles:read, roles:write, and roles:assign. Test the result with an account that is not an owner, because an owner's extra permissions hide mistakes.

Take action names from the Permissions Reference, not from button labels.

1. Define the permission

A statement has an effect, actions, and resources, and optional conditions that limit when it applies. This one allows only events:read on one resource:

iam-policies.yaml

name: evidence-read
statements:
  - effect: allow
    actions:
      - events:read
    resources:
      - vdt:verdictan:events:eu:org_example:events

The resource is an example. Replace it with the resource pattern of your organization and region before you assign the policy.

Verdictan denies every action that no statement allows, and a matching deny wins over an allow.

2. Simulate the policy

Sign in with verdictan auth login. A simulation calls the API but assigns nothing.

The allowed action:

verdictan policy evaluate \
  --file iam-policies.yaml \
  --action events:read \
  --resource-vrn 'vdt:verdictan:events:eu:org_example:events' \
  --json

An action that the file does not allow:

verdictan policy evaluate \
  --file iam-policies.yaml \
  --action events:export \
  --resource-vrn 'vdt:verdictan:events:eu:org_example:events' \
  --json

The first decision allows the read, and the second denies the export. Also try a resource outside the scope.

A simulation evaluates only the statements you give it. It does not know who has the role or whether their attributes match, so test real access after you assign it.

3. Create and assign the role

1. Open IAM → Policies and select New policy.
2. Enter the name, actions, resources, and any conditions, and save.
3. Open IAM → Roles and select New role.
4. Enter the role name, attach the policy, and save.
5. Assign the role to your test team or member.

The role shows the attached policy and the assignment. A policy that is not in an assigned role gives no access.

Create access policy is something else: it stores constraints for model requests, such as model or agent scope, and does not create an IAM policy.

CLI alternative

Create the policy and the role:

verdictan iam policy create \
  --name evidence-read \
  --action events:read \
  --resource 'vdt:verdictan:events:eu:org_example:events'

verdictan role create --name evidence-reviewer

Then use the returned IDs to attach the policy and assign the role:

verdictan role attach-policy --role-id <role-id> --policy-id <policy-id>
verdictan team assign-role --team-id <team-id> --role-id <role-id>

Role assignments to API tokens apply to the whole organization. Member and team assignments can be scoped to the organization or a team.

4. Do an access test

Sign in as the test member. Do the allowed read, then try an action the policy does not allow. Find both results and the administrative changes in Trail.

Look at the role from the CLI:

verdictan role show-actions --role-id <role-id>
verdictan role show-assignments --role-id <role-id> --json

Review the statements, the whole role, and every assignment. Another team or a direct role can grant access that this policy does not.

Conditions and wildcards

Pattern	Meaning
events:read	One action
events:*	Every action in the events namespace
*	Every action, or every resource in resources

Resource patterns start with vdt:verdictan:, or are *. Use the narrowest pattern that works. A deny in a shared policy applies to everyone who has it.

Conditions can test identity, request, or resource attributes. Operators include StringEquals, StringLike, StringNotEquals, Bool, Null, numeric comparisons, ForAnyValue:StringEquals, mfa_required, and tag and resource-name conditions.

To simulate a condition, pass JSON attributes with --caller-attrs, --resource-attrs, or --request-attrs. Simulate once with a matching value and once with the value missing.

Remove access

Review every assignment before you remove a role or detach a policy, because another assignment can grant the same action. To detach a policy:

verdictan role detach-policy \
  --role-id <role-id> \
  --policy-id <policy-id> \
  --yes

This changes access for everyone with the role. Confirm the denial with a test account and in Trail.

Troubleshooting

Problem	What to check
The simulation allows, but the user is denied	The assigned role, the resource scope, the attributes, and other deny statements
A test user can do too much	Direct roles and other teams, and that the account is not an owner
A change denies requests you did not expect	The exact action and resource. Do not add * to make the error go away.
A policy cannot be deleted	Whether a role still has it
SSO users get unexpected permissions	Group mappings, fallback roles, and direct assignments

Next steps

• Permissions Reference: exact action names.
• Members and Teams: manage assignments.
• IAM commands: the full CLI reference.