AI gateway governance is widening to cover agent tools and runtimes

At a glance

What this is: This is an editorial analysis of how agent adoption is colliding with weak governance, with a focus on AI gateway controls for tool access and runtime execution.

Why it matters: It matters because IAM and security teams now have to govern agent identities, delegated tool use, and approval paths, not just model access or human users.

By the numbers:

• Roughly 30% of respondents say their organizations have integrated AI agents into workflows, up from 13% the prior year.
• About 61% expect AI agents to do half their job within three years.

👉 Read TruFoundry's analysis of BCG's agent governance gap and AI gateway controls

Context

AI agents are software entities that can plan and take actions across tools, which makes their identity problem different from a normal model endpoint or a human user session. The governance gap is no longer just who can call a model, but who or what can delegate, route, and execute tool actions with real credentials.

TruFoundry frames the issue as a split between adoption and control: agent use is spreading faster than the governance structures around it. For IAM, PAM, and NHI teams, that means the security boundary is shifting toward the AI gateway, tool registry, and runtime approval points that govern action, not just inference.

This article is about agent governance rather than a pure product feature review. The useful lesson is that agent risk becomes operational only when tool access and runtime behaviour are observable, scoped, and reviewable.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create governance problems that normal access reviews miss?

A: AI agents can read, copy, transform, and re-share data after the original access decision, so a static review of entitlements does not capture downstream impact. Governance has to measure what the agent actually did with the data, not only whether the agent was allowed to see it. That is why lineage and activity evidence matter.

Q: What breaks when credentials are embedded in agent configurations?

A: Embedded credentials break point-of-use governance. The secret can be invoked repeatedly, passed downstream into other tools, and remain active long after the original workflow changes. That makes revocation slower, audit trails weaker, and access reviews less meaningful because the control is attached to storage, not actual use.

Q: How should organisations decide when to widen an agent's access?

A: They should widen access only after the team has reviewed traces, approvals, and actual outcomes for the current scope. Expansion should be based on evidence that the agent stayed within bounds and produced reliable work, not on enthusiasm for the use case. That keeps authority growth tied to observed behaviour.

Technical breakdown

Why agent identity governance has to cover tool calls

An AI agent is not just a model response generator. It is a loop that decides when to act, chooses a tool, sends the request, interprets the result, and may continue without fresh human input. That changes the identity question from authenticating a caller to governing a delegated executor. In practice, tool access becomes the control point: who authorised the agent, which systems it may reach, and whether the call is attributable to a person, service, or policy scope. Without that mapping, tool use becomes opaque even if the model itself is centrally hosted.

Practical implication: Treat agent tool access as governed delegated identity, not as incidental application traffic.

What a managed agent runtime changes

A managed runtime adds execution controls around the agent loop itself. Instead of credentials living inside prompts or agent definitions, the runtime can hold them centrally, apply sandboxing, gate sensitive actions, and produce traces of each step. That matters because the risk is not only what the agent knows, but what it can do between one decision and the next. Runtime design determines whether an agent is merely assisted automation or a governed operating unit with bounded authority and observable behaviour.

Practical implication: Use runtime controls to keep credentials, approvals, and execution logs outside the agent definition.

How gateway policy turns delegation into auditable access

Gateway-mediated access can combine OAuth-based delegation, RBAC, metadata policy, and request tracing so that each tool call is tied to an access decision. That is the difference between a loose integration and an identity control plane. For NHI and IAM teams, the key architectural point is that the gateway can enforce least privilege at the point of action, not only at provisioning time. This is especially important when agents operate across multiple systems and the business expects them to chain tasks.

Practical implication: Map every agent tool path to an enforceable policy and an audit trail before expanding its scope.

NHI Mgmt Group analysis

Agent governance is now an identity problem, not just an AI ops problem. Once an agent can act across tools, the relevant control surface becomes delegation, not output quality. That shifts responsibility toward IAM, PAM, and NHI governance because the agent must be constrained as an executable identity. The practical conclusion is that teams need one governance model for humans, service accounts, and agents when those identities can all initiate work.

