Use identity states that reflect trust, not just traffic labels. Separate verified clients, signed clients, spoofed clients, and unknown clients, then attach those states to each request alongside source IP and deployment context. That lets IAM, platform, and security teams make governance decisions based on verifiable attribution instead of guessed tool names.
Why This Matters for Security Teams
AI tools that call an mcp server are not just another client class. They can change behaviour by prompt, tool output, or orchestration logic, which means a simple “approved app” label does not tell IAM, platform, or SOC teams what risk is actually present. The classification question matters because trust needs to follow verifiable identity state, not a guessed product name or a static allowlist.
This is especially important when MCP configurations carry secrets or when tool permissions are broader than the operator intended. NHIMG research on the State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files, showing how quickly a small classification error can become a secrets exposure problem. Security teams should also read this through the lens of the OWASP Agentic AI Top 10, because agentic systems can chain tools and act outside the assumptions made by traditional application inventories.
In practice, many security teams discover the real client identity only after an access review, incident, or secrets leak has already forced the issue.
How It Works in Practice
The most defensible approach is to classify the caller by identity state at request time, then carry that state into policy decisions and logging. For MCP traffic, that usually means separating verified clients, signed clients, spoofed clients, and unknown clients. The label is not the control by itself; it is the input that lets a policy engine decide whether the caller may invoke a tool, read a resource, or continue a session.
In practice, teams should combine workload identity, transport signals, and deployment context. A verified client may present a cryptographic workload identity, such as SPIFFE-style identity or an OIDC-backed token, while a signed client might have code-signing assurance but weaker runtime provenance. A spoofed client should be treated as hostile until proven otherwise, and an unknown client should default to least privilege. That aligns with the direction described in NIST SP 800-53 Rev 5 Security and Privacy Controls, where identification, access enforcement, and auditability must be tied together rather than handled as separate manual checks.
- Attach identity state to each request, not just to the service account.
- Evaluate tool access at runtime with current context, not only during onboarding.
- Log source IP, deployment namespace, build provenance, and request intent together.
- Revoke or downgrade trust immediately when provenance becomes ambiguous.
That approach maps well to the operational lessons highlighted in NHIMG coverage such as Gemini CLI Breach — Silent Code Execution and the Replit AI Tool Database Deletion incident, where tool-enabled systems produced consequences that were not obvious from simple client labeling. These controls tend to break down when multiple agents share one gateway token because request-level attribution gets collapsed into a single opaque identity.
Common Variations and Edge Cases
Tighter classification often increases operational overhead, requiring organisations to balance stronger attribution against friction in developer workflows and runtime automation. That tradeoff is unavoidable, especially in mixed environments where some MCP clients are human-operated tools, some are autonomous agents, and some are embedded platform services. Current guidance suggests treating these as different trust classes, but there is no universal standard for this yet.
One common edge case is a tool that is signed but not strongly bound to a workload identity at runtime. In that situation, signature alone is not enough for access to sensitive MCP tools because a legitimate binary can still run in the wrong environment or with the wrong downstream privileges. Another edge case is an ephemeral agent that spins up per task. For those workloads, static RBAC often fails because the tool path changes faster than the role model can be updated; just-in-time credentials and policy-as-code are a better fit. NHIMG’s Analysis of Claude Code Security and the OWASP Agentic Applications Top 10 both reinforce that autonomous tools need context-aware governance, not just perimeter approvals.
For teams formalising this model, the practical question is not “Is it an app?” but “What level of trust can be proven for this request right now?” That is the classification standard that scales across agentic workflows, shared infrastructure, and evolving MCP deployments.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agentic clients need runtime trust classification, not static app labels. |
| CSA MAESTRO | GOV-02 | MAESTRO emphasizes governance for autonomous agent access and attribution. |
| NIST AI RMF | GOVERN | AI RMF governance requires accountability for adaptive system behaviour. |
| OWASP Non-Human Identity Top 10 | NHI-01 | MCP callers are non-human identities and need distinct trust states. |
| NIST CSF 2.0 | PR.AC-4 | Access enforcement must reflect current identity and context. |
Enforce least privilege dynamically using request-time identity and provenance.
