Beyond IAM: governing Amazon MSK for teams and AI agents

Amazon MSK removes most of the work of running Kafka brokers, but it does not answer the questions a platform team gets asked once more than one team is on the cluster: who can read this topic, what happens to the PII inside the payload, who approved that offset reset, and how you prove any of it after the fact. IAM policies and CloudTrail cover part of this. The rest is left to whatever you build or buy on top.

In this session, Chad Harris works through those requirements one at a time, drawing on his experience running Kafka on high-volume, PCI-compliant systems at Block. He covers how to map team structure onto role-based access control rather than per-principal IAM policies, what practical multi-tenancy looks like on a shared MSK cluster across namespacing, quotas, and view isolation, where field-level data masking belongs so engineers can debug production without reading customer data, and how to put approval workflows in front of the operations that are hard to undo: topic deletion, offset resets, configuration changes.

The session closes on agentic Kafka operations: what it means to let an AI agent inspect a cluster or carry out operational tasks, and why the controls above are what make that safe to attempt. Throughout, the focus is on what each control looks like once implemented, including the audit trail it produces, so you can judge what your own MSK setup is currently missing.