Why do tool-calling agents create governance problems for security and IAM teams?

Because the model is no longer only producing text. It is making action decisions that resemble delegated access, which means scope, approval, and error handling matter. If the agent can act in business systems, teams need controls for when it may act, what it may touch, and how failures are detected.

Why This Matters for Security Teams

Tool-calling agents change the risk profile because they do not just recommend actions, they can execute them through APIs, workflows, and connected systems. That creates governance questions that resemble delegated privilege, but with less predictability than a human operator. Security teams need to know which actions are allowed, what data can be exposed, and how to stop unsafe behaviour before it becomes a business incident. Guidance from the NIST Cybersecurity Framework 2.0 remains relevant because it anchors governance, risk management, and control ownership, but agentic systems add a new layer of execution uncertainty.

The practical issue is that traditional IAM assumes a stable subject with a clear identity and predictable intent. A tool-calling agent may inherit context from prompts, retrieval, or external connectors, then attempt an action that was never explicitly reviewed by a human. That can blur approval boundaries, undermine segregation of duties, and make audit trails harder to interpret. The governance problem is therefore not only access control, but also decision control, scope control, and recovery control. In practice, many security teams encounter this only after an agent has already touched production data or triggered an unintended workflow, rather than through intentional design.

How It Works in Practice

In a controlled deployment, an agent should be treated as an execution-capable workload with tightly bounded authority. That means the IAM design has to define what identity the agent uses, how tokens are issued, which tools are available, and whether the action requires step-up approval. The NIST AI Risk Management Framework is useful here because it frames AI governance as an ongoing lifecycle problem, not a one-time configuration task.

Security and IAM teams usually need to implement controls across three layers:

• Identity layer: unique workload identity, short-lived credentials, and explicit service ownership.
• Action layer: tool allowlists, scope-limited permissions, and policy checks before execution.
• Oversight layer: logging, review queues, human approval for high-risk actions, and rollback procedures.

This is where agentic AI differs from ordinary automation. A workflow engine follows a fixed path, while an agent may select tools dynamically based on context. That makes policy enforcement closer to runtime authorisation than static role assignment. Current guidance suggests treating high-risk tools, such as payment, identity change, and data export functions, as privileged actions that require stricter approval and monitoring. The OWASP Agentic AI Top 10 is especially useful for identifying failure modes such as excessive agency, tool abuse, and prompt manipulation. These controls tend to break down when tool permissions are broad, token lifetimes are long, and the agent operates across multiple business systems without a unified policy boundary.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance safety against speed and automation value. That tradeoff becomes more visible when agents support customer service, DevOps, or fraud operations, where legitimate actions are frequent and delays are costly. Best practice is evolving, and there is no universal standard for how much autonomy is acceptable in each business process.

One edge case is the agent that only drafts actions for human approval. That may look low risk, but the review burden can still be high if the output is persuasive, incomplete, or based on stale context. Another edge case is multi-agent orchestration, where one agent delegates to another and responsibility becomes harder to assign. Teams should also be cautious where retrieval systems expose sensitive context, because prompt injection, poisoned content, or malformed tool outputs can redirect behaviour in ways that are difficult to spot. For threat modelling, the MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework help teams separate model risk from workflow risk.

For organisations handling regulated data or critical services, the governance model should map agent actions to existing control families, including logging, least privilege, segregation of duties, and incident response. The control challenge is less about whether the agent is “smart” and more about whether its authority is bounded enough to be audited, revoked, and explained.

Related resources from NHI Mgmt Group

• Why do coding agents create new NHI governance problems for IAM teams?
• Why do LLM applications create governance problems for IAM and security teams?
• Why do large language models create governance problems for IAM and security teams?
• How do security teams measure whether shadow-tool governance is working?