Policy-driven event mediation for APIs and brokers in enterprise security

At a glance

What this is: This is a Kong engineering post about using Kong Gateway to mediate REST-to-event traffic through Solace with shared policy enforcement.

Why it matters: It matters because IAM, NHI, and platform teams increasingly need one governance model for API consumers, event publishers, and service identities across hybrid application flows.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Kong’s engineering demo for event mediation between APIs and Solace

Context

Kong’s example is about policy enforcement at the boundary between HTTP requests and event brokers. The security question is not whether events are useful, but whether publishers, payloads, and delivery paths are governed with the same discipline as APIs.

That matters for identity governance because event mediation often relies on service accounts, keys, JWTs, and broker permissions that can sprawl outside the visibility of the main API programme. If the gateway becomes the control point, the control model has to follow the traffic path, not just the application team structure.

For teams extending governance across APIs, brokers, and non-human identities, the practical issue is consistency: authentication, validation, transformation, observability, and rate control all become part of the same identity perimeter. The challenge is not new integration, but whether access policy remains enforceable once messages leave the request-response world.

Key questions

Q: How should security teams govern access to event brokers through API gateways?

A: Security teams should treat event broker access as part of the same entitlement model used for APIs. That means binding each publisher to a named identity, enforcing authentication and schema checks at the gateway, and reviewing broker permissions on the same schedule as other machine accounts. The goal is to make publish rights observable, bounded, and revocable.

Q: Why do event-driven systems increase the need for NHI governance?

A: Event-driven systems increase NHI governance needs because publishers are often service accounts or tokens that can send high-volume traffic without direct human oversight. Once those identities can inject messages into a broker, access scope, throughput, and lifecycle offboarding become the real control points. Without them, the broker becomes a blind spot rather than a managed interface.

Q: What breaks when API and event security are governed separately?

A: When API and event security are governed separately, teams usually get inconsistent validation, weaker audit trails, and mismatched access controls. The same workload may be constrained at the API layer but left broad at the broker layer. That creates uneven blast radius and makes incident investigation harder because the control model no longer follows the traffic path.

Q: Who should own policy enforcement for API-to-event mediation?

A: Ownership should sit with the platform or identity governance function that can manage both access and transport policy consistently. Application teams may define schemas and topics, but the governing control plane should own authentication, rate limiting, credential review, and offboarding. That prevents each broker integration from becoming a one-off security decision.

Technical breakdown

How API gateways mediate event streams

An event gateway in front of a broker sits between producers and the messaging system, applying policy before messages are accepted or forwarded. In this pattern, Kong terminates the client interaction, validates request format, maps the request into a topic or queue destination, and then passes the payload to Solace. That creates a consistent enforcement layer for both synchronous APIs and asynchronous events. The technical value is not only routing, but normalising security controls so that message publication is treated like any other protected interface.

Practical implication: place authentication, schema checks, and topic mapping at the gateway so event brokers do not absorb unauthorised or malformed traffic.

Validation, transformation, and correlation in event mediation

The post shows three common gateway functions that matter in event systems. Validation blocks structurally invalid payloads before they enter the broker. Transformation reshapes REST fields into the event topic model, which reduces custom glue in the application layer. Correlation IDs add traceability across distributed services, giving operations teams a way to connect a single request to downstream subscribers. These are not cosmetic features. They are control points that determine whether events remain governable once they are emitted.

Practical implication: require schema validation and correlation headers at publish time so downstream investigation and troubleshooting are possible.

Rate limiting and size controls for broker protection

Event brokers are efficient at fan-out, which also makes them vulnerable to noisy publishers and oversized messages. Kong’s rate limiting and request-size limiting act as blast-radius controls, reducing the chance that a client can overwhelm the broker or flood subscribers. In identity terms, this is part of the non-human access boundary. A valid credential should not imply unlimited publish capacity. The policy layer has to distinguish authenticated access from operationally safe access.

Practical implication: enforce per-client throughput and payload caps on every event publishing path, not only on public APIs.

NHI Mgmt Group analysis

Event mediation is becoming an identity control plane, not just an integration pattern. When API gateways front brokers, they decide who can publish, what they can publish, and how that traffic is observed. That moves event systems into the same governance problem space as NHI, because the broker is now reached through credentialed, policy-governed machine access. The implication is that identity architecture has to include message flows, not only request endpoints.

