Agentic Data Plane

Control Who Can Do What

Redpanda Agentic Data Plane decides who can do what with access policies. A policy names a principal, an action, and a resource, and either permits or forbids. That’s the authorization model: policies are what you write, and policy evaluation is what every API call resolves against.

Role-based access control (RBAC) has one job here. Assign the Admin role to the people who administer the deployment, and they author the policies that grant everyone else. Admin is the only built-in role that carries Agentic Data Plane permissions at all.

This page explains how the two fit together and how to grant access to a user, a group, or a service account.

After reading this page, you will be able to:

  • Explain how access policies decide who can do what in Agentic Data Plane

  • Explain why Admin is the only built-in role that reaches Agentic Data Plane

  • Grant a user, a group, or a service account the access it needs

Policies decide, roles bootstrap

Every Agentic Data Plane request resolves the same way:

  • A request is denied unless a permit matches it.

  • A matching forbid always wins, over any permit and over anything a role granted.

Both role bindings and access policies feed that one evaluation. Redpanda compiles your role bindings into permits automatically, so an Admin’s access arrives through the same path as a policy you wrote. There is no separate RBAC check that runs first and no second system to reason about.

The division of labor:

  • Access policies express the decision. A policy takes a user or an identity provider group as its principal, conditions on resource tags and ownership, narrows to a single resource, and denies. Policies are how you grant access.

  • RBAC bootstraps and administers. It gets your first administrators in, and it is deliberately coarse: Admin, or nothing.

RBAC is not the mechanism for granting day-to-day access in Agentic Data Plane. When you need to express something, express it as a policy.

Access policies are a preview capability, enabled per organization. Until they’re enabled for yours, an Admin binding or a custom role is the only way to reach an Agentic Data Plane API. See Manage Access Policies.

Admin grants every Agentic Data Plane permission on every resource, so it is not a least-privilege answer for day-to-day users. Bind Admin to the people who administer the deployment. Grant everything else with a policy.

Admin is the only built-in role that reaches Agentic Data Plane

Built-in roles span all of Redpanda Cloud. Only Admin reaches Agentic Data Plane.

Role What it grants in Agentic Data Plane

Admin

Every Agentic Data Plane permission, on every resource. Bootstraps a deployment, and covers the operators who configure providers, agents, MCP servers, and pricing, and who author access policies.

Writer, Reader

Nothing. Both roles keep their control-plane, Kafka, pipeline, and knowledge-base permissions, so a Writer can manage Redpanda Connect pipelines and knowledge bases and still can’t read, create, or invoke an agent, MCP server, or LLM provider.

PipelineInvoker and the Kafka and Schema Registry roles

Nothing. These cover Redpanda Connect pipelines, topics, consumer groups, and Schema Registry subjects.

There are no Agentic Data Plane Invoker or transcript-reader roles to assign. Runtime-only access for a service account (calling an MCP tool, proxying an LLM request) and read access to conversation transcripts come from policies you write, not roles you pick from a list. Redpanda used to ship narrow built-in roles for exactly those cases and no longer provisions them, because a policy does the same job with a condition and a scope attached.

If your organization predates this change, those roles may still appear in your role list. Don’t build new grants on them. Author the equivalent policy instead.

Grant access to a user, group, or service account

Write a policy. The principal is a user or a group, so you can grant a whole identity provider group in one statement and let group membership stay managed in your IdP.

For example, to let your support team call the tools on one MCP server and nothing else:

permit (
  principal in Group::"support",
  action == Action::"McpServerTool.call",
  resource is McpServerTool in McpServer::"zendesk"
);

Policies also do the things a role bundle structurally can’t: condition on a resource tag, restrict access to a resource’s creator, or deny an action across every principal at once. See Manage Access Policies for the authoring workflow, the actions a policy can name, and worked examples.

Access policies use their own vocabulary. A policy names an entity type and a verb, such as Action::"Agent.get", not the permission strings on this page. See Action reference.

A custom role holding Agentic Data Plane permissions still works. Reach for one when you need a permission bundle bound at a control-plane scope, or for the dataplane_aiagent_a2a_* permissions, which no policy action covers.

Agentic Data Plane permissions

Permissions are the RBAC-side vocabulary. You need them to read what Admin grants and to define a custom role. They are not what a policy names.

Agentic Data Plane permissions live in these families:

  • dataplane_adp_mcpserver_*: Manage and call MCP servers (CRUD plus runtime operations like tools_call and resources_read).

  • dataplane_adp_llmprovider_*: Manage LLM providers and proxy LLM requests through AI Gateway. The _invoke permission is what your applications need at runtime.

  • dataplane_adp_agent_* and dataplane_adp_agent_credential_*: Manage declarative AI agents and the OIDC credentials issued to them.

  • dataplane_adp_policy_* and dataplane_adp_policytemplate_*: Author and read access policies and policy templates.

  • dataplane_adp_transcript_*: Read agent conversation transcripts, which carry full conversation content.

  • dataplane_adp_auditlog_*: Read audit log events, which record who attempted an action, on which resource, and whether it was allowed.

  • dataplane_adp_spending_*: Read AI spending data for governance and cost reporting.

  • dataplane_aiagent_a2a_*: Invoke agent-to-agent (A2A) operations against an agent’s own ingress. These are the one Agentic Data Plane family a policy can’t govern; see A2A runtime permissions.

  • dataplane_aigateway_*: Manage enterprise AI Gateway features, including OAuth providers and clients, model providers, rate and spend limits, audit, and pricing.

Admin is the only built-in role that holds any of them. The legacy dataplane_mcpserver_* namespace, which older proto versions still enforce, is scoped the same way.

Two more families belong to Redpanda Connect resources that Agentic Data Plane uses. These are owned outside Agentic Data Plane, so they stay in the Writer and Reader roles and are outside what a policy can govern:

  • dataplane_pipeline_*: Manage and invoke Redpanda Connect pipelines.

  • dataplane_knowledgebase_*: Manage retrieval-augmented generation knowledge bases.

For the full list, see Roles and Permissions Reference.

Identity and impersonation

Agentic Data Plane API calls authenticate as one of two identity types:

  • User identity (OIDC): A human user signed in through Redpanda’s OIDC provider. The Agentic Data Plane UI uses this identity when an admin manages Agentic Data Plane resources interactively.

  • Service account: A non-human identity backed by OIDC client credentials. Applications, CI jobs, and rpk ai use service accounts.

Both are policy principals. A service account is granted access the same way a user is, with a policy naming it as the principal.

Account impersonation, which lets Redpanda Console reuse a user’s identity for Kafka API and Schema Registry calls, applies to those two subsystems only. Agentic Data Plane endpoints continue to authenticate clients directly through their OIDC tokens, regardless of how account impersonation is configured at the cluster level.

Where Agentic Data Plane fits in Redpanda Cloud RBAC

Agentic Data Plane permissions are part of the same Redpanda Cloud RBAC system that gates control-plane resources such as resource groups, networks, and clusters. They are scoped more tightly than the rest of it.

The Writer and Reader roles bundle control-plane permissions with dataplane Kafka permissions, so a Writer binding at the organization scope covers those layers in one grant. It does not reach Agentic Data Plane. A developer who holds Writer on the organization can create a cluster and manage topics and pipelines, and still gets a permission-denied error from every agent, MCP server, and LLM provider API until a policy grants that access.

Admin spans every layer, including Agentic Data Plane.

Next steps