Why do MCP-based agent workflows create audit and authorisation gaps?

Because the tool often sees the agent, not the human who triggered the action. Without propagated identity, logs cannot answer who asked for the action, who approved it, or whether the caller was entitled to it. That weakens least privilege, complicates investigations, and pushes teams toward broad access patterns that are hard to govern.

Why This Matters for Security Teams

MCP changes the control plane for agent workflows: the model can request tools, chain actions, and move across systems faster than a human reviewer can meaningfully inspect each step. That creates a governance gap when authorisation is still anchored to a static user session or a broad service account. Security teams then lose the ability to answer basic questions about intent, approval, and entitlement.

This is not a theoretical nuisance. In the State of MCP Server Security 2025, AI Agents: The New Attack Surface report also shows how quickly agent behaviour outruns existing controls, with many organisations already reporting actions beyond intended scope. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points to the same issue: the risk is not just the tool, but the lack of identity propagation and runtime decisioning around the tool call.

In practice, many security teams encounter the audit failure only after an agent has already touched sensitive data or executed an unauthorised tool path, rather than through intentional control testing.

How It Works in Practice

In a well-governed MCP workflow, the agent should not be treated as if it were a human user with a fixed role. The better pattern is to bind each request to a workload identity, then evaluate authorisation at runtime using the actual task, data sensitivity, and tool being invoked. That is why workload identity concepts such as SPIFFE/SPIRE or OIDC-backed service identities matter: they prove what the agent is, while propagated context helps show who initiated the action and under what policy.

Operationally, this usually means three layers working together. First, the human trigger is captured and preserved through the workflow. Second, the agent receives just-in-time, short-lived credentials for only the narrow task it needs. Third, the policy engine evaluates every tool call against current context rather than a pre-approved blanket role. The practical goal is to support auditability without giving the agent standing access to everything it might ever need.

• Use per-task identity and ephemeral secrets instead of long-lived API keys.
• Log the original requester, the agent identity, the tool invoked, and the policy decision.
• Prefer policy-as-code and runtime decisions over static allowlists for autonomous actions.
• Revoke credentials automatically when the task completes or the workflow changes scope.

This aligns with the guidance in CSA MAESTRO agentic AI threat modelling framework and NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives, both of which emphasise traceability, least privilege, and lifecycle control for non-human execution paths. These controls tend to break down when MCP servers are shared across teams with reused service accounts, because request provenance and entitlement boundaries are no longer separable.

Common Variations and Edge Cases

Tighter authorisation often increases workflow friction, so organisations have to balance auditability against latency, developer experience, and operational complexity. That tradeoff becomes sharper in multi-agent systems, where one agent delegates to another and each hop may need its own identity, scope, and revocation boundary.

There is no universal standard for this yet. Current guidance suggests separating three concerns that are often mixed together: human approval, agent identity, and tool permission. When those are collapsed into a single API token, audit trails become ambiguous and revocation becomes coarse. When they are separated, teams can keep the human trigger, the agent execution identity, and the MCP server authorisation decision distinct.

Edge cases usually appear in legacy environments, shared dev sandboxes, or integrations that cannot propagate identity end to end. In those settings, teams may need compensating controls such as stricter tool scoping, stronger change logging, and explicit human approval gates for high-risk actions. NHIMG’s Top 10 NHI Issues and the OWASP NHI Top 10 both reinforce that lifecycle gaps and privilege reuse are recurring failure modes. The same pattern is visible in the OWASP Top 10 for Agentic Applications 2026, where runtime control weaknesses are treated as a core agentic risk rather than an implementation detail.

Related resources from NHI Mgmt Group

• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?
• Why do MCP-based agent workflows increase identity risk compared with ordinary app integrations?
• How should security teams evaluate policy-based authorisation for agent workflows?