Tool-level policy is the new minimum viable control for agents. An agent that can call tools without registered scope, per-user attribution, and policy enforcement behaves like an ungoverned service account with a conversation layer on top. That is why gateway-mediated control matters: it gives security teams a place to apply authorization, routing, and audit before the action reaches the target system. Practitioners should treat every tool path as a governed privilege.

Trusted-core expansion is the right operating principle for agent rollout. The field keeps trying to solve agent risk by adding more model-side safety, but the operational issue is authority creep. Start with a narrow set of sanctioned tools and a bounded runtime, then expand only as traces, approvals, and outcomes prove the agent can stay within scope. That is the only scalable way to prevent agent sprawl from becoming privilege sprawl.

Runtime observability is becoming the dividing line between oversight and blind trust. If a team cannot inspect per-step execution, it cannot tell whether the agent accessed the right system, used the right data, or crossed an approval boundary. That makes auditability a governance requirement, not a nice-to-have. The implication for practitioners is straightforward: if the execution path is not legible, the agent should not be widened.

Dynamic tool selection creates a runtime privilege window that static IAM was not built to cover. Traditional provisioning assumes access can be reviewed after assignment. Agents can request, combine, and discard access within a single workflow, which means the security question moves to moment-of-action governance. Teams should re-evaluate whether current approval and certification cycles are fast enough to govern that behaviour.

From our research:

• 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, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% say governing them is critical to enterprise security.
• For a deeper control view, see OWASP NHI Top 10 and NIST AI Risk Management Framework.

What this signals

Agent governance will increasingly converge on the AI gateway, because that is where identity, delegation, and auditability can be enforced together. If tool calls stay scattered across prompts, connectors, and runtime code, the programme will never get a complete access picture. Teams should expect governance reviews to start asking for traceable tool registries, approval paths, and a named owner for each agent identity.

Tool-level delegation creates an identity blast radius that IAM teams need to measure explicitly. Once an agent can chain tool calls, the practical risk is not just unauthorised access but unauthorised sequence. That means review cycles, approval thresholds, and least-privilege boundaries all need to be judged against execution speed, not just assigned entitlements.

Runtime traceability is the new control evidence for agent programmes. Traces, approvals, and outcome logs become the artefacts that show whether the agent remained inside policy. Organisations that cannot produce those artefacts will struggle to justify broader deployment, especially in regulated or high-impact workflows.

For practitioners

• Define agent identities explicitly Create a separate identity class for agents, then map each one to an owner, purpose, tool scope, and expiry condition before production use.
• Centralise tool authentication at the gateway Keep credentials out of prompts and agent definitions, and force all external tool calls through a gateway that handles delegation, policy, and logging.
• Bind every agent to a trusted tool registry Allow agents to call only registered tools and approved servers, then review registry changes as access-control changes rather than as feature updates.
• Require step-level traces and approval gates Capture per-step execution logs, cost, and tool choices, and pause high-impact actions for human approval before the agent can continue.
• Expand authority only after outcome review Use observed execution, not model confidence, to decide whether an agent can be given broader data access or additional tools.

Key takeaways

• AI agents change identity governance because they act as delegated executors, not just model callers.
• Governance is falling behind adoption, and the visible gap is tool access, runtime control, and auditability.
• The practical response is to centralise delegation, bound the runtime, and expand authority only after measured evidence.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Tool Delegation Trust: The assumption that an agent may safely call external tools or services once the model appears authorised. This is a governance failure if the delegation boundary is not explicitly scoped, monitored, and revocable.
• Managed Agent: A managed agent is a software identity that performs tasks on behalf of an organisation and must be governed like any other non-human identity. In practice, it needs an owner, a defined access scope, and reviewable entitlements so its actions can be traced and controlled.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

TruFoundry's full article covers the operational detail this post intentionally leaves for the source:

• Documented control mappings for the AI Gateway and Agent Harness, including how each surface governs a different part of the agent workflow
• The full section-by-section comparison between BCG's survey findings and the runtime controls TruFoundry uses to interpret them
• Implementation detail on sandboxing, approval gates, and per-step tracing for managed agent execution
• The article's cited documentation references for MCP Gateway policy, delegation, and Skills Registry controls

👉 TruFoundry's full article covers the MCP Gateway, Agent Harness, and execution governance in more detail.

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 building or maturing identity security across human and non-human estates, it is worth exploring.