Policy consistency across APIs and events reduces governance drift. The strongest value in this model is not the plugin itself, but the elimination of separate control expectations for REST and asynchronous delivery. If one team enforces schema validation, rate limits, and observability while another treats broker access as a back-end detail, the programme develops uneven risk. That creates a governance gap across the same machine identity estate. Practitioners should treat event publication as part of the same access review and control standard as API access.

Blast-radius control becomes the decisive design principle for event publishers. Rate limits, payload caps, and correlation headers all constrain what an authenticated publisher can do once access is granted. This is especially important for service accounts and other NHIs that can emit large volumes of operational traffic without human intervention. The lesson is that publish rights are not enough to describe risk. Practitioners should define safe operational boundaries for every event-producing identity.

Identity-aware event routing should be understood as a lifecycle issue as much as a runtime issue. If a service account can publish into a broker today, the governance question is how that access is provisioned, monitored, and eventually removed. Without lifecycle discipline, mediation only controls the path, not the entitlement. That means offboarding, credential review, and broker policy review have to be coupled. Practitioners should align event infrastructure with NHI lifecycle governance rather than treating it as a separate integration layer.

Named concept: event mediation boundary. This post illustrates the point where API governance stops being a request-only discipline and becomes a message-governance discipline. Once Kong sits in front of Solace, the security boundary expands to include topic mapping, publisher authentication, and delivery protections. Practitioners should use that boundary to decide where access policy, audit logging, and transformation rules must live.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Read NHI Lifecycle Management Guide for the governance model that ties provisioning, review, and offboarding together across machine identities.

What this signals

Event mediation is now a governance problem for machine identities as much as an integration problem for developers. As more application traffic moves through brokers and gateways, the practical question becomes whether each publisher is owned, bounded, and reviewable. Teams that already struggle to inventory service accounts should expect the same visibility issues to surface in event routing unless access and observability are unified.

With 52% of companies able to track and audit the data their AI agents access, the market signal is clear: blind spots in non-human access are already normal, and event systems can widen them if broker permissions sit outside IAM oversight. The next maturity step is to align message publishing, policy enforcement, and lifecycle review across the same entitlement layer.

Identity-aware mediation needs a lifecycle lens. When publisher credentials are created for temporary projects, migrations, or partner integrations, the biggest failure mode is not initial access but forgotten offboarding. That is where the NHI Lifecycle Management Guide becomes relevant for teams deciding how to operationalise broker governance.

For practitioners

• Treat event publishers as governed NHIs Map every Solace publisher to a named service identity, owner, and purpose so broker access can be reviewed like any other non-human entitlement.
• Apply schema validation before broker ingress Reject malformed or incomplete payloads at the gateway so invalid events never enter the broker and downstream services do not inherit bad data.
• Enforce per-publisher throughput limits Set rate limits and payload caps for each publish path to keep authenticated clients from overwhelming the broker or creating downstream fan-out spikes.
• Add correlation IDs to every event flow Standardise correlation headers at publish time so operations and investigation teams can trace a request across API, broker, and subscriber layers.
• Review offboarding for broker-facing credentials Remove unused keys, JWTs, and broker groups when services are retired or repurposed so event access does not outlive the workload that needs it.

Key takeaways

• Kong’s Solace pattern shows that event delivery is governed access, not just messaging.
• The control set that matters most is authentication, validation, transformation, observability, and rate limiting applied at publish time.
• Teams should manage broker-facing identities with the same lifecycle discipline they apply to other NHIs.

Key terms

• Event Mediation Boundary: The point where a gateway decides whether an event producer may publish, what shape the message must take, and how it is routed to the broker. In practice, it is the control boundary between application traffic and message infrastructure, where identity, policy, and delivery rules converge.
• Broker-facing Identity: A non-human identity used to authenticate to a message broker or event system on behalf of a workload, integration, or service. It should be owned, scoped, reviewed, and revoked like any other machine credential, because broker access can carry broad downstream impact.
• Publish-time Validation: The act of checking a message for schema correctness, required fields, and acceptable structure before it enters the broker. This reduces downstream risk by stopping malformed or unsafe events at the control point where they can still be blocked.
• Blast-radius Control: A safeguard that limits how much damage an authenticated identity can cause once access is granted. In event systems, this usually means rate limits, payload caps, and routing constraints that prevent a single publisher from overwhelming a broker or subscriber estate.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.

This post draws on content published by Kong: Connecting Kong and Solace: Building Smarter Event-Driven APIs. Read the original.