Skip to content
Hexel StudioDocs

Actions reference

Every action you can allow in a policy for identity and access, the API calls that check it, and the product actions in managed policies.

On this page

An action is named <service>:<resource>:<verb>. Put action names, or patterns, in the Action field of a policy statement. See Policies for the document language.

Wildcards

PatternMatches
*Every action
org:*, iam:*, workspace:*Every action of that service
iam:policy:*Every action on that resource
An exact nameThat action only

Only a trailing * is a wildcard, and names are case-sensitive. iam:*:read does not match iam:policy:read.

Calls marked "any member" in the tables below check no action: any member or service user of the organization can make them with a valid token.

Organization (org:)

ActionAllowsChecked by
org:org:readRead the organization, its members and the exportGET /v1/organizations, GET /v1/organizations/<org-id>, GET .../members, GET .../members/enriched, GET .../members/check, GET .../export, GET .../provisioning
org:org:updateChange the organization's detailsPATCH /v1/organizations/<org-id>, POST .../provisioning/retry
org:org:deleteDelete or restore the organizationDELETE /v1/organizations/<org-id>, POST .../restore
org:member:inviteAdd members, and create, list, revoke and resend invitationsPOST .../members, POST and GET .../invitations, POST .../invitations/<invitation-id>/revoke, POST .../invitations/<invitation-id>/resend
org:member:manageRemove members and change their member roleDELETE .../members/<member-id>, PATCH .../members/<member-id>
org:settings:readRead organization settingsGET .../settings
org:settings:writeChange organization settingsPATCH .../settings
org:audit:readRead the organization's audit logGET .../audit-logs

The person who created the organization can read and retry its provisioning status without org:org:read or org:org:update. Creating an organization, listing your own organizations (GET /v1/organizations/by-user) and accepting an invitation check no action. Member roles also limit who can add or change which members; see Members.

Workspaces (workspace:)

ActionAllowsChecked by
workspace:workspace:createCreate workspacesPOST /v1/workspaces. Checked at organization level only: a grant placed on a workspace does not count.
workspace:workspace:readList and read workspacesGET /v1/workspaces, GET /v1/workspaces/default, GET /v1/workspaces/<workspace-id>
workspace:workspace:updateChange a workspacePATCH /v1/workspaces/<workspace-id>
workspace:workspace:deleteDelete a workspaceDELETE /v1/workspaces/<workspace-id>
workspace:member:manageList, add and remove workspace membersGET, POST /v1/workspaces/<workspace-id>/members, DELETE .../members/<member-id>

Calls on one workspace are checked in that workspace, so grants placed on the workspace count.

Environments (env:)

ActionAllowsChecked by
env:env:createCreate environmentsPOST /v1/environments, checked in the target workspace
env:env:readList and read environmentsGET /v1/environments, GET /v1/environments/default, GET /v1/environments/<environment-id>
env:env:updateChange an environmentPATCH /v1/environments/<environment-id>
env:env:deleteDelete an environmentDELETE /v1/environments/<environment-id>

Calls on one environment are checked in that environment and its workspace.

Service users (directory:service_account:)

ActionAllowsChecked by
directory:service_account:createCreate service usersPOST /v1/service-users
directory:service_account:readList and read service users, their API keys, OAuth clients and attached policiesGET /v1/service-users, GET /v1/service-users/<service-user-id>, GET .../api-keys, GET .../oauth-clients, GET .../policies
directory:service_account:updateChange a service user, including disabling itPATCH /v1/service-users/<service-user-id>
directory:service_account:deleteDelete a service userDELETE /v1/service-users/<service-user-id>
directory:service_account:manage_keysCreate and revoke API keys; create, rotate and revoke OAuth clientsPOST .../api-keys, DELETE .../api-keys/<key-id>, POST .../oauth-clients, POST .../oauth-clients/<client-id>/rotate, DELETE .../oauth-clients/<client-id>

Attaching policies to a service user through its own route needs iam:policy:attach (below), not a directory: action.

