Should organisations treat tool-calling agents as part of identity governance?

Why This Matters for Security Teams

Tool-calling agents are not just software assistants when they can read records, submit tickets, provision access, or trigger workflows in production systems. At that point, the question is no longer whether they are “users” in a human sense, but whether their execution path is governed with the same discipline applied to NIST Cybersecurity Framework 2.0 and related identity controls. If an agent can act, it can also be abused, misdirected, over-scoped, or left active after the business need has changed.

The practical risk is that many organisations deploy agents through integration teams or product owners, while identity governance remains focused on employees, contractors, and service accounts. That gap creates shadow privilege, unclear ownership, and weak revocation. The presence of an LLM does not reduce the need for control. It increases the need to define what actions are permitted, under what context, and with what monitoring. Guidance from the NIST AI Risk Management Framework reinforces that AI systems require lifecycle governance, not just point-in-time approval. In practice, many security teams encounter agent overreach only after an automated action has already changed data, sent messages, or expanded access, rather than through intentional governance.

How It Works in Practice

Tool-calling agents should be treated as governed non-human identities when they have direct execution authority. That means assigning a named owner, recording the business purpose, defining scoped entitlements, and deciding whether the agent is read-only, approve-only, or action-capable. The identity model should be built around the tools the agent can invoke, not around the model itself. For example, a support agent that can open tickets may need different controls from a procurement agent that can approve purchase requests.

In practice, the control set usually includes:

• Distinct credentials or workload identity for the agent, never shared across environments.
• Least privilege for each tool, API, and queue the agent can reach.
• Human review for high-impact actions such as access grants, payments, or production changes.
• Logging that preserves prompts, tool calls, approvals, and outputs for audit and investigation.
• Periodic access recertification with a clear revocation path when the workflow changes.

Security teams should also test for prompt injection, tool abuse, and unsafe chaining of actions. The OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix are useful references for mapping how an agent can be manipulated before, during, or after tool execution. Where an agent can chain actions across multiple systems, governance should extend to the full path of impact, not just the first approved tool call. These controls tend to break down when agents inherit broad service credentials in shared automation platforms because ownership, monitoring, and revocation all become ambiguous.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance automation speed against control depth. That tradeoff is real, especially when teams want agents to move quickly in customer support, engineering, or SecOps workflows. Best practice is evolving, but current guidance suggests that the more consequential the action, the stronger the identity guardrails should be.

Not every tool-calling agent needs the same treatment. A low-risk summarisation agent with no external side effects may sit closer to content governance, while an agent that creates vendors, resets passwords, or deploys code should be handled much more like a privileged automation identity. There is no universal standard for this yet, so classification should be based on impact, not on whether the system is branded as “AI” or “automation.” The CSA MAESTRO agentic AI threat modeling framework is helpful where teams need to reason about autonomy, tool scope, and oversight boundaries.

For regulated environments, identity governance should also reflect auditability and change control. If an agent can affect financial records, personal data, or security settings, the approval trail should be as explicit as it would be for a privileged human operator. Where organisations cannot explain who owns the agent, what it can touch, and how it is revoked, the safest assumption is that governance is incomplete. The edge case that causes the most trouble is the “temporary” agent that becomes permanent after the workflow proves useful, but never receives a formal entitlement review or retirement decision.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• Should organisations treat browser extensions as part of identity governance?
• When should organisations treat agent intent as part of identity governance?
• Should organisations treat semantic governance as part of identity governance?