Roles and permissions

Quick overview

Administrators use Settings → Team → Members to invite people and assign one of six system roles. Each role starts with permissions suited to that person's work.

| Role | Primary responsibility | |---|---| | Administrator | Team, billing, security, and platform configuration | | Developer | SDK integration, application setup, and diagnostics | | Governance Engineer | Rules, policy evaluation, and changes in results over time | | Compliance Officer | Evidence, regulatory readiness, and gate approvals | | Business Owner | Portfolio outcomes, cost, and strategic decisions | | Auditor | Read-only evidence review and formal audit statements |

Edit a team member to change their role. After saving, confirm the role in the member list and ask the person to sign in again to check their access.

VeriProof includes six system roles. Assign the role that matches a person’s current responsibilities. Review application restrictions as well as role permissions when deciding what that person should access.

Only an Administrator can invite team members or change system-role assignments. Keep at least one active Administrator account.

Choose the right role

Role	Use this role for	Typical access
Administrator	People responsible for the VeriProof account	Team, applications, keys, integrations, billing, security, compliance, and evidence
Developer	People integrating an AI application	Applications, API keys, SDK health, session traces, and technical diagnostics
Governance Engineer	People designing and monitoring governance controls	Rules, policy exceptions, evaluation data, governance trends, session traces, and redaction policy
Compliance Officer	People preparing evidence and managing regulatory work	Compliance, evidence exports, reports, legal holds, erasure requests, gate approvals, and policy exceptions
Business Owner	People accountable for outcomes and cost	Application summaries, sessions, cost analysis, and business-level reporting
Auditor	People independently reviewing evidence	Read-only applications, sessions, compliance evidence, activity history, and assigned audit work

Your organization can change the display labels for these roles or create a custom role based on a system role. The underlying permissions remain the source of access decisions.

Use Decision Reviewer for scoped sign-off

Decision Reviewer is a maintained custom-role template, not a seventh system role. Use it for subject-matter experts who record assigned business decisions for selected applications.

Create the role once and reuse it for reviewers with the same decision authority. Select applications for each person so one reviewer can cover lending applications while another covers fraud applications.

The template does not grant policy, application, integration, user, export, routing, continuation, or technical recovery access. Sensitive or technical evidence requires a separate explicit permission.

Use Business Owner when the person also needs portfolio outcomes and cost views. Use Compliance Officer for regulatory oversight, controls, evidence, and compliance administration.

Compare important permissions

This table highlights common tasks. The portal’s role settings show the complete permission list for your organization.

Task	Administrator	Developer	Governance Engineer	Compliance Officer	Business Owner	Auditor
Manage team members	Yes	No	No	No	No	No
Manage applications	Yes	Yes	Yes	No	No	No
Manage API keys	Yes	Yes	No	No	No	No
View SDK health	Yes	Yes	Yes	No	No	No
View session traces	Yes	Yes	Yes	Yes	No	Yes
Author policy rules	Yes	No	Yes	No	No	No
Manage policy exceptions	Yes	No	Yes	Yes	No	No
Approve governance gates	Yes	No	No	Yes	No	No
Export evidence	Yes	No	No	Yes	No	Yes
View cost analysis	Yes	No	No	No	Yes	No

These permissions come from the current customer-portal permission matrix. Custom roles can narrow or extend access within the limits configured by your organization.

Change a team member’s role

Open Team

In the customer portal, go to Settings → Team → Members.

Select a team member

Open the team member’s edit action.

Choose the new role

Select a system role or an available custom role. Review the description below the field before you continue.

Confirm the change

Save the edit and confirm the updated role in the member list. Ask the person to sign in again and check that their access matches the assignment.

Review access safely

A role change can be blocked if it leaves pending work without an eligible decision owner. Resolve the ownership requirement shown in the portal before trying again.

Start with the role that grants the least access needed for the person’s work.
Use separate accounts for administration and routine work when your security policy requires it.
Review team access after role changes, departures, and audit milestones.
Remove access promptly when a person no longer needs the account.