AI gateway governance is widening to cover agent tools and runtimes

At a glance

What this is: This analysis argues that AI gateway governance has to expand beyond model traffic to cover agent tool calls and runtimes, because agents act, chain tools, and carry credentials.

Why it matters: For IAM, IGA, PAM, and NHI teams, the implication is that governance must shift from prompt oversight to delegated action control, approval gates, and runtime traceability.

By the numbers:

• around 30% of respondents say their organizations have integrated AI agents into workflows
• about 61% expect agents to handle half their job within three years

Context

AI gateway governance is the control layer that routes, authorises, traces, and constrains AI traffic before it reaches models, tools, or runtimes. In this article, TruFoundry argues that once agents enter the picture, governance has to extend beyond model requests to the tool calls and execution loops that agents use to act.

That matters because agent behaviour is not the same as chat behaviour. An agent can plan, call tools, observe results, and continue, which means access control, approval, delegation, and audit all need to follow the action path rather than only the prompt path. The article frames this as an operating-model problem as much as a technical one.

The source uses BCG’s 2026 AI-at-work findings as the trigger, then maps them to AI gateway controls and a managed runtime. The practical question for identity teams is whether their current governance model can see who or what authorised a tool call, how credentials were handled, and where runtime approvals belong.

Key questions

Q: What breaks when an AI agent is allowed to call tools without strict scope controls?

A: The main failure is privilege expansion. A model can only act safely if every tool it can call is constrained by explicit scope, server-side validation, and audit logging. Without those controls, the agent can read files, trigger actions, or expose data far beyond what the user intended, turning a helpful assistant into an uncontrolled access path.

Q: Why do SaaS AI agents create more governance risk than traditional chatbots in enterprise environments?

A: SaaS AI agents can operate across live systems and inherit broad access from existing users, features, or auto-configured modules. That makes them more likely to expose sensitive data, bypass intended handling rules, and surface regulated content. The risk is not the interface itself, but the combination of inherited access, weak labeling, and direct connection to core enterprise data.

Q: How do security teams know if agent governance is actually working?

A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.

Q: Should organisations treat agent runtimes as part of identity governance?

A: Yes. Once the runtime decides when an agent executes, pauses, or resumes, it becomes part of delegated access control. Identity governance has to extend to the loop that carries the action, because the runtime is where authority is actually exercised.

Technical breakdown

Why agent tool calls need separate governance from model prompts

A model prompt is an instruction to generate text, but an agent tool call is a delegated action against an external system. That difference matters because the risk boundary moves from content to control. In a governed agent stack, tool access should be mediated separately from model access so that authorization, delegation, and traceability follow the action, not just the conversation. The article describes this as the role of an MCP Gateway, where tools are registered, credentials are injected centrally, and calls can be tagged to a user or workflow. Without that separation, credentials end up embedded in agent definitions or spread across scripts, making revocation and audit materially harder.

Practical implication: Treat tool access as its own control plane and enforce per-tool authorization before an agent can reach production systems.

How a managed agent runtime changes credential and approval handling

The runtime is where the agent loop executes, which makes it the right place to handle orchestration, sandboxing, approvals, and step-level tracing. The article’s Agent Harness model keeps credentials out of agent definitions and routes model, tool, and skills references through governed services instead. That design reduces the chance that a runtime will become a loose bundle of hard-coded secrets and unreviewed action paths. It also makes human approval gates practical for selected sensitive actions, because the system can pause a specific step rather than trying to supervise an entire conversational session after the fact.

Practical implication: Place approvals and execution controls in the runtime so sensitive actions can be stopped at the step where they occur.

What observable execution adds to AI gateway governance

Observable execution means the system can show which tools were called, what each step produced, and how much the run consumed. That does not expose private reasoning, but it does create an audit path that is useful for governance, investigation, and workflow tuning. For identity teams, this is important because delegated access without traceability becomes difficult to certify or revoke with confidence. The article argues that one-pane observability across model, tool, and agent traffic is the practical basis for expanding agent authority over time. In governance terms, traceability is not a reporting feature; it is the evidence layer for delegated action.

