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.

Redpanda also seeds a few system-managed policies into every organization, such as the Owner lifecycle policy that lets users manage resources they created, and the Agent capability ceiling that forbids agents from minting credentials or controlling OAuth settings. They take part in the same evaluation as the policies you write. See The built-in Owner lifecycle policy.

The division of labor:

  • Access policies express the decision. A policy takes a user, an identity provider group, or an agent 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 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. A Writer can’t read, create, or invoke an agent, MCP server, or LLM provider.

The Kafka and Schema Registry roles

Nothing. These cover Kafka and Schema Registry resources, such as topics, consumer groups, and 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, a group, or an agent. Naming a group lets you grant a whole identity provider group in one statement and let group membership stay managed in your IdP. To grant an agent its own permissions, see Grant an agent its own permissions.

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. Use one when you need a permission bundle bound at a control-plane scope.

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 fall into families, including:

  • 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_adp_agentnetwork_*: View the agent network topology and its metrics.

  • dataplane_adp_guardrail_*: Manage guardrails.

  • dataplane_adp_budget_*: Manage per-agent LLM spend budgets.

  • dataplane_adp_a2a_invoke: Invoke an agent over agent-to-agent (A2A). One permission covers every A2A call, and a policy grants it with Action::"Agent.invoke". The older per-method dataplane_aiagent_a2a_* permissions are no longer evaluated. See A2A runtime permissions.

  • dataplane_aigateway_*: The AI Gateway’s own OAuth surface: inbound OAuth client registrations for external tools, dynamic client registration and client ID metadata document settings, the outbound OAuth providers MCP servers use for user-delegated authentication (including attaching one to a server), and per-user OAuth connections in the token vault.

Admin is the only built-in role that holds any of them. The legacy dataplane_mcpserver_* namespace and the legacy dataplane_aiagent_create, _get, _list, _update, and _delete set are scoped the same way.

For the full list, see Roles and Permissions Reference.

Identity and impersonation

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

  • User identity (OIDC): A human user signed in through Redpanda’s OIDC provider. The Agentic Data Plane UI uses this identity, and so does rpk ai after you sign in with rpk ai auth login.

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

  • Agent: A non-human identity for an agent, used when the agent calls MCP tools and LLM providers with the credentials issued to it.

All three are policy principals. A service account is evaluated as a user identity, so you grant it access the same way you grant a user, with a policy naming it as the principal. An agent is named as Agent::"<agent-name>". See Grant an agent its own permissions.

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 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.

Check your understanding

Answer each question, then expand it to compare.

A user holds the Writer role on the organization. Can they invoke an agent?

No. Writer and Reader carry no Agentic Data Plane permissions. A Writer can manage clusters and topics and still gets a permission-denied error from every agent, MCP server, and LLM provider API until a policy grants that access.

A permit policy matches a request, and so does a forbid policy. Which wins?

The forbid. A matching forbid always wins, over any permit and over anything a role granted. Agentic Data Plane denies a request unless a permit matches it.

You need a service account that can call one MCP server’s tools and nothing else. Do you reach for a role or a policy?

A policy, with the service account as the principal, the McpServerTool.call action, and the resource scoped to that one server. Redpanda no longer provisions narrow built-in roles for runtime-only access; a policy does the same job with a condition and a scope attached.

When is a custom role still the right tool?

When you need a permission bundle bound at a control-plane scope. Everything else, including A2A invocation, is granted with a policy.

Next steps