Beyond IAM: governing Amazon MSK for teams and AI agents

IAM policies and CloudTrail tell you who can connect to an Amazon MSK cluster and log what they did. They don’t tell you how to structure access once more than one team shares that cluster, what happens to personally identifiable data inside a payload when an engineer needs to debug production, or who approved a destructive operation like an offset reset.

In this session, Chad Harris, Head of Product at Factor House, draws on his experience running Kafka on high-volume, PCI-compliant systems to work through the governance patterns that fill that gap: mapping team structure onto role-based access control rather than per-principal IAM policies, practical multi-tenancy on a shared MSK cluster across namespacing, quotas, and view isolation, and field-level data masking so engineers can debug production without reading customer data.

The session closes on approval workflows for operations that are hard to undo, such as topic deletion and offset resets, and what it takes to let an AI agent inspect a cluster or carry out operational tasks once those controls are in place.

What the session covers

• Mapping team structure onto role-based access control instead of per-principal IAM policies
• Practical multi-tenancy on a shared MSK cluster: namespacing, quotas, and view isolation
• Field-level data masking so engineers can debug production without reading customer data
• Approval workflows in front of destructive operations like topic deletion and offset resets
• What it takes to let an AI agent operate on Amazon MSK safely

This is a technical session aimed at platform engineers and data engineers running Amazon MSK for more than one team.