Kafka governance: guardrails, not gatekeeping
Give application teams the autonomy with Kafka to modernize real-time apps faster, while keeping control.
Developer access still runs through tickets
Kafka underpins some of the most sensitive systems, so platform teams lock it down to secure it. Every time someone wants to do something with Kafka, they need to raise a ticket: adding a new user, viewing what’s inside a topic, requesting access for an AI agent.
Kafka access is scattered
Kafka lacks a governance layer: Native Kafka ACLs and IAM sit inside each cluster and were designed for a single application access. Not for global role–based access across multiple Kafka environments.
Developers have no safe way to explore data
Without fine-grained permissions, data masking, discovery and query tooling, data will be copied out of Kafka and passed through tickets to explore it. One sensitive field in a topic can block access to it entirely.
AI agents hold standing access to Kafka
Connecting AI agents through a service account turns one developer’s long-lived access into a shared identity used by potentially thousands of agents. Credentials remain static, permissions are too broad, and audit trails lose human accountability because every action appears under the same identity.
How to safely delegate to developers & agents
Map identity to access
Connect Lenses to your SSO, so developers get authorized securely before accessing Kafka. Their identity provider groups automatically map to Lenses' granular, multi-Kafka IAM roles. No separate accounts to provision or manage.
Scope roles to exactly what’s needed
Configure IAM roles with granular user rights across the entire Kafka estate, scoped to the specific assets and actions each team needs - so developers get exactly the access their role requires, and nothing more.
Mask sensitive fields
Set data policies once, and Lenses masks sensitive fields for every developer automatically - so teams can discover and query Kafka data, without breaching compliance.
Give agents scoped, short-lived credentials
Connect AI agents through Lenses MCP. They authenticate with short-lived, scoped, revocable OAuth 2.1 tokens instead of broad, persistent shared credentials - so an agent can only do the job it was set up for.
Send every action into your audit trail
Every data access and action - human or agent - is logged automatically and shipped to your existing security and event management tooling, so you can prove what happened.
Let developers troubleshoot application failure
An application teams can monitor their own apps, metrics, explore their own consumer groups, and find a poison pill in a Kafka topic, without being exposed to sensitive data or seeing other teams’ apps or data.
Allow Support to restart connectors themselves
A broken connector at 2am shouldn't mean paging platform admins. Support engineers can restart it themselves, without seeing its underlying configuration.
Enable QA to reset their consumer offsets
Recovering from a brokenad deployments is faster when developers can reset their own offsets, on their own schedule, without waiting on anyone else.
Permit a Kafka SRE Agent to diagnose a stalled consumer
A Kafka SRE Agent can securely investigate a stalled consumer - inspecting lag and permitted records, spotting poison pills or schema changes, and recommending a fix - without touching unrelated data.
Governed multi-modal Kafka access for engineers
Safely open up streaming data to developers
Platform adoption
With governance and visibility maintained.
Data access in minutes
Quickly unite developers with the data they need.
Full compliance
Granular roles, policies and permissions help uphold data regulations.
Platform productivity
Fewer tickets and more capacity to support teams
Kafka governance features
Multi-Kafka Operating Fabric
One access and operating layer over every Kafka cluster, so governance is defined globally instead of cluster by cluster.
Lenses IAM Model
Granular RBAC over SSO, from topic down to field level, turning access requests into scoped self-service for users, service accounts and agents alike.
Catalog, SQL Studio and IDE access
Every topic, schema and owner across the estate, discoverable and queryable in place from the UI, CLI or VS Code, with nothing copied into a second store.
Governed Agent Access
Agents connect through Lenses MCP with short-lived, finely scoped OAuth tokens, so they carry a policy of their own rather than a developer's rights.
Field-Level Data Masking
Field-level masking on read, enforced across every Lenses access path - UI, SQL Studio, CLI, MCP - so every user and agent sees only the data they're cleared for.
Audit trail
Every action by a person or an agent, logged with actor and timestamp and shipped to your SIEM, so you can prove what happened.
What makes Lenses different?
Enterprise governance-first architecture
Powerful permission, data masking and auditing model build for enterprise environments
Vendor agnostic
Lenses works on top of any Kafka flavor including MSK, Confluent, Aiven, and Apache Kafka setups.
No data movement
Query events with SQL syntax with data in its place; nothing is materialized in a separate store.
Scales to an enterprise footprint
Designed to scale to hundreds of clusters across different networks and distributions.
Lenses gave us the confidence to migrate to Confluent Cloud, and the migration overall has improved our engineering productivity by 20-30%.
Guardrails, not gatekeepers
Sep 8 - 5PM CEST
Kafka self-service governance is a way to let application teams access and work with a limited set of Kafka topics, schemas, connectors and other Kafka assets directly - without raising a ticket to the platform team - while still enforcing centralized access control, data masking and audit logging. Lenses provides this through a governance layer that sits on top of any Kafka.
Most Authorization for Kafka is designed for application-authorization and access, not user-authorization. They only control coarse, cluster-level access - they don't offer field-level permissions, don't span multiple clusters, and require manual changes for every new grant. They are also traditionally tied to a single Kafka vendor, making it difficult for multi-Kafka and vendor environments.
Yes. With Lenses, platform engineers configure IAM roles scoped to what each team or role needs, and developers get that access automatically through SSO - without a manual approval step for every request that falls within their role.
Lenses applies field-level data masking on read, so sensitive fields are hidden automatically wherever developers access data - through the UI, SQL Studio, CLI or MCP. This lets a topic stay open to a team without exposing the specific fields they're not cleared to see.
Yes. Lenses' SQL Snapshot engine lets developers query Kafka topics in place using SQL syntax, with no data materialized or copied into a separate store. Combined with field-level masking, this removes the common workaround of copying topics to a laptop just to inspect them.
AI agents connect through Lenses MCP and authenticate using short-lived, scoped, revocable OAuth 2.1 tokens, rather than inheriting a developer's standing credentials. Each agent gets a policy of its own, so its access can be narrowed to a specific job and reviewed independently of the person who set it up.
A shared service account turns one developer's access into a single identity used by potentially thousands of agents. Because the credential is static and shared, every agent action shows up under the same identity, so audit trails lose the ability to attribute actions to a specific agent or task and making it impossible to revoke for just one Agent It causes a further risk as it’s a long-living service account, rather than being granted privileges for a very specific task.
Yes. Every action taken by a person or an agent - including data access - is logged with actor and timestamp and can be shipped to an external SIEM or security tooling, supporting compliance obligations like GDPR, SOX and PCI DSS.
Yes. Lenses is vendor-agnostic and works on top of any Kafka flavor, including Amazon MSK, Confluent, Aiven and Apache Kafka. Access roles and governance policies are defined once and applied consistently across the entire estate, rather than being configured cluster by cluster.
Self-service in Lenses means developers get scoped access within roles the platform team defines - not open, ungoverned access. Platform engineers retain control over what each role can see and do, and every action remains logged and auditable.
Lenses connects to your existing SSO provider, and identity provider groups map directly to Lenses' IAM roles. Developers sign in with their existing identity, so there's no separate account provisioning step for platform teams to manage.
Lenses supports governed access through the UI, CLI, IDE (such as VS Code) and MCP, so developers and agents can work with Kafka through whichever interface fits their workflow, with the same permissions and masking enforced everywhere. In each case, the users can be authorized over OAuth.
