What breaks when AI security teams do not separate model risk, agent risk, and workflow risk?

When those risks are blended together, teams usually miss where the control failed. A model issue, a tool abuse issue, and a workflow permission issue need different fixes. If all three are treated as one category, monitoring becomes noisy, accountability becomes unclear, and remediation can target the wrong layer of the system.

Why This Matters for Security Teams

When model risk, agent risk, and workflow risk are collapsed into one bucket, the investigation starts in the wrong place and the wrong control gets tuned. A model can generate unsafe output, an agent can misuse tools, and a workflow can grant excessive permissions even when the model is behaving correctly. Those are different failure modes, and they create different blast radii. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward separating the system into distinct risk surfaces rather than treating “AI” as a single control domain.

That separation matters because monitoring, policy, and incident response all depend on attribution. If a tool call exfiltrates data, the root cause may be prompt injection, overbroad workflow permissions, or a compromised non-human identity, not a bad model response. NHIMG research shows how quickly agent behaviour can outrun governance, and the AI Agents: The New Attack Surface report highlights that 80% of organisations have already seen agents perform actions beyond intended scope. In practice, many security teams discover the difference only after access, data, or money has already moved through the wrong control layer.

How It Works in Practice

The practical fix is to model the stack in three layers. Model risk covers unsafe generations, hallucinations, prompt injection susceptibility, and data leakage from the model itself. Agent risk covers what the autonomous entity can do with tools, tokens, and delegated authority. Workflow risk covers how orchestration logic, approvals, routing, and human handoffs create permission paths that the model never controls directly. That distinction is essential because a secure model can still drive a dangerous outcome if the agent has broad credentials, and a tightly scoped agent can still cause harm if the workflow silently grants access to the wrong system.

Teams usually need separate controls for each layer:

• Model risk: prompt filtering, output validation, sensitive data handling, and red-teaming.
• Agent risk: short-lived credentials, workload identity, tool allowlists, and runtime policy evaluation.
• Workflow risk: approval gates, segmented permissions, exception logging, and scoped orchestration tokens.

That is why NHIMG’s OWASP NHI Top 10 coverage and incident analyses such as CoPhish OAuth Token Theft via Copilot Studio are so useful: they show that the compromise often sits in the handoff between identity, tools, and task orchestration, not in the model weights. A useful operating model is to ask three separate questions at incident review time: What did the model produce? What was the agent allowed to do? What did the workflow authorize on its behalf? These controls tend to break down when legacy IAM and approval systems are reused for autonomous agents because they were designed for static users, not dynamic goal-seeking execution.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance clearer accountability against faster delivery. That tradeoff is real, especially when teams want one dashboard, one policy set, and one owner for everything labeled “AI.” Best practice is evolving, but current guidance suggests avoiding that simplification for production systems because it hides which layer actually failed.

Edge cases show up when a workflow includes multiple agents, external APIs, or human review steps. In those environments, a single harmful action can be the result of harmless model output plus excessive workflow permissions, or safe tool selection plus an inherited token that was never meant for the task. The CSA MAESTRO agentic AI threat modeling framework is useful here because it pushes teams to trace risk across orchestration, identity, and action boundaries instead of blaming the model by default. For incident response, that means preserving tool logs, workflow state, and token lineage as separate evidence sets.

NHIMG’s Analysis of Claude Code Security and the Replit AI Tool Database Deletion examples both reinforce the same lesson: when autonomous systems act inside production workflows, the failure may be upstream in the model, midstream in the agent, or downstream in the business process. Security teams that separate those layers can contain the blast radius faster and assign remediation to the right control owner.

Related resources from NHI Mgmt Group

• What breaks when security teams track human and AI agent risk separately?
• What breaks when teams treat agent security as only a model problem?
• How should security teams govern AI use when the same model creates different risk in different contexts?
• How should security teams govern model routing in AI agent workflows?