Directory trust signals help you decide whether a server is worth evaluating. Runtime control decides what an AI client can actually do once connected. Trust badges, popularity metrics, and maintainer verification are useful, but they do not replace per-tool authorization, session logging, or revocation when access should end.
Why This Matters for Security Teams
For MCP, directory trust signals answer a narrow question: is this server credible enough to inspect? They do not answer the security question that matters most: once a client connects, what can it do, with which tools, and for how long? That distinction is critical because MCP servers can expose secrets, data retrieval, and execution paths that are invisible at the directory layer. NHIMG’s The State of MCP Server Security 2025 found only 18% of deployments implement any form of access scoping for tool permissions, which shows how often trust signals are mistaken for control.
This gap is especially dangerous in agentic environments, where autonomous clients can chain tools, persist sessions, and act beyond the operator’s intent. Guidance from the OWASP Agentic AI Top 10 treats tool misuse and over-privilege as core risks, not edge cases. Directory badges, maintainer verification, and popularity metrics are useful for intake triage, but they are not authorization. In practice, many security teams discover this only after an MCP-connected workflow has already reached a sensitive tool or data source.
How It Works in Practice
Directory trust signals belong in the evaluation and onboarding stage. They help teams decide whether to review a server, not whether to grant it operational authority. Runtime control begins after connection and must enforce per-session, per-tool, and per-action decisions based on the client’s identity, the requested tool, the context of the request, and the current policy state. That is the practical difference between “looks trustworthy” and “is allowed to do this now.”
For MCP, effective runtime control usually combines several layers:
- Workload identity for the client and server, so access decisions are tied to cryptographic identity rather than a directory listing.
- Just-in-time credential issuance, so secrets are short-lived and can be revoked when the task ends.
- Tool-level authorization, so a client may read one resource but not invoke a write or admin operation.
- Session logging and audit trails, so later review can reconstruct what was requested and what was allowed.
- Policy evaluation at request time, so rules can reflect current risk, environment, and user approval state.
That approach aligns with current guidance from OWASP Top 10 for Agentic Applications 2026 and NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities, which both reinforce that machine identities need operational controls, not just registration data. In short, directory trust is a gate to assessment, while runtime control is the gate to action. These controls tend to break down when MCP clients inherit broad developer tokens or when one long-lived credential is reused across multiple sessions and tools.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance faster onboarding against stronger containment. That tradeoff is real, especially in environments that rely on many third-party MCP servers or frequent tool updates. There is no universal standard for how much a directory should enforce versus how much should be delegated to runtime policy, so current guidance suggests separating discovery from authorization as cleanly as possible.
Some teams treat directory trust as a proxy for risk scoring, using maintainer verification, version history, or community adoption to prioritise review. That can be useful, but it should not be confused with authorization. Other teams use directory metadata to trigger stricter runtime checks, such as mandatory human approval, shorter TTLs, or restricted tool sets. That is usually the safer pattern.
Edge cases appear when the MCP server itself is dynamic, multi-tenant, or able to broker access to downstream systems. In those cases, trust signals may tell you the server is legitimate, but they say little about tenant isolation, transitive tool access, or whether the server can invoke more privilege than the client requested. NHIMG’s Ultimate Guide to NHIs – Standards is useful here because it frames control as an identity and lifecycle problem, not a directory problem. The practical rule is simple: trust metadata can help you decide to connect, but only runtime policy can decide what happens after connect.
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 | A4 | Addresses tool misuse and over-privilege in autonomous clients. |
| CSA MAESTRO | TR-2 | Covers runtime trust decisions for agent-to-tool interactions. |
| NIST AI RMF | Supports governance and lifecycle control for AI systems in operation. |
Enforce per-tool authorization and request-time policy checks before any agent action.
Related resources from NHI Mgmt Group
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between human identity governance and AI agent governance?
- What is the difference between workload identity and API keys for AI agents?
- What is the difference between governing human access and governing AI agent access?
