Security teams should make the governed mediation layer the only working path to APIs and web applications. That means blocking direct credentials, requiring identity-aware proxies, and rejecting requests that do not carry approved session attestation. If alternative paths remain usable, MCP becomes advisory rather than enforceable.
Why This Matters for Security Teams
MCP only improves control when every agent action is forced through the governed mediation layer. If an AI agent can still reach APIs, SaaS consoles, or web apps with direct secrets, the control plane becomes optional and the agent can route around policy. That is why teams should treat MCP as an enforcement boundary, not a convenience feature, and why guidance from the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both emphasize runtime governance over static trust.
This matters because agent behaviour is goal-driven, not session-predictable. Once an agent can chain tools, reuse tokens, or discover alternate paths, classic IAM assumptions break down fast. NHI Management Group has documented how weak scoping and exposed credentials keep showing up in agent ecosystems, including the State of MCP Server Security 2025, where only 18% of MCP server deployments implement any form of access scoping for tool permissions. In practice, many security teams discover bypass paths only after the first unauthorized agent action has already occurred, rather than through intentional control validation.
How It Works in Practice
The practical pattern is simple: make the governed mediation layer the only path that can reach protected resources, then prove at request time that the agent is entitled to perform the action. That usually means blocking direct credentials, forcing all tool calls through an identity-aware proxy, and requiring short-lived attested sessions before the proxy forwards anything. This is where workload identity matters. Agents need cryptographic proof of what they are, not just a reusable secret. In modern deployments, that often means OIDC-backed workload identity, SPIFFE-based identity, or equivalent runtime attestation paired with policy-as-code.
Security teams should also separate authentication from authorization. Authentication proves the agent instance or workload identity. Authorization decides whether the specific task, resource, and context are allowed right now. That aligns with current guidance in the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, both of which favour continuous evaluation over static trust.
- Use JIT credentials that expire after the task, not long-lived shared secrets.
- Evaluate policy at request time with context such as target, tool, data sensitivity, and session attestation.
- Deny any direct outbound path that bypasses the mediation layer, even for admin or service accounts.
- Log the approved intent, tool call, and downstream resource for later audit and containment.
For teams mapping this to NHI operations, the lesson is consistent with NHI governance research from AI Agents: The New Attack Surface report and Ultimate Guide to NHIs — Standards: the control only works when the agent has no alternative credential path to exploit. These controls tend to break down in legacy environments where the agent must interact with unmanaged APIs, browser sessions, or SaaS tools that cannot validate session attestation.
Common Variations and Edge Cases
Tighter mediation often increases operational overhead, requiring organisations to balance containment against workflow latency and integration complexity. That tradeoff is real, especially when teams are dealing with hybrid estates, vendor-managed SaaS, or browser-based automation that was never designed for identity-aware proxying. Current guidance suggests that these cases should still default to denial, with exceptions only where the downstream system can enforce the same runtime controls.
There is no universal standard for this yet, so teams need to be explicit about what counts as an approved alternate path. For example, some environments allow a temporary break-glass route for incident response, but that route should still require attestation, time limits, and full audit. Others may use separate policies for read-only agents versus action-taking agents. The key distinction is that read access can sometimes tolerate broader scoping, while write actions, credential retrieval, and privilege escalation should be tightly mediated.
One useful signal is whether the agent can independently mint, store, or replay credentials. If yes, the bypass risk remains high even when the MCP layer is well designed. NHI Management Group’s research on the Moltbook AI agent keys breach and the AI LLM hijack breach shows why static secrets and weak scoping are still the fastest route around policy. If the agent can keep a usable secret outside the mediation layer, enforcement is already compromised.
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 | Agent bypasses are classic broken authorization and tool abuse risks. |
| CSA MAESTRO | IAM | MAESTRO covers agent identity, mediation, and runtime trust boundaries. |
| NIST AI RMF | AI RMF supports continuous governance for autonomous system behaviour. |
Bind agent identity to attested sessions and require policy checks on each tool call.
