How should security teams implement MCP in multi-step AI workflows?

Why This Matters for Security Teams

MCP changes how AI agents reach tools, but it does not change the underlying security problem: multi-step workflows expand the blast radius of every credential, session, and tool call. If an agent can discover tools, chain actions, and pass context between steps, then a single weak approval path or overbroad tool schema can turn routine automation into privileged misuse. Guidance from the OWASP Agentic AI Top 10 is clear that agentic systems need tighter controls than conventional app integrations.

Security teams often misread MCP as a trust boundary when it is better treated as an orchestration layer. That distinction matters because the same agent that retrieves a harmless record in one step may later invoke a destructive tool in the next step if policy is not re-evaluated at runtime. The risk is amplified in environments that already struggle with secret sprawl and weak rotation, a pattern NHIMG has highlighted in its State of Non-Human Identity Security research. In practice, many security teams encounter MCP abuse only after an agent has already chained through several tools and reached an action that should never have been available in the first place.

How It Works in Practice

Secure MCP implementation starts by putting the protocol behind a controlled gateway that enforces authentication, session isolation, and request-level policy checks. The gateway should expose only the minimum tool surface needed for the workflow, with strict schemas that define allowed inputs, outputs, and side effects. For multi-step work, each step should be authorized separately rather than assuming that an earlier approval carries forward indefinitely.

That model aligns with current guidance from the OWASP Top 10 for Agentic Applications 2026, which emphasises prompt injection resistance, least privilege, and tool abuse controls. It also fits the broader control logic described in NHIMG’s OWASP Agentic Applications Top 10, especially where agents can discover and invoke tools dynamically.

• Bind the agent to a workload identity rather than a long-lived shared secret.
• Issue short-lived credentials per task, and revoke them when the task ends.
• Separate discovery rights from execution rights so tool catalog access does not imply tool use.
• Apply approval gates for sensitive actions such as deletions, money movement, or privilege changes.
• Log the full chain of tool calls, not just the final outcome, so investigators can reconstruct agent intent.

For implementation detail, the operational pattern is to keep MCP sessions ephemeral, tie them to a policy engine, and evaluate every tool call in context. Where possible, the underlying APIs should retain their own authorisation and auditing controls rather than inheriting trust from the agent. These controls tend to break down in highly dynamic workflows with many third-party tools because policy drift and tool chaining make static allowlists too coarse to stay reliable.

Common Variations and Edge Cases

Tighter MCP controls often increase workflow friction and integration overhead, so organisations have to balance developer velocity against blast-radius reduction. That tradeoff becomes most visible when an agent needs to move across systems owned by different teams, because each boundary may have different approval rules, logging requirements, and token lifetimes.

Best practice is evolving for recursive or multi-agent workflows. There is no universal standard for this yet, but current guidance suggests treating each agent as a separate workload identity with its own session, policy scope, and revocation path. Shared sessions between agents are especially risky because they blur accountability and make tool misuse harder to attribute.

In high-trust internal environments, teams sometimes relax controls for low-risk read-only tools. That can be acceptable if the schema is narrow, the data is non-sensitive, and the gateway enforces hard separation between read and write operations. But once an MCP-connected agent can trigger external side effects, the design should revert to explicit approval and step-by-step authorisation. NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs research is a reminder that exposed credentials and over-privileged automation are quickly weaponised, often before defenders notice the misuse.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that run long, multi-step workflows?
• How should security teams implement MCP access to spreadsheet data in AI workflows without exposing regulated records?
• How should security teams govern AI agent identities in MCP workflows?
• How should security teams implement AI evaluation in production workflows?