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.
At a glance
What this is: Kong frames agentic AI infrastructure as a five-pillar platform problem, with governance, discovery, and runtime control as the decisive gaps.
Why it matters: IAM, NHI, and platform teams need to treat agent identity, tool access, and auditability as first-class controls before agent sprawl outruns governance.
By the numbers:
- As many as 9 out of 10 enterprise organizations are actively adopting AI agents.
👉 Read Kong's framework for building an agentic AI developer platform
Context
Agentic AI is exposing a basic identity governance problem: the enterprise is asking existing infrastructure to manage identities that can select tools, change execution paths, and interact with multiple services in real time. That is a different control problem from traditional API traffic or static workload access, even when the platform uses the same transport layers.
The primary issue is not whether agents can be connected to enterprise systems. It is whether IAM, NHI governance, and audit controls can still define least privilege, traceability, and policy enforcement when the actor is making runtime choices across the stack. The article argues that fragmented tooling and manual processes are already misaligned with that operating model.
Key questions
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. Govern the service catalog, tool descriptors, and policy enforcement point together so discovery, authorisation, and logging are aligned. Without that, agents can chain legitimate calls into behaviour that exceeds the original intent.
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. Agentic systems can change action paths during execution, which breaks that assumption and makes static entitlements less predictive of actual behaviour. The control challenge is therefore runtime governance, not just credential management.
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. Those signals show whether policy is enforced at the request path or only after the fact. If teams cannot reconstruct an agent session end to end, governance is incomplete.
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.
Technical breakdown
Why agentic AI changes the access-control model
Agentic AI differs from ordinary automation because the system is not just executing a script. It is selecting actions at runtime, chaining tool calls, and adapting to intermediate results. That means the identity layer cannot assume a single request maps to a single, predeclared permission. In practice, the platform must understand both the agent's current context and the downstream systems it can discover and call. The result is an identity problem that sits between orchestration, policy enforcement, and observability.
Practical implication: model agent permissions as runtime-bound access paths, not static entitlements.
MCP, discovery, and tool invocation as identity surfaces
The article's emphasis on native MCP support and service discovery shows where identity control shifts from login events to tool-access events. Once an agent can discover APIs, events, databases, and models dynamically, the catalogue becomes part of the trust boundary. Semantic metadata matters because an agent that understands a service can invoke it even if no human has manually stitched the path together. That creates a new governance surface for approval, classification, and downstream logging.
Practical implication: treat service catalog entries and MCP tool descriptors as governed identity surfaces.
Governance for AI traffic needs policy, audit, and cost controls
The Govern pillar bundles policy enforcement, inspection, observability, and cost guardrails because agentic AI creates both security and financial risk through the same runtime path. Prompt and response inspection helps with sensitive data, but the more important architectural point is that the enforcement point sits in front of both model calls and downstream tool calls. That is how enterprises get one control plane for AI traffic rather than scattered checks after the fact. Without that, audit trails and policy outcomes fragment across teams.
Practical implication: centralise enforcement at the request path and log both model and tool activity.
Threat narrative
Attacker objective: The objective is to use agentic access paths to move data, invoke tools, and create business or security impact faster than existing governance can observe.
- Entry occurs when an agent is granted access to enterprise tools, models, and service catalogs through normal platform onboarding rather than a one-off compromise.
- Escalation happens when the agent discovers additional services at runtime and chains tool calls beyond the original intent or human review point.
- Impact follows when the platform cannot constrain sensitive data movement, external model use, or downstream action visibility across the agent's session.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Dynamic tool discovery is the new trust boundary for autonomous access. When agents can query a service catalog at runtime, least privilege is no longer decided only at provisioning. The catalogue, metadata, and invocation policy collectively define what the agent can do, which means governance now extends into service registration and semantic labelling. The practitioner takeaway is that discovery controls must be treated as part of identity control, not as documentation hygiene.
Runtime observability matters because agent behaviour is now an identity event stream. The article's emphasis on logs, policy enforcement, and request-level inspection reflects a broader shift: agent actions need to be observable at the same granularity as access decisions. That is especially true when agents can route through multiple models and tool paths inside one workflow. Practitioners should treat incomplete traceability as a governance failure, not an operational inconvenience.
Agentic AI changes the privilege model from static entitlement to context-bound execution. Traditional IAM assumes the subject and purpose of access remain stable long enough to review. That assumption fails when the actor can change tools, routes, and downstream effects during execution. The implication is not simply to add more controls, but to recognise that the old provisioning-time view of privilege no longer matches the behaviour of autonomous agents.
From our research:
- 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.
- Read NHI Lifecycle Management Guide for the lifecycle controls that matter when agent access, secrets, and offboarding need to stay aligned.
What this signals
Runtime governance will become the differentiator for agent programmes. Teams that can correlate model calls, tool invocation, and policy enforcement in one path will have a usable control plane; everyone else will end up with fragmented logs and delayed incident triage. For deeper context on control design, see NIST AI Risk Management Framework and OWASP Top 10 for Agentic Applications 2026.
Discovery is becoming an identity function. Once agents can find services dynamically, the catalogue itself becomes part of the access model, which means platform teams need approval, metadata quality, and logging discipline at the point of registration. That is why a resource such as OWASP Agentic AI Top 10 matters to teams building internal platforms.
The practical signal for IAM and NHI teams is straightforward: if agent behaviour cannot be tied back to a specific policy decision and a specific runtime path, the programme is already behind the operating model.
For practitioners
- 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.
- Separate discovery from execution approval Allow agents to find available services only through governed catalogs, but require additional controls before any tool can touch production data or external providers.
Key takeaways
- Agentic AI platforms move identity control from provisioning time to runtime, which makes discovery, policy, and audit part of the same governance surface.
- The evidence points to a structural shift, with 9 out of 10 enterprise organisations already adopting AI agents and legacy infrastructure struggling to keep pace.
- Teams should focus on governed discovery, request-path enforcement, and correlated session logging before agent access spreads across production systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent tool use and runtime decisions are central to the platform model. | |
| NIST AI RMF | Governance, audit, and accountability are core to agentic AI risk management. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Least privilege and continuous verification fit dynamic agent access paths. |
Map agent tool access and runtime boundaries to OWASP agentic controls before production rollout.
Key terms
- Agentic AI Developer Platform: A platform architecture that supports building, running, discovering, governing, and monetising AI agents across enterprise systems. It combines runtime routing, service discovery, policy enforcement, and observability so agents can operate as governed workloads rather than isolated experiments.
- Runtime Governance: The enforcement of policy while an identity is actively executing, not after the fact. For AI agents and other non-human identities, runtime governance covers tool access, data handling, logging, and decision control across the full execution path.
- Service Catalog as Trust Boundary: The point where discoverable enterprise services become part of the access control model. When agents can select tools dynamically, the catalogue, metadata, and approval rules define what can be reached and under what conditions.
- Correlated Execution Chain: A joined record of model calls, tool invocations, downstream API requests, and policy outcomes for one agent session. It gives security teams the evidence needed to reconstruct behaviour end to end instead of piecing together separate logs.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.
This post draws on content published by Kong: Building the Agentic AI Developer Platform: A 5-Pillar Framework. Read the original.
Published by the NHIMG editorial team on 2026-01-15.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org