Permissions

The authorization rules of the platform, generated from mapi_spec.tenancy and mapi_spec.tokens by scripts/gen_docs_platform.py. Every component (the API, the web app through OpenAPI, the tests) checks the same table. The Administration guide explains how to use it.

Roles

Roles are ordered viewer < editor < runner < admin; each includes the one before it. tenant-wide means only a tenant-wide membership grants it; otherwise the effective role in the project counts (the higher of the tenant-wide and the project grant). A pair that is not listed is denied to everyone.

Resource	Action	viewer	editor	runner	admin	Operator
tenant	read	✓ tenant-wide	✓ tenant-wide	✓ tenant-wide	✓ tenant-wide	✓
	update				✓ tenant-wide
	create					✓
	delete					✓
	manage (tier, status, residency, identity verification)					✓
tenant_member	read	✓ tenant-wide	✓ tenant-wide	✓ tenant-wide	✓ tenant-wide	✓
	create				✓ tenant-wide
	update				✓ tenant-wide
	delete				✓ tenant-wide
project	read	✓	✓	✓	✓	✓
	create				✓ tenant-wide
	update				✓
	delete				✓ tenant-wide
member	read	✓	✓	✓	✓	✓
	create				✓
	update				✓
	delete				✓
token	read	✓	✓	✓	✓	✓
	create	✓	✓	✓	✓
	delete (own tokens; manage covers everyone's)	✓	✓	✓	✓
	manage (list and revoke other members' tokens)				✓
catalog	read	✓	✓	✓	✓	✓
dataset	read	✓	✓	✓	✓
	create		✓	✓	✓
	update		✓	✓	✓
	delete				✓
spec	read	✓	✓	✓	✓
	create		✓	✓	✓
	update		✓	✓	✓
	delete				✓
run	read	✓	✓	✓	✓	✓
	create			✓	✓
	cancel			✓	✓
	update			✓	✓
model	read	✓	✓	✓	✓
	run (score)			✓	✓
	delete				✓
	validate (submit, resubmit or cancel a governance validation)			✓	✓
	approve (needs the reviewer capability; never the submitter, never a token)		✓ with reviewer	✓ with reviewer	✓
	update (deprecate a validated version)				✓
endpoint	read	✓	✓	✓	✓
	run (score)			✓	✓
	create				✓
	update				✓
	promote				✓
	delete				✓
	manage (override a promotion gate; sessions only)				✓
plot	read	✓	✓	✓	✓
	create		✓	✓	✓
	run (render)			✓	✓
	delete (saved plots)		✓	✓	✓
embed	read	✓	✓	✓	✓
	create		✓	✓	✓
	delete		✓	✓	✓
webhook	read				✓
	create				✓
	update (includes rotating the secret and replaying deliveries)				✓
	delete				✓
plugin	read	✓	✓	✓	✓
	create				✓
	delete				✓
usage	read	✓	✓	✓	✓	✓
billing	read				✓ tenant-wide	✓
audit	read				✓ tenant-wide	✓
quota	read					✓
	update					✓
	delete					✓
kill_switch	read					✓
	update					✓
executor	read					✓
	update					✓
event	create	—	—	—	—	internal services only
tenant_deletion	read				✓ tenant-wide	✓
	create				✓ tenant-wide
	cancel (within the grace period)				✓ tenant-wide
	manage (purge, retry)					✓
tenant_export	read				✓ tenant-wide
	create				✓ tenant-wide
workflow	read	✓	✓	✓	✓
	create		✓	✓	✓
	update		✓	✓	✓
	delete				✓
	run			✓	✓
	cancel			✓	✓
policy	read	✓	✓	✓	✓
	create				✓
	update				✓
	delete				✓
tenant_policy	read	✓ tenant-wide	✓ tenant-wide	✓ tenant-wide	✓ tenant-wide
	create				✓ tenant-wide
	update				✓ tenant-wide
	delete				✓ tenant-wide

Operators

Platform operators (verified e-mails in MAPI_OPERATOR_EMAILS, signed in; never through an API token) hold exactly these permissions, on every tenant: audit read, billing read, catalog read, executor read, executor update, kill_switch read, kill_switch update, member read, project read, quota delete, quota read, quota update, run read, tenant_deletion manage, tenant_deletion read, tenant_member read, tenant create, tenant delete, tenant manage, tenant read, token read, usage read. None of them reads tenant content: datasets, specs, models or plots.

Capabilities

A capability is granted on top of a role, per project membership; project admins hold every capability implicitly. A rule that needs one says so in the roles table ("✓ with reviewer").

Capability	Needed for	What it allows
reviewer	model approve	Approve or reject model validations that wait for a second person (POST /v1/validations/{id}/approvals), never the member's own submissions (SELF_APPROVAL_FORBIDDEN) and never through an API token. Granted per project membership (capabilities on the membership, or the Reviewer column of Members); viewers cannot hold it.

Token scopes

A token acts as its owner, narrowed by its scopes: both the owner's role and a scope must allow an action. admin covers everything the owner's role allows; score:<alias> covers one endpoint (score:* every endpoint of the project).

Resource	Action	models:read	runs:create	score:*	plugins:publish	datasets:write	endpoints:promote	webhooks:manage	workflows:write	workflows:run	models:validate	policies:manage	runs:write
project	read	✓	✓										✓
catalog	read	✓	✓						✓				✓
dataset	read	✓	✓			✓				✓			✓
	create					✓
	update					✓
spec	read	✓	✓										✓
run	read	✓	✓							✓	✓		✓
	create		✓							✓	✓
	cancel		✓							✓
	update												✓
model	read	✓	✓				✓				✓		✓
	run		✓	✓						✓
	validate										✓
endpoint	read	✓	✓	✓			✓						✓
	run		✓	✓
	create						✓
	update						✓
	promote						✓
	delete						✓
plot	read	✓	✓										✓
	run		✓
webhook	read							✓
	create							✓
	update							✓
	delete							✓
plugin	read				✓
	create				✓
	delete				✓
usage	read	✓	✓										✓
workflow	read	✓	✓						✓	✓			✓
	create								✓
	update								✓	✓
	run									✓
	cancel									✓
policy	read	✓	✓								✓	✓	✓
	create											✓
	update											✓
	delete											✓

Trust tiers

Tier	Executor must provide	vCPU-s / day	vCPU-s / month	Concurrent runs	Fan-out tasks	Largest class	Storage	Egress / month	Requests / min
internal	isolation ≥ process	—	—	100	1,000	—	—	—	6,000
self-hosted-trusted	isolation ≥ process	—	—	—	—	—	—	—	—
verified	isolation ≥ gvisor, egress and DNS enforced	86,400	1,000,000	20	256	L	100 GiB	100 GiB	600
public	isolation ≥ gvisor, egress and DNS enforced	3,600	36,000	2	16	S	2 GiB	5 GiB	60

Platform-wide (global) defaults: concurrent_runs = 700. A dash means no limit at that level.