IAM (iam:)

Policies

ActionAllowsChecked by
iam:policy:writeCreate, change and delete policies; create versions; attach and detach any policy to any principal; read role templatesPOST /v1/policies, PATCH and DELETE /v1/policies/<policy-id>, POST .../versions, POST .../attachments, DELETE .../attachments/<attachment-id>, GET /v1/role-templates, GET /v1/role-templates/<name>
iam:policy:readList a policy's versions and attachmentsGET /v1/policies/<policy-id>/versions, GET /v1/policies/<policy-id>/attachments
iam:policy:attachAttach and detach policies through a service user's own routePOST /v1/service-users/<service-user-id>/policies, DELETE /v1/service-users/<service-user-id>/policies/<attachment-id>
Any memberList and read policiesGET /v1/policies, GET /v1/policies/<policy-id>

iam:policy:attach is not needed for POST /v1/policies/<policy-id>/attachments, and iam:policy:write is not enough for the service user route. Attaching also requires that you hold the policy's actions; see Nobody grants what they don't hold.

Groups

ActionAllowsChecked by
iam:group:writeCreate, change and delete groupsPOST /v1/groups, PATCH and DELETE /v1/groups/<group-id>
iam:group:manage_membersAdd and remove group membersPOST /v1/groups/<group-id>/members, DELETE .../members/<user-id>
Any memberList and read groups, members and membership historyGET /v1/groups, GET /v1/groups/<group-id>, GET .../members, GET .../audit-logs

Roles

ActionAllowsChecked by
iam:role:writeCreate, change and delete roles; revoke all sessions of a rolePOST /v1/roles, PATCH, PUT and DELETE /v1/roles/<role-id>, POST .../revoke-sessions
iam:role:write_trustSet a role's trust policyPUT /v1/roles/<role-id>/trust-policy, and POST /v1/roles when the body has a trust_policy
iam:role:readRead a role's policies and trust policy; simulate its trust policyGET /v1/roles/<role-id>/policies, GET .../trust-policy, POST .../trust-policy/simulate
Any memberList and read rolesGET /v1/roles, GET /v1/roles/<role-id>

Attaching a policy to a role is done with iam:policy:write. A policy attached to a role grants only to sessions of that role. See Roles.

Permission sets

ActionAllowsChecked by
iam:permission_set:readList and read permission sets and their assignmentsGET /v1/permission-sets, GET /v1/permission-sets/<permission-set-id>, GET .../assignments
iam:permission_set:writeCreate, change and delete permission sets; assign and unassign themPOST /v1/permission-sets, PATCH and DELETE /v1/permission-sets/<permission-set-id>, POST .../assignments, DELETE .../assignments/<assignment-id>

Testing access and the action catalog

ActionAllowsChecked by
iam:authz:simulateTest access and validate policy documentsPOST /v1/authz/evaluate, POST /v1/authz/explain, POST /v1/authz/simulate, GET /v1/authz/expand, POST /v1/authz/validate-policy
iam:permission:readRead one entry of the action catalogGET /v1/permissions/<permission-id>
Any memberList the action catalogGET /v1/permissions

The action catalog is descriptive. Access is decided only by the action names in your policies, and the catalog does not list every action on this page.

Audit logs

ActionAllowsChecked by
iam:audit:readRead audit log entries and retention policiesGET /v1/audit/logs, GET /v1/audit/logs/<log-id>, GET /v1/audit/retention

See Audit logs.

Preview features

These actions guard Preview APIs. The calls work, but most of what they configure does not change access decisions yet. See each page.

