TL;DR: API gateways can impose authentication, validation, transformation, and rate limits on event flows, while preserving a familiar policy layer for REST and broker traffic, according to Kong. The broader implication is that event mediation now sits inside identity and access governance, not outside it.
NHIMG editorial — based on content published by Kong: Connecting Kong and Solace: Building Smarter Event-Driven APIs
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Kong's full blog post covers the implementation detail this post intentionally leaves for the source:
- Step-by-step Kong and Solace configuration, including the route definitions and plugin settings used in the demo.
- The exact decK configuration structure for authentication, validation, transformation, and protection policies.
- Hands-on test cases showing how malformed requests, unauthorised access, and traffic floods are handled.
- The example repository and local setup instructions needed to reproduce the event mediation flow.
👉 Read Kong’s engineering demo for event mediation between APIs and Solace →
Event-driven APIs and governance gaps teams are missing?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Policy-driven event mediation for APIs and brokers in enterprise security