Practical implication: Require per-step traces for any agent that can reach business systems or trigger sensitive downstream actions.

Threat narrative

Attacker objective: The objective is to turn delegated agent access into unauthorized or ungoverned action across real systems.

1. Entry occurs when an agent is allowed to use a tool or runtime with delegated access, rather than remaining limited to model output.
2. Credential exposure or misuse follows when credentials are embedded in definitions, passed too broadly, or reused across registered tools and workflows.
3. Escalation happens when the agent chains tool calls inside a runtime that can continue executing without sufficient approval or scoping.
4. Impact is misrouted action, unauthorized system changes, or exposed operational data through agent-driven execution paths.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI gateway governance is now an access-control problem, not just a model-routing problem. Once agents can call tools and act inside a runtime, the security question shifts from what the model said to what the system was allowed to do. That is why model-centric controls are insufficient on their own. Practitioners should treat delegated action as a distinct governance surface, not a side effect of chat.

The old assumption that credentials can be supervised at provisioning time breaks under agentic execution. That assumption was designed for stable, reviewable access held by a human or a long-lived service account. It fails when the actor acquires and releases credentials as part of a task loop and uses them across multiple tools in one run. The implication is that governance has to move toward issuance-time control and step-level evidence.

Tool registries and runtime harnesses are becoming the practical boundary of agent identity governance. A registry constrains what an agent may touch, while a harness governs how the loop executes and when it pauses for approval. Together they represent a shift from identity as a static subject to identity as a managed action path. Practitioners should re-evaluate where authorization actually occurs in their agent stack.

Observable execution is becoming the minimum viable proof of control for agents. If an organisation cannot show which tool an agent called, what it changed, and which step required approval, it cannot credibly govern that agent at scale. The important question is not whether the platform can log activity, but whether those logs are structured enough to support delegation review, incident analysis, and lifecycle decisions.

Runtime governance gap: the real failure mode is not that agents exist, but that they are allowed to act before their tool access, approvals, and traces are bound to a governed runtime. That gap widens quickly when adoption grows faster than policy design. Practitioners should read this as a sign that agent governance is maturing from experimentation into control architecture.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime governance gap: the governance problem is no longer whether organisations allow AI agents at all, but whether they can constrain tool calls, approvals, and traces inside the execution loop. When agents can act across systems, the control surface has to follow the loop rather than stop at the model.

Agent governance will increasingly converge with identity governance because delegated action depends on registered tools, scoped credentials, and evidence of who authorised what. That convergence is where IAM, PAM, and NHI teams can add the most value: by making agent authority reviewable instead of implicit.

For practitioners

• Define separate controls for model access and tool access Map which permissions belong to the model layer, which belong to MCP tool calls, and which must never be embedded in agent definitions.
• Move sensitive actions behind runtime approval gates Require explicit human authorization for high-impact steps such as external writes, deletions, payments, or policy changes before the agent can continue.
• Require per-step traces for every governed agent Capture tool name, execution step, decision point, and outcome so investigators can reconstruct the run without relying on prompts alone.
• Register approved tools before an agent can use them Limit agent access to a governed tool registry so new tools are added through review instead of opportunistic connection from the runtime.

Key takeaways

• Agents change the control problem from prompt supervision to delegated action governance across tools and runtimes.
• If tool access and runtime approvals are not separated, an agent can turn a small logic error into a real system change.
• The strongest governance signal is observable execution, meaning teams can reconstruct what the agent did, which tool it used, and who approved it.

Key terms

• Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.
• Tool Governance: Tool governance is the control of the APIs, service accounts, connectors, and permissions an agent uses to reach other systems. It focuses on the delegated paths that convert agent intent into action, because those paths often hold the real security risk and the broadest privilege exposure.
• Observable Execution: The ability to reconstruct what an agent did step by step, including which tool it called, what each step produced, and who approved sensitive actions. This is the evidence layer for governing delegated action and is essential for audit, investigation, and safe scale.
• Delegated action: An action performed by one identity on behalf of another, with some authority borrowed from the principal. In agentic environments, delegated action needs explicit scope, auditability, and revocation boundaries because the executor is not the same as the beneficiary.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.