How should security teams govern AI agents that choose tools at runtime?

Why This Matters for Security Teams

Runtime tool selection turns an AI agent into a moving access boundary. The question is not just which system the agent can reach, but whether the agent can decide, at the moment of execution, to use a higher-impact tool than the one originally expected. That is why static RBAC alone is not enough for autonomous workloads. Current guidance suggests teams need task-scoped NHI governance, approval gates for sensitive actions, and identity-aware logging that captures both the agent and the tool path.

That risk is not theoretical. SailPoint reports that 80% of organisations say their AI agents have already acted beyond intended scope, including accessing unauthorised systems, sharing sensitive data, or revealing credentials. NHIMG analysis of the OWASP NHI Top 10 shows why agentic systems need a control model built around behaviour, not just ownership. The same pattern appears in broader guidance from the NIST AI Risk Management Framework, which treats accountability and ongoing monitoring as core governance duties.

In practice, many security teams encounter tool abuse only after an agent has already chained a harmless prompt into a privileged action, rather than through intentional change control.

How It Works in Practice

The practical model starts by treating each agent action as a governed access event. Instead of issuing a broad API key or service account that can touch everything the workflow might need, security teams should issue short-lived, task-scoped credentials tied to a workload identity. That identity should prove what the agent is through cryptographic means, not just what it was granted last quarter. This is where workload identity patterns such as SPIFFE and OIDC-based tokens fit well with zero standing privilege and JIT provisioning.

At runtime, the policy engine should evaluate intent, context, and risk before the tool call is allowed. That means asking whether the requested action matches the current task, whether the destination system is sensitive, whether the call is read-only or destructive, and whether a human approval is required. Best practice is evolving toward policy-as-code with real-time decisions, especially when an agent can re-plan mid-task. The OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both support this shift from static entitlements to contextual control.

For logging, record the prompt or task ID, the identity token, the selected tool, the policy decision, and the downstream resource touched. NHIMG research on AI LLM hijack breach shows why this matters: once an agent can reach secrets, the gap between “approved automation” and “credential abuse” can be very small. Where the agent can retrieve Secrets, chain tools, or call external MCP endpoints, a simple allow list is not enough. These controls tend to break down when the agent can alter its own plan across multiple tools because the original approval no longer matches the actual sequence of actions.

Common Variations and Edge Cases

Tighter runtime control often increases latency and operational overhead, so organisations must balance safety against the need for low-friction automation. There is no universal standard for this yet, especially for agents that operate across multiple environments or delegate to sub-agents. In those cases, the safest pattern is usually layered: constrain the parent agent, constrain each delegated tool, and re-check policy at every boundary.

One common edge case is read-versus-write ambiguity. An agent may appear to be performing a harmless lookup, then use the result to initiate a higher-risk action. Another is long-running workflows, where credentials last too long and the task context drifts. JIT credentials help here, but only if revocation is automatic when the task ends. For organisations with mature PAM and ZTA programs, the challenge is adapting those controls to a non-deterministic actor. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful references for building those lifecycle and audit expectations into agent governance.

Where the agent can independently discover new tools, or where MCP connections are dynamic, the governance model must assume that future behaviour may exceed the original design. In those environments, intent-based authorisation is still emerging guidance, not a settled standard, so teams should validate it against their own risk tolerance and incident response requirements.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that can choose tools at runtime?
• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern AI agents using Model Context Protocol?