ActionGuardsPage
iam:scp:read, iam:scp:write/v1/scpsGuardrails
iam:rcp:read, iam:rcp:write/v1/rcpsGuardrails
iam:boundary:read, iam:boundary:write/v1/boundariesGuardrails
iam:policy:write/v1/resource-policies (all calls, including reads)Fine-grained access
iam:abac:readRead ABAC policiesFine-grained access
iam:abac:writeWrite ABAC policies, and read, set and delete ABAC attributesFine-grained access
iam:relation:readRead namespaces, tags and session policiesFine-grained access, Session policies
iam:relation:writeWrite namespaces, tags and session policies; write, read, check and look up relationship tuplesFine-grained access, Session policies
iam:workload_identity_provider:read, iam:workload_identity_provider:write/v1/workload-identity-providersWorkload identity
iam:jit:read, iam:jit:write, iam:jit:approve/v1/jitJust-in-time access
iam:approval:read, iam:approval:write, iam:approval:manage/v1/approvalsJust-in-time access
iam:review:read, iam:review:write, iam:review:manage/v1/reviewsAccess reviews
iam:audit:writeCreate audit reports and scans, resolve findings, manage retention policiesSIEM export
iam:audit:siemRead and write SIEM configurationsSIEM export

Trust policy actions (sts:)

sts:role:assume and the sts:role:assume_with_* actions go in a role's trust policy, not in a policy you attach. They say who may assume the role. See Roles.

Product actions in managed policies

The managed policies also grant actions of other Hexel Studio products. Each product checks its own actions; see the product's documentation for which call needs which action.

ServiceActionsManaged policies
Atlasatlas:connector:read, atlas:connector:write, atlas:connector:admin, atlas:channel:read, atlas:channel:write, atlas:tool:read, atlas:tool:write, atlas:knowledge:read, atlas:knowledge:write, atlas:memory:read, atlas:memory:write, atlas:graph:read, atlas:placement:read, atlas:placement:writepol_data_full (atlas:*), pol_data_readonly (the :read actions)
Hexel Managed Memorystorage:memory:store:create, storage:memory:store:read, storage:memory:store:update, storage:memory:store:delete (stores); storage:memory:memory:read, storage:memory:memory:write, storage:memory:memory:delete (memories); storage:memory:job:read; storage:memory:export:createpol_memory_full (storage:memory:*), pol_memory_user (read stores; read, write and delete memories; read jobs), pol_memory_readonly (read stores, memories and jobs)
Skills Registrystorage:skills:skill:read (resolve, fetch, list, search), storage:skills:skill:publish (publish versions), storage:skills:tag:write (move and delete tags), storage:skills:version:yank (deprecate, yank, restore versions), storage:skills:registry:admin (namespaces, publisher keys, audit, webhooks)pol_skills_full (storage:skills:*), pol_skills_publisher, pol_skills_readonly
Supportsupport:ticket:create (open tickets), support:ticket:read and support:ticket:reply (tickets you requested or are copied on), support:ticket:read-org (every ticket of the organization)pol_support_customer, pol_support_org_admin
Billingorg:billing:read, org:billing:managepol_billing_full, pol_billing_readonly, pol_org_member, pol_org_readonly
Other productscompute:*, tool-gateway:*, deployment:*, monitoring:*pol_compute_full, pol_compute_readonly, pol_tool_full, pol_tool_execute, pol_deploy_full, pol_deploy_readonly, pol_monitoring

Atlas actions were renamed from data-platform: to atlas:. Policy documents carry both names for now, so a policy that allows data-platform:knowledge:read also allows atlas:knowledge:read. Write new policies with atlas: names.

Hexel Managed Memory and Skills Registry actions moved under storage:: memory:<resource>:<verb> is now storage:memory:<resource>:<verb>, and skills:<resource>:<verb> is now storage:skills:<resource>:<verb>. storage:* allows both products. Policy documents carry both names for now, so a policy that allows memory:store:read also allows storage:memory:store:read. Write new policies with storage: names.

Actions that no call checks

Some managed policies also list actions that no Hexel Studio API checks today, for example iam:group:read, iam:tag:manage, iam:binding:read, iam:trust:read, iam:role_template:read, directory:user:read and directory:session:read. Allowing them has no effect. The routes for your own account, such as GET /v1/users/me, check no action and work only on your own account.