Why do AI agents and multi-provider LLM setups create new governance risk?

Why This Matters for Security Teams

AI agents and multi-provider LLM stacks change governance risk because the control problem is no longer just who can log in, but what an autonomous workload can do once it has tool access. Agents can chain prompts, APIs, files, and credentials into actions that traditional IAM was not designed to inspect at runtime. Multi-provider routing adds another layer of uncertainty because data paths, policy enforcement, and logging can diverge across vendors and models.

That creates a gap between intended policy and actual execution. Teams that still rely on static role design often discover that least privilege looks adequate on paper while the agent is already capable of lateral movement, data exfiltration, or unapproved spend. Current guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime controls, not just onboarding checks. NHIMG research on OWASP NHI Top 10 shows why agentic workloads must be treated as active identity and authorization problems, not only model selection problems.

In practice, many security teams encounter the real failure only after an agent has already triggered an unauthorized action through a trusted integration, rather than through intentional security testing.

How It Works in Practice

The governance challenge starts with the identity primitive. For agents, the most useful control is usually workload identity, not a human-style account. That means issuing cryptographic proof for the agent instance or task, then binding that identity to a short-lived session, a narrow policy, and a specific execution context. Static secrets and standing API keys are especially risky here because autonomous systems can reuse them faster and more broadly than a human operator would.

In practice, stronger patterns combine NIST AI Risk Management Framework governance with policy-as-code and runtime enforcement. Security teams are increasingly using gateways or control planes to inspect requests, validate tool use, and apply spend limits across multiple model providers. That helps close the gap created by routing sprawl, where one provider handles classification, another handles generation, and a third handles tool execution. The key is that authorization must happen at request time, with the full context of the task, data sensitivity, tool risk, and current trust state.

• Use short-lived credentials issued per task, then revoke them automatically on completion.
• Separate model access from tool access so a prompt cannot implicitly inherit file, network, or cloud permissions.
• Log every routing decision, model call, and downstream action in one reviewable path.
• Apply content filters and output checks, but do not mistake them for authorization controls.

NHIMG’s coverage of the CoPhish OAuth Token Theft via Copilot Studio and the Replit AI Tool Database Deletion incidents illustrates how quickly tool-enabled agents can turn a governance gap into a live operational event. These controls tend to break down in highly integrated environments where agents can reach multiple SaaS apps, cloud accounts, and internal APIs through pre-existing trust chains.

Common Variations and Edge Cases

Tighter control often increases integration overhead, requiring organisations to balance stronger containment against developer velocity and model flexibility. That tradeoff becomes sharper in multi-provider setups, where one team wants the cheapest or fastest model for each task while another team needs consistent policy enforcement and auditability across the entire workflow.

There is no universal standard for this yet, but current guidance suggests a layered approach. Some teams use a single gateway for routing, inspection, and budget controls. Others separate high-risk tools into a hardened execution tier and keep low-risk generation on a more permissive path. In regulated environments, the deciding factor is usually not model quality alone but whether the provider chain can support traceable data handling, incident response, and policy evidence.

Edge cases matter. A read-only retrieval agent may look safe until it is allowed to summarize sensitive records into a ticketing system. A coding agent may be blocked from production deploys but still able to create malicious pull requests. A multi-agent pipeline may distribute risk so no single step looks dangerous, even though the full chain is. NHIMG’s AI LLM hijack breach and LLMjacking: How Attackers Hijack AI Using Compromised NHIs research show why compromised credentials and weak session boundaries remain the fastest path from model use to governance failure.

That is why the best practice is evolving toward intent-based authorization, ephemeral secrets, and runtime policy checks rather than static role reviews alone.

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 are AI agents creating a new category of secrets risk?
• Why do AI agents create more IAM risk than ordinary developer tools?