TL;DR: Enterprises need a five-pillar agentic AI developer platform covering build, run, discover, govern, and monetise, because agents are now making runtime decisions across many services, according to Kong. The governance gap is structural: existing IAM and NHI controls were designed for bounded access patterns, not for agents that change context and invoke tools in flight.
NHIMG editorial — based on content published by Kong: Building the Agentic AI Developer Platform: A 5-Pillar Framework
By the numbers:
- As many as 9 out of 10 enterprise organizations are actively adopting AI agents.
Questions worth separating out
Q: How should security teams govern AI agents that can call enterprise tools in real time?
A: Treat the agent as a runtime identity with bounded access paths, not a static application.
Q: Why do AI agents complicate existing IAM and NHI controls?
A: Existing IAM and NHI controls assume access is defined at provisioning time and reviewed later.
Q: What should teams measure to know whether agent governance is working?
A: Track policy violation rate, cross-service discovery usage, and how much of agent activity is logged as one correlated execution chain.
Practitioner guidance
- Map agent tools to explicit trust boundaries Inventory every MCP endpoint, API, event stream, database, and model an agent can reach, then classify which ones are internal, external, or sensitive before allowing runtime discovery.
- Enforce policy at the AI request path Apply a shared control plane that inspects prompts, model responses, and downstream tool calls so policy decisions happen before data leaves the approved flow.
- Require session-level audit trails for agent actions Log model selection, tool selection, and downstream API invocation as one correlated chain so investigators can reconstruct what the agent did without stitching together separate systems.
What's in the full article
Kong's full blog post covers the operational detail this post intentionally leaves for the source:
- The five-pillar platform framework with concrete examples of Build, Run, Discover, Govern, and Monetize in practice
- Metrics for development cycle time, discovery-to-integration time, policy violation rate, and cost attribution coverage
- Architecture examples showing how agent routing, semantic caching, and request-path enforcement work together
- Specific operational scenarios for local testing, catalog registration, and gateway-based policy enforcement
👉 Read Kong's framework for building an agentic AI developer platform →
Agentic AI developer platforms: what IAM teams still have to govern?
Explore further
Agentic AI developer platforms are now an identity governance problem, not just an architecture pattern. The article is right to frame build, run, discover, govern, and monetise as one platform, because agent identity only becomes manageable when those layers are linked. Separate point tools create inconsistent policy enforcement and blind spots across discovery, runtime, and audit. Practitioners should read this as a warning that platform design now determines whether governance is enforceable at all.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which shows how quickly governance assumptions break down at the implementation layer.
A question worth separating out:
Q: Who should own governance for agentic AI platforms?
A: Ownership should sit jointly with IAM, platform security, and application platform teams, because the control surface spans identity, runtime routing, and service discovery. If any one group owns it alone, the result is usually fragmented policy and inconsistent auditability across the agent lifecycle.
👉 Read our full editorial: Building an agentic AI developer platform still leaves identity gaps