Roles & permissions

The Komodor Agentic Operation Platform (KAOP) authorizes members, service accounts, and agents with the same default-deny model. Capabilities describe actions, policies group capability grants, roles group policies, and assignments give roles to identities. Manage the model under Settings → Roles, Policies, and Access explorer.

​

Built-in and custom roles

KAOP provides built-in roles for common responsibilities: Built-in roles and their built-in policies are read-only: you can assign them, but cannot edit or delete them. Built-in role names appear with a builtin: prefix. Create custom policies and roles when the defaults do not match your responsibility boundaries.

​

How access is composed

• A capability is one governed action, such as invoking an agent, reading a run, or managing a trigger.
• A policy is a named, reusable set of capability grants and their scopes.
• A role links policies and is assigned to identities.
• A direct grant can give a subject a role or capability over a resource scope without changing a reusable role.

Access is additive. An identity receives the union of its matching grants; a request with no matching grant is denied. Adding a policy never subtracts access granted elsewhere. The console uses the same capabilities to hide or lock unavailable actions, while the API enforces authorization independently of the interface.

​

Scope a grant to resources

A capability says what the identity may do. Its resource scope says where it may do it.

​

Account-wide scope

An account-wide grant covers every resource of the applicable type in the account. Use it only when the role genuinely requires broad reach.

​

Exact resource or pattern

Select one resource ID, or use * in a pattern that must match the whole ID: Characters other than * match literally.

​

Labels

Label selectors scope by metadata rather than naming. For example, team = payments covers labeled resources for that team. A selector can also use a principal attribute: team = $principal.team matches resources whose team label equals the acting identity’s team attribute. Agents, credentials, channels, knowledge bases, MCP servers, and workflows can carry labels directly. Related resources can inherit labels from their parent agent. Member and service-account attributes are managed from their identity settings.

​

Expiration

A grant can include an expiration time. Use expiring grants for temporary access so the permission ends without a later cleanup step.

​

Verify before changing access

Use Access explorer to inspect an identity’s effective capabilities and their provenance. Use Access check to test one capability against a specific resource, including its pattern and label matching, before adding or removing a grant.

​

Next steps