How can organisations reduce risk when AI agents use MCP servers?

Why This Matters for Security Teams

MCP servers turn a model into an operator with live tool access, which means the risk is no longer limited to prompt injection or bad output. The more important issue is what data the agent can reach, which credentials it can consume, and how quickly that access can be revoked when scope changes. NHI Management Group’s Astrix Security analysis of MCP server security shows why this matters: 53% of MCP servers expose credentials through hard-coded values in configuration files, and only 18% implement any form of access scoping for tool permissions.

That is not a policy footnote. It is a direct path from agent autonomy to credential exposure, overbroad data access, and unaudited actions across internal systems. Traditional reviews often focus on whether the server is trusted, but for MCP the more relevant questions are whether the tool can be constrained at runtime and whether the identity behind the call is continuously verifiable. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points to runtime control rather than static trust. In practice, many security teams only discover MCP exposure after an agent has already reached a sensitive tool path or leaked a credential through a server configuration.

How It Works in Practice

Reducing risk starts with treating each MCP server as a governed workload boundary, not a convenience integration. That means inventorying every server, mapping the tools it exposes, and tying each tool to an explicit business purpose, data classification, and revocation owner. NHI Management Group’s OWASP NHI Top 10 and the Ultimate Guide to NHIs both reinforce the same operational point: lifecycle control matters more than simple visibility.

For agentic workloads, static RBAC is usually too coarse. Agents do not follow stable human job patterns, so access should be evaluated at request time using context such as task intent, tool sensitivity, environment, and current risk state. That is where policy-as-code and intent-based authorisation become useful. Best practice is evolving, but the direction is clear: combine short-lived credentials, scoped tokens, and explicit revocation workflows so a server only receives the minimum access needed for the current task. The CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework both support this kind of ongoing evaluation.

• Issue JIT credentials per task rather than reusing long-lived secrets.
• Bind agent calls to workload identity so the server can verify what is making the request, not just what secret it presents.
• Limit each MCP tool to a narrow scope and separate read paths from write or export paths.
• Log tool invocation, data touched, and revocation events for audit and incident response.

These controls tend to break down when MCP servers are shared across multiple agents and teams because ownership, scope, and revocation authority become ambiguous.

Common Variations and Edge Cases

Tighter MCP governance often increases integration overhead, so organisations have to balance speed of experimentation against the cost of control design. That tradeoff is real, especially in teams that are shipping multiple agents quickly or using internal MCP servers as a shared automation layer.

One common edge case is a server that is technically harmless in isolation but dangerous when chained with other tools. An agent may use a low-risk read tool to discover a higher-value write path, so server-level approval alone is not enough. Another edge case is delegated access through shared service credentials. If the same secret is reused across environments, revocation becomes blunt and may interrupt unrelated workloads. Current guidance suggests using short-lived, context-aware credentials and treating each server as revocable infrastructure, not a permanent trust anchor.

Teams also need to account for ownership changes. If an MCP server changes hands, expands scope, or begins reaching regulated data, the original approval should not be assumed to remain valid. That is why the strongest programmes pair inventory with change management and conditional access review. NHI Management Group’s Top 10 NHI Issues highlights how often non-human access control fails at the lifecycle stage, not the design stage. In practice, MCP risk is rarely caused by one bad server alone; it emerges when permissive defaults, weak revocation, and autonomous tool chaining line up at the same time.

Related resources from NHI Mgmt Group

• How should teams govern AI agents that use MCP?
• How can organisations govern AI agents that use service accounts and tokens?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents increase non-human identity risk in existing IAM programmes?