Manage Access Policies

Use roles to get started and to stay coarse: provision the first user, and hand out the Admin role where per-resource precision isn’t the point. Redpanda turns those role bindings into permits for you, so they take part in the same evaluation and you never author them by hand.

Among the built-in roles, only Admin carries Agentic Data Plane permissions, so role-based access control (RBAC) gives you one coarse grant and nothing in between. Writer and Reader reach the control plane, Kafka, pipelines, and knowledge bases, but no agent, MCP server, or LLM provider. Policies are how you grant everyone who shouldn’t be an Admin. See Control Who Can Do What.

From there, authorization defers to policy evaluation. Every decision that needs a condition, a specific resource, or a denial belongs in a policy, and a forbid overrides whatever a role granted.

Each verb also exists as an action group, so action in Action::"get" matches every <Entity>.get action.

Use action groups in forbid, where one clause can cover every type that adopts a verb. In a permit the required type pin narrows the group back down to the actions of that one type, so naming the actions is equivalent and clearer.

To grant a verb across every type, name each <Entity>.<verb> action explicitly. The Access page does this for you when you pick verbs with the All resources scope.

The Templates tab includes built-in quick-start templates, each a superset of the one before it:

A template fixes the action set, not the reach. Applies to defaults to All resources, and you narrow it from there: to every resource of one type, or to a single resource. The same Read only template can therefore back an org-wide viewer grant and a one-agent grant, with no second template to maintain.

The built-in templates all permit. A template you author yourself can forbid instead, and a policy that links it denies.

One policy ships with the feature and applies to everyone: users can get, update, and delete the agents, MCP servers, LLM providers, guardrails, and budgets they created, plus create and manage triggers on their own agents.

It deliberately stops short in a few places. Creating a resource at the top level isn’t covered, because a create authorizes against a payload that records no creator yet, so ownership can’t grant it. Agent credentials and sessions aren’t covered either, because neither records a creator at all.

Reading a tag a resource doesn’t have is an evaluation error, not false. Always pair getTag with a hasTag check on the same key. This policy denies reads of ITAR-tagged agents, and exempts US persons:

Without the hasTag guard, the policy errors on every untagged resource, and an erroring forbid denies. You would block access to every untagged agent, the opposite of the intent. Validation rejects the unguarded form when you save.

A tag condition on a type that carries no tags is dead code: it’s valid Cedar but can never match, and validation flags it when the policy pins the resource type. Pin the type on every policy that reads tags so you get that check. See Attribute reference for which types carry tags.

Principals carry an email and group memberships, nothing else. Write principal in Group::"nationality/US", not principal.nationality == "US". Validation rejects attribute reads on principals.

To reference a resource’s creator, guard the read the same way as a tag:

Write the attribute on the left of the comparison. The condition builder on the Access page parses this shape back into editable rows, and principal == resource.created_by leaves the policy read-only in the UI.

On create and update actions, resource is the state the operation produces, not the stored row. A forbid on production-tagged agents therefore fires on any update to an agent that carries the tag, even an update that doesn’t touch tags, and stops firing on the update that removes the tag.

A write-scoped tag condition therefore behaves as a state invariant. A resource that violates it is frozen for non-exempt principals until an update fixes the violation. Reads and deletes evaluate the stored row, so a resulting-state condition behaves normally on those verbs.

To gate the transition itself (adding or removing a specific tag), condition on changed_tags, the set of tag keys the update adds, removes, or changes:

The changed_tags attribute exists only on the update path, so this policy doesn’t fire on create. To close the create case too, pair the policy with a create-scoped clause that reads the tag directly:

A scalar field that holds its zero value doesn’t appear on the entity at all, so resource.enabled == true errors whenever enabled is false, and that error denies. Guard scalar reads the same way as tags:

You can’t condition on a scalar’s zero value. Absent and false are indistinguishable, so resource has enabled && resource.enabled == false never matches, saves without complaint, and silently does nothing. Write the rule as the positive case and flip it with unless.

Members of contractors can’t read agents tagged env=prod, no matter what their roles grant:

Nobody but an agent’s creator can update it:

Only the support group may call tools on the zendesk MCP server. The resource is the tool child entity, scoped to its parent server:

Nothing is readable until it’s explicitly cleared. An agent with no classification tag is denied, and only classification=public clears the gate:

Validation runs in strict mode against the current schema and reports every problem it finds at once. The error text is abbreviated here; search your own error for the quoted fragment.

Validation runs against the policy body, and only when a write includes it, so it never rejects a policy stored before a schema change. To run the current checks against an older policy, re-submit its body, for example by re-applying it with rpk ai policy apply. Editing only the name or description re-validates nothing.

A denial caused by access policies surfaces as a permission-denied error:

On update actions, authorization runs inside the write transaction, after request validation. An unauthorized caller can therefore receive an invalid-argument or not-found error instead of a permission-denied one, and a concurrent-modification conflict can surface as an aborted error. Treat any of them as a failure, and don’t branch on which arrives first.