Team, Roles, and Permissions

Last updated: Edit on GitHub

Overview

Aikraft is designed for cross-functional teams: compliance officers own classification decisions, technical leads connect data sources, and executives need read-only assurance. This page describes how members, roles, and permissions map to those responsibilities.

Organisation and workspace

When you sign up, Aikraft creates an organisation — the billing and data boundary for your company. Each organisation has one or more workspaces (on Enterprise) or a single default workspace (Starter and Pro).

All AI systems, documentation, and monitoring configuration belong to a workspace. Users are invited at organisation level and granted access to specific workspaces.

Built-in roles

Roles are fixed at the code level. You cannot create custom roles or change a member’s role after they have joined.

RoleTypical userCore permissions
OwnerFirst registrant or transferred adminFull access: billing, members, API keys, delete workspace
AdminSenior team memberFull access (same as Owner), but cannot be the first registrant
Compliance OfficerLegal, GRC, DPO officeClassify systems, approve documentation, manage FRIA records, export audit packs
Technical LeadML engineer, platform teamIntegrations, monitoring connectors, webhook configuration, read/write on technical fields
AnalystRisk or opsView all systems, comment, run classification drafts — cannot publish final tier or exports
MemberGeneral team memberView systems and documentation, read monitoring data, export documents — no write access
Auditor (read-only)External auditorView assigned systems and documentation; cannot change settings

Key differences

  • Owner vs Admin: Both have full permissions. The Owner is the first registrant (or a transferred one). You cannot invite someone as Owner.
  • Analyst vs Member: Analysts can run classification drafts and write monitoring data; Members are read-only.
  • Auditor: Does not consume a paid seat and can only see assigned systems.

Inviting members

  1. Open Settings → Team in the app sidebar.
  2. Click Invite member and enter a work email address.
  3. Select a role and, on multi-workspace plans, tick the workspaces they should access.
  4. The invitee receives a link valid for 7 days. SSO tenants can enforce domain allowlists in Settings → Security.

Constraints

  • Owner cannot be invited. Ownership is transferred separately in Settings → Team.
  • Roles are fixed. Once a member accepts an invitation, their role cannot be changed. If you need a different role, remove the member and re-invite them.
  • No duplicate invitations. An active pending invitation blocks a new one for the same email.
  • No duplicate members. You cannot invite someone who is already a member of the workspace.

Invitations consume a seat on your plan, except for the Auditor (read-only) permission, which does not use a seat. Removing a user frees the seat within the current billing period.

Classification and publishing rules

By default, only Compliance Officers, Admins, and Owners may:

  • Mark a classification as final (locking the risk tier for audit)
  • Publish generated Annex IV documentation to the official version history
  • Sign off Fundamental Rights Impact Assessment records (where enabled)

Technical Leads may run the classification questionnaire and generate documentation drafts, but the final publish step requires a Compliance Officer unless the Owner disables separation of duties in Settings → Governance (not recommended for regulated environments).

API keys and service accounts

API keys are created under Settings → Developers. Keys are shown once at creation; store them in your secrets manager.

API keys do not have member roles. Instead, their scope maps to a synthetic role for permission checks:

ScopeMaps toEffective permissions
ReadAuditorList systems, fetch classification results, download published documentation
WriteTechnical LeadCreate or update system metadata, push monitoring events from CI
AdminAdminManage webhooks, full API access
  • Read scope: list systems, fetch classification results, download published documentation.
  • Write scope: create or update system metadata, push monitoring events from CI.
  • Admin scope: manage webhooks — Owner, Admin, or Technical Lead only.

Rotate keys if a member with access leaves the organisation.

Auditor access

To grant an external party read-only access, invite them with the Auditor (read-only) permission:

  1. Open Settings → Team and click Invite member.
  2. Enter their work email and select the Auditor (read-only) permission.
  3. Scope the access to one or more specific systems.

Auditors can view only the systems assigned to them — published classification and documentation — and cannot change settings or browse unrelated systems. The Auditor permission does not consume a paid seat. Revoke access at any time by removing the member. See Exports and auditor access for packaging PDFs alongside read-only access.