Treat the full workflow as one identity problem, not two separate control problems. The same agent should have a stable principal, a shared policy model, and one correlated audit trail across both gateways. If model governance and tool governance cannot be joined without manual reconciliation, the control plane is incomplete.
Why This Matters for Security Teams
Agents that can both call models and invoke tools collapse two traditionally separate trust boundaries into one workflow. That changes the control question from “is the prompt safe?” to “is this principal allowed to think, decide, and act right now?” Static IAM and separate governance reviews often miss the handoff point where a model output becomes an authenticated tool action. NHI Mgmt Group’s Ultimate Guide to NHIs shows how widespread identity control gaps already are, including the fact that only 5.7% of organisations have full visibility into their service accounts.
The practical risk is not limited to credential leakage. An agent can chain model reasoning, memory, and tool execution in ways that create privilege escalation, lateral movement, or data exfiltration without ever looking like a conventional user session. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance, not just pre-approval. In practice, many security teams encounter the model-to-tool abuse path only after a production incident forces them to reconcile two logs that were never designed to match.
How It Works in Practice
The safest pattern is to govern the agent as a single principal with one identity, one policy decision point, and one audit trail. The model call and the tool call should both inherit the same session context, task scope, and risk controls. That means the model is not a separate “brain” outside security review; it is part of the execution chain that produces an action.
At implementation time, teams should combine workload identity, short-lived credentials, and runtime policy evaluation. For example, the agent can authenticate with a workload identity rather than a shared secret, then receive just-in-time tool permissions only for the specific task it is currently executing. The policy engine should inspect context such as task intent, tool sensitivity, data classification, and recent agent behaviour before allowing the call. This is consistent with the direction of the CSA MAESTRO agentic AI threat modeling framework and with operational lessons from the Analysis of Claude Code Security.
- Use a stable agent principal so model actions and tool actions map to the same identity.
- Issue ephemeral, task-bound tokens instead of long-lived API keys.
- Evaluate policy at request time, not only at onboarding or deployment.
- Correlate prompt, decision, and tool telemetry into one reviewable trail.
- Separate high-risk tools behind step-up checks or human approval where needed.
The goal is not to block every autonomous action. It is to make each action attributable, bounded, and revocable. That becomes especially important when agents can invoke external systems, create follow-on tasks, or reuse retrieved context in ways the original designer did not anticipate. These controls tend to break down in loosely coupled microservice environments because identity context is often lost between the model gateway, orchestration layer, and downstream tool API.
Common Variations and Edge Cases
Tighter cross-domain control often increases latency and operational overhead, so organisations have to balance autonomy against assurance. Best practice is evolving on how much context should follow the agent across all calls, and there is no universal standard for this yet. Some teams use a single policy engine for both model and tool requests, while others keep a shared policy model but split enforcement across gateways.
The edge cases usually appear when agents operate across trust zones, vendor boundaries, or delegated accounts. A tool may accept a valid token but still be unsafe because the model recently generated a risky plan. Conversely, a model may be harmless while the downstream tool is highly privileged. That is why runtime risk scoring matters more than static role mapping. Current guidance suggests the most resilient design uses one correlated identity and one decision record, even if the enforcement points are technically separate. For a broader NHI baseline, the Ultimate Guide to NHIs remains the best starting point, while the OWASP Top 10 for Agentic Applications 2026 is useful for modelling prompt injection, tool misuse, and privilege escalation together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic abuse spans model and tool calls, matching agent risk controls. |
| CSA MAESTRO | MT.4 | MAESTRO addresses threat modeling for autonomous agent workflows and tool use. |
| NIST AI RMF | GOVERN | AI RMF governance fits accountability, oversight, and lifecycle controls for agents. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Shared identities and weak secret handling are core NHI failure modes for agents. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is central when agents can call tools directly. |
Use one workload identity per agent and replace static secrets with short-lived credentials.
