What breaks when tool access and model routing are handled directly inside each agent file?

Why This Matters for Security Teams

Putting tool access and model routing directly inside each agent file turns identity and policy into application code. That makes every agent a separate control plane, so a provider change, credential rotation, or authorization fix has to be repeated everywhere. Security teams lose the ability to apply consistent RBAC, JIT access, or policy-as-code checks across the fleet, and auditability fragments as each file logs differently.

For agentic systems, this is more than a maintainability issue. Autonomous agents can chain tools, retry failed actions, and route through different models based on context, so the security boundary cannot rely on static code paths. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance instead of hard-coded trust decisions. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of gap this pattern widens.

In practice, many security teams discover the problem only after a provider migration, secret leak, or tool misuse has already forced a fleet-wide rewrite.

How It Works in Practice

The safer pattern is to separate agent logic from identity, routing, and authorization. Each agent should request capabilities from a shared control layer at runtime, not define them inline. That control layer can issue short-lived credentials, evaluate policy based on the current task, and record a consistent audit trail regardless of which model or tool is chosen.

Operationally, that means using workload identity for the agent itself, then layering ephemeral secrets and context-aware authorization on top. SPIFFE-style workload identity or OIDC-based federation gives cryptographic proof of what the agent is, while policy engines such as OPA or Cedar decide what it may do at the moment of request. This approach supports JIT access, better TTL enforcement, and cleaner revocation when a task ends. It also reduces the blast radius when one agent is compromised, which aligns with the control intent described in OWASP Non-Human Identity Top 10 and the agent-specific guidance in CSA MAESTRO agentic AI threat modeling framework.

• Keep model routing in a central policy service so provider changes do not require code edits in every agent.
• Issue per-task credentials with strict TTLs, then revoke them automatically when the workflow completes.
• Log tool calls, model selections, and policy decisions in one place to preserve audit integrity.
• Use separate identities for each workload so permissions map to function, not to a static agent file.

This guidance tends to break down when teams embed direct provider SDK calls inside long-running, self-modifying agents because the control plane and execution plane become indistinguishable.

Common Variations and Edge Cases

Tighter central control often increases engineering overhead, requiring organisations to balance governance against developer velocity. That tradeoff is real, especially in experimental agent labs where teams want to prototype quickly. Current guidance suggests that the right answer is not “no local logic,” but “no local trust decisions”: agents may still orchestrate workflows, but the final permission, routing, and secret issuance should live outside the file.

There is no universal standard for agent routing yet, so implementations differ. Some teams place model selection behind a gateway, others use a broker service, and some pair workload identity with policy-as-code in the CI/CD pipeline. The important part is consistency. If one agent routes to a fallback model while another hard-codes a primary provider, audit and incident response become inconsistent. NHIMG’s Analysis of Claude Code Security and the Replit AI Tool Database Deletion case both show how quickly tool-mediated actions can create destructive outcomes when guardrails are scattered.

For teams handling sensitive actions, direct file-level routing is especially risky in multi-agent systems, regulated environments, or environments with third-party tools, because policy drift accumulates faster than reviewers can spot it.

Related resources from NHI Mgmt Group

• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• Why is JIT access important for AI agent management?
• When does an AI agent become a privileged access problem?