**TL;DR? Event Gateway 1.3 introduces the following:**
Have you ever watched somebody pump their own gas? Nobody's standing there with a clipboard. You swipe a card, pick a grade, and the pump takes it from there, because the pump has the rules built in: a pre-authorized amount, an automatic shutoff when the tank is full, and a nozzle that physically won't fit the wrong car. Self-service works only because someone put the limits in the pump instead of on a laminated sign.
Shared Kafka clusters mostly still run on the limits listed on the laminated sign. The central team would *love* for every team to create its own topics. The central team is also the one that gets paged when somebody creates a topic with hundreds of partitions; the onboarding calls get scheduled, and the review queue gets longer with every new team.
Event Gateway 1.3 is about moving the limits into the pump, plus a few other things that make the pump nicer to use. (If you want the full list of what changed in each release, the [_Event Gateway changelog_](https://developer.konghq.com/event-gateway/changelog/)_Event Gateway changelog_ has it.)
How many partitions are too many? Who gets to decide? Is the answer written down somewhere, and has anybody opened that page since the last reorg? ACLs can't help here, because they answer whether a principal may issue a command at all, and they never read the command. A sensible topic request and a hundred-partition one look identical to them, so platform teams cover the gap with wiki conventions, manual review, or custom tooling, and all three get harder as more teams share the cluster.
The [_Request Rule Validator policy_](https://developer.konghq.com/event-gateway/policies/request-rule-validator/)_Request Rule Validator policy_ is Event Gateway's traffic control policy for this. You write rules against the contents of a Kafka request, like partition count, replication factor, topic and consumer group naming, and ACL bindings. It also reaches into client settings, so you can require producers to acknowledge writes from all in-sync replicas. Each rule is an expression describing what a valid request looks like; when the expression evaluates to false, the rule's action *runs*.
There are two actions:
Batched requests get equal treatment. When a create-topics request carries several topics, and one breaks a reject rule, only that topic is rejected, and the rest go through. One more tip from the docs: put the validator after your ACLs policy, so a client that isn't authorized learns nothing about your rules before it gets turned away. Once you configure a create-topics rule, the gateway turns off automatic topic creation on metadata requests, so clients can't skip your rules by auto-creating topics.
*ACLs decide whether you can ask. Rules decide what you can ask for.*
In gas pump terms, 1.3 gives you the pre-authorized limit and the receipt. The mid-fill slowdown isn't in this release, since a rule's actions are reject or passthrough, and the validator doesn't yet amend a request to safe values or throttle it.
Kafka stores bytes, which is wonderful for Kafka and less wonderful for a developer who knows REST and JSON and just wants to send an order event. To do it, they need a schema registry, a serializer, the right registry credentials, and a working opinion about binary formats. Operators end up teaching every new team the same lesson, or each team writes glue code in its own language.
**Record transcoding moves that work into the gateway, and it comes as a pair of policies. **[_**Record Transcode Produce**_](https://developer.konghq.com/event-gateway/policies/record-transcode-produce/)_**Record Transcode Produce**_** takes the JSON a producer sends and converts it to Avro before the record is written to the backend topic. **[_**Record Transcode Consume**_](https://developer.konghq.com/event-gateway/policies/record-transcode-consume/)_**Record Transcode Consume**_** converts the stored Avro back to JSON for a consumer that doesn't run a schema registry client, and the record in the backend cluster stays Avro. **
With the consume policy, systems allowed to see the original format keep access to it. The produce policy changes the stored format for good, since the cluster never receives the original. You point the policy at a schema in your registry by subject and version, or embed the schema inline in the policy configuration, and converting to Avro needs one of those because Avro can't serialize without a schema. Nobody has to write a custom connector to get JSON into Kafka, and in 1.3 the supported formats are JSON and Avro.
It works like subtitles on a foreign film. The movie keeps speaking its original language, and everyone in the room reads it in their own. The analogy breaks down in one place: subtitles go one way, but the gateway converts both ways.
Define the format once at the gateway, and every client gets it for "free."
Records often carry values only some consumers should see, like emails, account numbers, or names. Without masking at the gateway, hiding a field means maintaining separate sanitized copies of a topic, and anyone who maintains a sanitized copy knows how that story ends.
**The **[_**Mask Fields policy**_](https://developer.konghq.com/event-gateway/policies/mask-fields-consume/)_**Mask Fields policy**_** works on string fields at the gateway in Event Gateway 1.3**. On the consume side, it redacts the value for the client that reads it and leaves the stored record alone, so systems that are permitted to see the original keep seeing it. A produce-side version masks the value before it's written to the cluster, and because the cluster never receives the original, you can't undo it. You get three strategies: keep a number of leading and trailing characters and replace the middle with a phrase of your choosing, handle an email's local part and domain separately (including keeping the whole domain), or replace the whole value. Keep the first character for the broadcast-TV treatment, where the word is still obvious, and nobody's ears get hurt. A support app can see which company an email address belongs to without seeing who the person is.
You can list field paths one by one, or you can let the schema decide. With Confluent Schema Registry, an expression can select every field that carries a PII tag, so when the schema evolves and somebody tags a new field, it's masked with no policy change. The docs call this the recommended approach, and it builds on the schema metadata work that arrived in 1.2. It also means anyone who can edit schema tags can change what's masked, so keep write access to the registry limited to people you trust.
Two gotchas worth a minute. Masking can break client-side validation, since a client that checks the format of an SSN may reject a masked one, so confirm your clients accept masked values first. And the consume masker runs under a Schema Validation policy, which needs its failure mode set to skip or error. A parent set to passthrough or mark delivers records without parsing, so the client receives the fields unmasked.
(Full disclosure: the masker handles string fields only, so numbers and booleans aren't covered in 1.3)
Amazon MSK clusters can use IAM access control instead of passwords or certificates, so a gateway in front of one has to authenticate with IAM.
**In 1.3, Event Gateway can **[_**authenticate to MSK backends with AWS IAM**_](https://developer.konghq.com/event-gateway/configure-aws-iam-backend-cluster-auth/)_**authenticate to MSK backends with AWS IAM**_**. **By default, it uses the AWS SDK's standard credentials chain, so environment variables, a shared credentials file, or an EC2, ECS, or EKS instance role all work. If the cluster lives in another AWS account, the gateway can assume an IAM role first. It shows up with the building's own badge instead of a homemade one, and that IAM authentication covers only the hop between the gateway and the backend cluster, separate from how your clients authenticate to the gateway. You'll need an MSK cluster with IAM access control enabled that the gateway's data plane can reach (the IAM listener uses port 9098 by default), and credentials with the MSK IAM permissions to connect to and describe the cluster.
Check out the demo below to see Event Gateway 1.3 in action.
Konnect already governs your APIs, your LLM traffic, and your MCP servers from one place, and Event Gateway extends that to Kafka.
**Version 1.3 adds request inspection, record reshaping, and field protection, all with the same self-service model your API teams already use.**
The timing comes from AI agents. Event streams increasingly feed them, which means more non-human clients on your cluster, and none of them are going to read the wiki page. Rules in one place are much easier to write now than to chase across every team later. And because Event Gateway sits in front of the Kafka clusters you already run, there's no migration and no new cluster to operate.
Why was the Kafka topic so popular? It had a lot of followers. Ok, that was *bad*, but if you've run Kafka, you've said worse in a postmortem.
[_**Book a demo **_](https://konghq.com/contact-sales)_**Book a demo **_of the Kong Event Gateway today!
Most teams handle field-level data protection with client-side interceptors — code that has to live in every producer and consumer, in every language, maintained by every team that touches the topic. Renaming a topic means a migration project. And
Kong Catalog is the system of record for every interface running across your organization — regardless of which team built it, which cloud it runs on, or which gateway sits in front of it. Where it previously tracked APIs, Catalog now treats AI Mode
Your infrastructure already has the raw materials: compute (VMs, containers, serverless), event streaming (Kafka, Kinesis, Pub/Sub, RabbitMQ), data stores (warehouses, databases, object storage), and AI endpoints (any hosted or self-hosted LLM). Tho
You wouldn't expose a REST API without a gateway. What about Kafka? Before we talk about an event gateway, it's worth grounding ourselves on what an event is. An event is simply a record of something that happened. In modern integration, there are
The MSK exposure problem Amazon MSK brokers live in private subnets by default. That's the right default. Kafka's protocol wasn't designed for untrusted networks — it has no concept of rate limiting, no built-in field-level encryption, and its ACL
Organizations scaling their event streams usually run into the exact same pattern of chaos: Security policies become inconsistent across teams. Data contracts drift or break silently in production. Observability is totally fragmented. Governance bec
