Agentic Data Plane

Control Who Can Do What

Redpanda ADP uses role-based access control (RBAC) to gate every API call, so you can apply least-privilege access across your deployment and keep developers, operators, and service accounts to exactly what they need. RBAC in ADP composes permissions, roles, and role bindings, with scopes that range from the entire organization down to a single dataplane.

ADP ships built-in roles for common patterns (Admin, Writer, Reader, and task-specific Invoker roles) and supports custom roles for more granular control. This page explains the three-layer model, the ADP permission families, and how to pick the right role for each workload.

After reading this page, you will be able to:

Explain how ADP permissions, roles, and role bindings fit together
Differentiate between the Admin, Writer, Reader, and Invoker built-in roles
Identify which built-in role grants the permissions a user or service account needs

The three-layer model

Redpanda ADP authorization composes multiple layers. Each layer answers a different question.

Permission: What action is allowed? A permission is a string like dataplane_adp_llmprovider_invoke that names exactly one operation on one resource type. The gRPC service that handles an API call checks the caller’s permission set before executing.
Role: Which permissions go together? A role is a named bundle of permissions. ADP ships built-in roles for common access patterns (Admin, Writer, Reader, and a set of Invoker sub-roles), and you can define custom roles for more specific needs.
Role binding: Who gets the role, and where? A role binding attaches a role to a principal (user or service account) at a scope. Scopes range from the entire organization down to a single resource group or dataplane, so the same principal can have different permissions in different parts of your deployment.

A successful API call requires all three: the caller must hold a role binding whose role contains the permission the endpoint enforces, at a scope that covers the resource being acted on.

ADP-namespaced permissions

ADP permissions live in the following families, named by the namespace prefix:

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_transcript_*: Read agent conversation transcripts. Granted by the dedicated TranscriptReader role (and Admin), not by Writer or Reader, because transcripts carry full conversation content.
dataplane_adp_spending_*: Read AI spending data for governance and cost reporting.
dataplane_aiagent_a2a_*: Invoke agent-to-agent (A2A) operations on running agents.
dataplane_aigateway_*: Manage enterprise AI Gateway features (rate limits, spend limits, guardrails, model providers, audit, pricing, IAM).

Two more families belong to Redpanda Connect resources that ADP uses:

dataplane_pipeline_*: Manage and invoke Redpanda Connect pipelines.
dataplane_knowledgebase_*: Manage retrieval-augmented generation knowledge bases.

For the full list of permissions and which built-in role grants each one, see Roles and Permissions Reference.

Built-in roles

ADP includes the following built-in roles. Admin, Writer, and Reader are general-purpose. The remaining roles are narrow: a set of Invoker roles for runtime-only access, plus TranscriptReader for reading agent conversation transcripts.

Role What it grants

Role	What it grants
Admin	Every permission, on every resource. Use for cluster operators who configure providers, agents, MCP servers, and pricing.
Writer	Full create, read, update, and delete access across every ADP-namespaced API (LLM provider, MCP server, agent, agent credential, AI Gateway, pipeline, knowledge base). Use for developers who need to build and modify ADP resources.
Reader	Read-only access (`_get` and `_list`) across the same APIs, plus MCP runtime read operations such as `resources_list` and `prompts_get`. No create, update, delete, or invoke. Use for auditors, evaluators, and stakeholders who need visibility without mutation rights.
TranscriptReader	Transcript reads only: `dataplane_adp_transcript_get` and `dataplane_adp_transcript_list`. Transcripts carry full conversation content, so this access is granted through a dedicated role rather than bundled into Reader or Writer. Use for users and service accounts that read agent conversation transcripts. Provisioned for organizations with an ADP cluster.
AIAgentInvoker	A2A runtime only: `message_send`, `message_stream`, and the task lifecycle (`get`, `list`, `cancel`, `subscribe`). Use for service accounts that consume agents over A2A but should not manage them.
MCPInvoker	MCP runtime only: `initialize`, `ping`, the `resources_` read methods, the `prompts_` read methods, and `tools_list` / `tools_call`. No CRUD. Use for service accounts that call MCP tools without managing the servers themselves.
LLMProviderInvoker	A single permission: `dataplane_adp_llmprovider_invoke`. Use for applications that proxy LLM requests through AI Gateway but should not see or modify provider configuration.
PipelineInvoker	Runtime pipeline invocation only: `gateway_invoke`, `otlp_grpc_invoke`, `otlp_http_invoke`. Use for clients that produce telemetry or send data into Connect pipelines without managing them.

Admin

Every permission, on every resource. Use for cluster operators who configure providers, agents, MCP servers, and pricing.

Writer

Full create, read, update, and delete access across every ADP-namespaced API (LLM provider, MCP server, agent, agent credential, AI Gateway, pipeline, knowledge base). Use for developers who need to build and modify ADP resources.

Reader

Read-only access (_get and _list) across the same APIs, plus MCP runtime read operations such as resources_list and prompts_get. No create, update, delete, or invoke. Use for auditors, evaluators, and stakeholders who need visibility without mutation rights.

TranscriptReader

Transcript reads only: dataplane_adp_transcript_get and dataplane_adp_transcript_list. Transcripts carry full conversation content, so this access is granted through a dedicated role rather than bundled into Reader or Writer. Use for users and service accounts that read agent conversation transcripts. Provisioned for organizations with an ADP cluster.

AIAgentInvoker

A2A runtime only: message_send, message_stream, and the task lifecycle (get, list, cancel, subscribe). Use for service accounts that consume agents over A2A but should not manage them.

MCPInvoker

MCP runtime only: initialize, ping, the resources_* read methods, the prompts_* read methods, and tools_list / tools_call. No CRUD. Use for service accounts that call MCP tools without managing the servers themselves.

LLMProviderInvoker

A single permission: dataplane_adp_llmprovider_invoke. Use for applications that proxy LLM requests through AI Gateway but should not see or modify provider configuration.

PipelineInvoker

Runtime pipeline invocation only: gateway_invoke, otlp_grpc_invoke, otlp_http_invoke. Use for clients that produce telemetry or send data into Connect pipelines without managing them.

Pick the narrowest role that covers a workload. For example, an application that only needs to call an LLM through AI Gateway should hold the LLMProviderInvoker role, not the Writer role.

Identity and impersonation

ADP API calls authenticate as one of two identity types:

User identity (OIDC): A human user signed in through Redpanda’s OIDC provider. The ADP UI uses this identity when an admin manages ADP resources interactively.
Service account: A non-human identity backed by OIDC client credentials. Applications, CI jobs, and rpk ai use service accounts.

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

Where ADP fits in Cloud RBAC

ADP permissions are part of the same Cloud RBAC system that gates control-plane resources such as resource groups, networks, and clusters. The Admin, Writer, and Reader built-in roles each cover control-plane permissions, dataplane Kafka permissions, and ADP dataplane permissions in a single bundle, so a single role binding on the Writer role at the organization scope grants a developer access to every layer.