Notifications
Clear all
Topic starter
25/06/2026 10:32 pm
TL;DR: Agentic systems need a durable commit log rather than static state snapshots, according to Kong, and Kong lays out a Kafka-backed reference architecture that governs synchronous model calls, MCP tool use, and asynchronous event streams through Kong AI Gateway and Kong Event Gateway. The operational implication is that agentic control becomes a logging, schema, and policy problem, not just a runtime problem.
NHIMG editorial — based on content published by Kong: Building the Agentic Commit Log: A Technical Blueprint with Apache Kafka and Kong
Questions worth separating out
Q: How should security teams govern AI agent actions that must be replayed later?
A: Security teams should govern replayable agent actions as immutable events, not as mutable session state.
Q: Why do agentic systems need both runtime controls and event governance?
A: Agentic systems make decisions at runtime, but those decisions also create a historical record that outlives the session.
Q: What breaks when agent events are not schema-governed?
A: When agent events are not schema-governed, consumers stop agreeing on what the data means.
Practitioner guidance
- Define the event model before the agent runtime Design session_id, causation_id, and topic boundaries first so every turn can be reconstructed as an ordered chain of actions.
- Separate live authorization from replay governance Use one policy model for model calls and tool invocations, and a different control layer for schema validation, retention, and consumer access to the commit log.
- Make schema compatibility a release gate Block production event changes unless new versions remain backward compatible with existing consumers and can still be replayed correctly from the broker.
What's in the full article
Kong's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step reference architecture for the sync and async data planes, including how Kong AI Gateway and Kong Event Gateway connect.
- Detailed topic catalog design for agent actions, judgments, audit envelopes, and dead-letter queues.
- Implementation specifics for Kafka partitioning, replication, retention, and replay behaviour.
- Schema registry and AsyncAPI enforcement details for backward-compatible event evolution.
👉 Read Kong's technical blueprint for the agentic commit log architecture →
Agentic commit logs: what Kong’s architecture means for IAM?
Explore further
25/06/2026 11:06 pm
Commit-log governance is becoming the baseline for agentic identity control. Once agents can call models, invoke tools, and emit events across a session, point-in-time access checks stop being enough. The real control surface is the ordered record of decisions, not the model output alone. That is why commit-log design is emerging as an identity governance pattern, not just an infrastructure choice. Practitioners should treat durable session lineage as a control requirement for agentic systems.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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 governance for an agent commit log?
A: Ownership should sit with the team responsible for identity, platform, and security governance together, because the commit log is both an operational substrate and an evidence system. If ownership sits only with application teams, policy drift is likely. If it sits only with infrastructure teams, the identity and audit requirements are easy to miss.
👉 Read our full editorial: Building the agentic commit log for governed AI agent operations
