Requests split across separate logs, budgets, and policy checks, which makes it hard to reconstruct a full workflow or stop repeated risky actions. An agent may call a model, fetch sensitive data, update a system, and trigger another action without one consistent identity or audit trail. The result is weaker incident response, poorer compliance evidence, and less effective spend control.
Why Split Agent Workflows Become Hard to Govern
When an agent can bounce between model calls and MCP tool calls, each step often lands in a different control plane. That split breaks the simple security story teams rely on, because the request, the decision, the tool execution, and the resulting side effect are no longer evaluated as one workflow. The practical outcome is fragmented accountability, inconsistent policy enforcement, and weak replayability when something goes wrong.
In that setting, the question is not just what the agent did, but whether any system can still prove how the action chain unfolded. If a model call influences a tool call that then influences another model call, the governance problem is the missing correlation across those transitions, not the tool call by itself.
Teams usually feel this first as an evidence problem. Logs may exist, but they are split across systems, timestamps, tenants, budgets, and policy engines, so the full path is hard to reconstruct without manual correlation.
What Breaks When Identity, Budget, and Policy Are Not Shared
The largest gap is that each hop can be treated as a separate event instead of one governed workflow. That makes it easier for an agent to repeat a risky action, exceed a spend threshold in pieces, or keep operating after one stage should have been stopped. AI Agent Observability, Audit and Incident Response Guide is useful here because the core challenge is attribution across the whole sequence, not just visibility into a single call.
Unified governance also matters for authorization. If one part of the workflow is checked against one policy and another part against a different policy, the system can accidentally permit a chain of actions no single reviewer intended. That is especially dangerous when one step reads sensitive data and a later step writes to production, because the blast radius is determined by the full chain, not the individual action.
This is also why agent identity design cannot be an afterthought. Without a consistent identity model, the workflow becomes difficult to bind to a principal, difficult to scope, and difficult to revoke cleanly when the agent should stop. Agentic AI Identity Guide and AI Agent Authorisation Guide both support the same operational point: identity and action scope need to travel with the workflow, not reset at every boundary.
How to Govern Cross-Model and MCP Sequences Without Blind Spots
Good governance starts by treating the workflow as one security object, even if it is implemented across multiple services. That means one correlation identifier, one policy story, and one audit trail that can tie model reasoning, tool invocation, and downstream side effects together.
MCP introduces an additional boundary because tool access is often mediated by authorization and token handling. If token usage, resource access, and server trust are managed separately from the agent workflow, you can end up with a technically valid call chain that is still operationally unsafe. MCP Security Guide is the right companion reference for the protocol side, while MCP authorization specification captures the need for bounded tokens and proper resource-server behavior.
For practitioners, the governance question is whether each action is evaluated against the same principal, the same permission scope, and the same stop condition. If not, the workflow can drift into a state where one component thinks the request is ordinary while another component sees only a benign sub-step, even though the end-to-end effect is sensitive.
Risk and Threat Considerations
Fragmented governance creates a real abuse path, because attackers and misconfigured agents benefit from every gap between logs, policies, and identities. A workflow that can fetch data, transform it, and then trigger a second action without one consistent control path is easier to misuse, harder to interrupt, and more likely to leave incomplete evidence after compromise.
Failure mechanism: The workflow is split into isolated checks, so no single system sees the full sequence of actions or can reliably stop repeated or chained abuse.
Impact: Incident responders lose the ability to reconstruct intent and effect, compliance teams lose defensible evidence, and finance or security teams may miss repeated spend or repeated harmful action until after the blast radius grows.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Covers agent workflows where identity and privilege must persist across model and tool actions. |
| Recommendation — Enforce per-action authorization and bound each agent step to the same principal and policy context. | ||
| CSA MAESTRO | UNKNOWN — Multi-Agent Environment, Security, Threat, Risk and Outcome | Applies to orchestration risk when multi-step agent workflows cross trust and tool boundaries. |
| Recommendation — Model the end-to-end workflow, then add controls for each trust boundary and downstream action. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Relevant when agent workflows use credentials that outlive or exceed the workflow's actual need. |
| Recommendation — Reduce standing privilege and scope credentials to the smallest workflow-specific permission set. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Audit records must capture enough context to reconstruct chained model and tool actions. |
| AC-6 — Least Privilege | Cross-tool workflows need tightly limited permissions to prevent chain amplification. | |
| Recommendation — Log each workflow step with principal, decision, target, and outcome details. Limit each workflow component to the minimum permissions needed for its step. | ||
Practitioner Guidance
What to prioritise: Bind model calls and MCP tool calls to a single workflow identity and a single audit record before you try to optimise prompts, routing, or tool selection. If the workflow cannot be replayed from logs, it is not governed well enough to trust.
What to verify: Check that one control plane can answer three questions consistently: who initiated the workflow, which policy approved each step, and what side effect each tool call produced. If those answers require manual stitching across unrelated logs, the control design is too weak for reliable operations.
Practitioner takeaway: The core problem is not that the agent uses multiple systems, it is that control breaks when those systems no longer agree on identity, authorization, and audit context.
Related resources from NHI Mgmt Group
- How should security teams govern AI connectivity when LLM APIs, MCP tool calls, and agent-to-agent workflows all touch sensitive data?
- What happens when enterprises scale multi-agent systems without guardrails and model governance?
- What happens when application access governance is attempted without unified workflows and automation?
- What happens when a hijacked agent is allowed to make tool calls without intent checks?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
