Why do direct model to tool connections create governance and security risk as AI agents scale?

Why This Matters for Security Teams

Direct model-to-tool wiring turns each agent into a distributed access path, not just a chat interface. That matters because the agent is not following a fixed human workflow; it is selecting tools, chaining actions, and expanding scope at runtime. In that environment, static RBAC and hard-coded API keys age badly. The problem is not only over-privilege, but also the loss of a reliable control plane for approvals, logging, and revocation.

As tool counts rise, security teams often discover that access logic has drifted into prompts, application code, or ad hoc configuration, which makes governance brittle and inconsistent. Best practice is evolving toward workload identity, short-lived credentials, and policy decisions made at request time, rather than trusting pre-approved connectivity. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward runtime governance, not static trust. NHIMG’s OWASP NHI Top 10 also frames identity sprawl as a central risk when machine identities are left to accumulate. In practice, many security teams encounter tool misuse only after an agent has already touched production data, rather than through intentional access review.

How It Works in Practice

The safer pattern is to treat the agent as a workload with a verifiable identity, then issue access only for the task being executed. That usually means short-lived tokens, task-scoped permissions, and a central policy engine that evaluates context before each tool call. A direct connection from model to tool should be the exception, not the default, because it bypasses the controls that make revocation and auditing workable.

Operationally, teams are converging on a few practices:

• Use workload identity, such as SPIFFE or OIDC-backed service identity, so the system can prove what the agent is without embedding long-lived secrets in prompts or code.
• Issue just-in-time credentials with tight TTLs and automatic revocation when the task ends.
• Evaluate policy at request time with policy-as-code, using context such as tool purpose, environment, data sensitivity, and step-up approval state.
• Separate discovery from execution so the agent can propose an action without automatically gaining the authority to perform it.

This approach aligns with the control direction in the CSA MAESTRO agentic AI threat modeling framework and the NIST Cybersecurity Framework 2.0, both of which favor managed access, visibility, and continuous control validation. It also reflects NHIMG research on CoPhish OAuth Token Theft via Copilot Studio and Replit AI Tool Database Deletion, where tool-level trust and weak guardrails produced outsized impact. These controls tend to break down when agents are allowed to call production systems directly from loosely governed orchestration layers because the runtime no longer has a single enforcement point.

Common Variations and Edge Cases

Tighter control often increases integration overhead, requiring organisations to balance autonomy against operational friction. That tradeoff is real, especially in fast-moving environments where teams want agents to help with support, engineering, or workflow automation without slowing delivery.

There is no universal standard for this yet, so current guidance suggests matching control strength to the agent’s blast radius. Low-risk retrieval tasks may tolerate broader read access, while actions that modify records, send messages, or execute code should require stronger runtime checks, step-up approval, or human confirmation. The hard cases are multi-agent systems and toolchains that span SaaS, internal APIs, and data platforms. In those environments, access can fragment quickly unless every hop inherits a common identity and policy layer.

Security teams should also watch for hidden exceptions: emergency admin tokens, developer bypasses, and long-lived integration secrets created “just for testing” that later become production dependencies. NHIMG’s Ultimate Guide to NHIs — 2025 Outlook and Predictions and the Analysis of Claude Code Security both reinforce the same lesson: once machine access is scattered across prompts, code, and connectors, revocation becomes slow and incomplete. Current guidance suggests centralising identity, shortening secret lifetimes, and enforcing policy at the moment of tool use, not at design time.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?
• How should security teams limit the risk from AI agents that have access to production systems?