They often focus on the protocol and ignore the governance boundary. The real issue is whether the assistant is allowed to see the right data, ask follow-up questions, and trigger actions safely. Without tight scoping, MCP can expose investigation data to identities that should only consume a narrow result set.
Why Security Teams Misread MCP Risk
Security teams often treat MCP as the problem when the real risk sits at the governance boundary: what the assistant may see, what it may ask next, and what it may do with a tool call. MCP-connected assistants are autonomous or semi-autonomous workloads, so static RBAC alone rarely reflects the full task context. That gap is why the strongest guidance now focuses on agentic authorisation and scoped execution, as reflected in the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10.
The practical failure mode is overtrusting the assistant’s “role” while ignoring its actual objective. An agent may begin with a narrow question, then chain follow-up prompts, retrieve adjacent records, and invoke tools that were never meant for that workflow. In NHI terms, the issue is not just identity, but whether the identity is bound to a specific intent, data slice, and action boundary. Research from The State of MCP Server Security 2025 shows how often MCP deployments still leave permissions and secrets too open, which turns a convenience layer into an exposure layer. In practice, many security teams encounter the breach in a post-incident audit rather than through intentional scope design.
How It Should Be Governed at Runtime
Effective MCP governance starts with intent-based authorisation, not broad access grants. The assistant should receive only the minimum context needed for the current task, then be re-evaluated at each step before any follow-up query or tool execution. That is a better fit for autonomous behaviour than pre-defined job roles because agents do not follow fixed workflows in the same way humans do. Current guidance suggests combining policy-as-code with workload identity, so the system can verify what the agent is, what it is trying to do, and whether the action is still allowed in the current context.
In practice, that means using short-lived credentials, task-scoped secrets, and explicit approval boundaries for sensitive actions. JIT credential provisioning helps reduce blast radius because tokens are issued for a task and revoked when the task ends. Workload identity, such as SPIFFE or OIDC-backed identities, gives the policy engine a cryptographic basis for deciding whether the agent should continue. This is also where OWASP Top 10 for Agentic Applications 2026 and NHIMG’s Analysis of Claude Code Security are useful: both show that agentic risk is about execution authority, not just prompt content. For a working control model, security teams should combine least privilege, real-time policy evaluation, and logging that captures the full chain of data access and tool calls. In AI agent environments with multiple tools, shared memory, or delegated sub-agents, these controls tend to break down because each hop expands context faster than reviewers can manually inspect it.
- Issue JIT secrets per task, not standing credentials for the whole assistant.
- Bind tool access to workload identity and runtime policy checks.
- Limit retrieval to the smallest data slice needed for the immediate action.
- Require step-up approval for destructive, external, or high-impact tool calls.
- Audit every follow-up question, data fetch, and action chain.
Where the Edge Cases Break the Model
Tighter runtime controls often increase latency and operational overhead, so organisations have to balance safety against user experience and engineering complexity. That tradeoff becomes visible when assistants need to answer quickly across multiple systems, because every extra policy check, approval gate, or credential refresh can slow the workflow. Best practice is evolving here, and there is no universal standard for when an assistant should pause for confirmation versus continue autonomously.
Edge cases usually appear when assistants operate across mixed-trust environments, such as investigation workflows, code execution, or incident response. In those settings, a narrow result set can still become dangerous if the assistant can ask one more question, pull one more record, or invoke a tool that reaches outside the original business need. This is why static RBAC is not enough on its own: a role can be valid while the current intent is not. The operational answer is to pair zero standing privilege with context-aware policies and explicit constraints on retrieval, memory, and delegation. That aligns with the direction signalled by the OWASP Agentic Applications Top 10 and the broader agentic control approach in the OWASP Agentic AI Top 10. The hardest environments are those where an assistant can chain tools across domains, because a single permitted step can become an unauthorised workflow before a human ever sees it.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers agentic misuse from autonomous tool use and scope drift. |
| CSA MAESTRO | AI-3 | Addresses governance for agent identity, tools, and delegated execution. |
| NIST AI RMF | GOVERN | Govern function fits accountability for autonomous agent behavior and controls. |
Constrain agent actions to runtime-approved intents and log each tool invocation.
