Kafka governance, without the bottleneck
Give application teams and AI agents guardrails and self-service for Apache Kafka, without gatekeeping the data they need.
Kafka access requires tickets for everything
Kafka underpins some of the most sensitive systems, so you 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.
No unified Kafka access model
Native Kafka ACLs and IAM are cluster-specific; not designed for multi-cluster or role-based governance. You end up managing Kafka access control separately on every cluster.
Sensitive data blocks Kafka exploration
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 with shared credentials are risky
Shared service accounts mean thousands of AI agents run under one identity with static, broad permissions. Audit trails lose accountability, and you can't revoke one agent without affecting all.
How to safely delegate to developers & agents
Connect to your SSO
Developers authenticate via your identity provider; groups automatically map to fine-grained Kafka roles. No extra accounts to 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 alerting 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.
Allow AI SRE agents to diagnose Kafka issues
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.
Kafka governance that scales with your teams
Safely open up streaming data to developers
Platform adoption
Offsets translate automatically, so apps resume exactly where they left off.
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
Control Kafka access at role, topic, and field level with SSO integration.
Discover Kafka topics from any IDE
Explore topics and schemas from your UI, CLI, or VS Code – no data movement.
Governed Agent Access
Connect AI agents with scoped, short-lived OAuth tokens; not shared developer credentials.
Automatic Field-Level Data Masking
Mask sensitive Kafka fields across all access methods – UI, SQL, CLI, MCP – automatically.
Audit trail for compliance
Every Kafka access action logged with actor and timestamp – shipped to your SIEM.
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 AWS 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%.
Watch our latest governance for Kafka webinar
To play this video, accept functional cookies in your privacy settings.
Vimeo video
Kafka governance resources
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.
