They should define a governance model for MCP identities before broad rollout, including secret lifecycle, access scope, audit logging, and revocation. If the server will be used by multiple users or tools, the identity design has to support delegated access, not a single shared static credential.
Why This Matters for Security Teams
MCP adoption changes the identity problem from “who logged in” to “which workload is allowed to act, for which tool, under which context.” That shift matters because a single shared server credential can silently become a broad trust anchor across users, agents, and automation paths. Current guidance suggests that MCP should be treated as a non-human access design problem first, not just an integration task. The OWASP OWASP Agentic AI Top 10 and NHIMG’s State of MCP Server Security 2025 both point to the same operational issue: once access is embedded into a server or tool configuration, revocation, scoping, and auditability become much harder to enforce consistently.
For IAM and security teams, the main risk is not only secret exposure. It is the tendency to scale first and define identity governance later. That usually produces hard-coded credentials, weak delegation, and unclear accountability across multiple callers. NHIMG’s 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities. In practice, many security teams encounter overbroad MCP access only after tool sprawl, shared credentials, and inconsistent logging have already spread across production.
How It Works in Practice
The safest way to scale MCP is to design the identity layer before broad rollout. That means defining whether the MCP server represents a shared service, a per-user delegated session, or a per-tool workload identity. For most environments, the answer is not a single static secret. It is a short-lived identity model with explicit scope boundaries, auditable issuance, and revocation tied to task completion. That aligns with the current direction of the OWASP Top 10 for Agentic Applications 2026, which emphasizes that autonomous and tool-using systems require runtime control rather than trust by default.
In operational terms, IAM teams should map MCP access to the smallest meaningful unit of authority. That usually includes:
- workload identity for the MCP server, not just a shared API key
- delegated user context when the server acts on behalf of multiple users
- separate secrets for each environment, tenant, and tool boundary
- short TTLs with automatic rotation and immediate revocation paths
- request-level logging for who asked, what tool was called, and why access was granted
Where possible, teams should prefer workload identity and federation patterns over long-lived static secrets, and should treat the MCP server as a policy enforcement point rather than a trusted conduit. NHIMG’s 2024 Non-Human Identity Security Report shows why this matters: 59.8% of organisations see value in dynamic ephemeral credentials, which is a practical signal that the market is moving toward runtime authorization and shorter-lived access. These controls tend to break down when multiple business units share one MCP deployment because delegated access, audit attribution, and secret ownership become ambiguous.
Common Variations and Edge Cases
Tighter MCP identity controls often increase rollout overhead, requiring organisations to balance developer convenience against traceability and blast-radius reduction. Best practice is evolving, so there is no universal standard for this yet, but the strongest pattern is to avoid one-size-fits-all authentication. A per-user model is usually better for interactive workflows, while a per-workload model is often cleaner for automation and service-to-service use cases.
Edge cases appear when an MCP server must support multiple tools, multiple tenants, or mixed human and agentic use. In those environments, a single identity can hide important differences in privilege and intent. Security teams should avoid granting broad tool permissions just because the server is “internal,” and they should not rely on static secrets stored in configuration files. NHIMG’s State of MCP Server Security 2025 highlights how quickly this becomes dangerous in practice, especially when access scoping is missing. The report also shows that 53% of MCP server deployments expose credentials through hard-coded values in configuration files, which is a strong signal that governance must come before scale, not after it.
For teams building shared MCP services, the practical test is simple: if the identity cannot be scoped, logged, rotated, and revoked independently, it is not ready for broad production use.
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 | A1 | Agentic tools need scoped runtime auth, not static trust. |
| CSA MAESTRO | ID-1 | MAESTRO addresses identity, delegation, and agent trust boundaries. |
| NIST AI RMF | AI governance must account for tool-using systems and operational risk. |
Define per-request authorization and reduce broad tool privileges before expanding MCP usage.
Related resources from NHI Mgmt Group
- What should IAM and security teams do first when AI adoption accelerates?
- How should security teams prioritise data security investment across IAM and governance programmes?
- What should IAM teams do before introducing digital employee models?
- What should IAM and PAM teams do before approving an agent pilot?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
