A capability map is the explicit list of actions, resources, and network paths a server is allowed to use. It matters because MCP risk is defined by what the server can reach at runtime, not by its stated purpose or source repository alone.
Expanded Definition
A capability map is the runtime boundary for an NHI-enabled server or agent: the explicit set of actions it may perform, resources it may touch, and network paths it may traverse. In practice, this is broader than a simple allowlist because it captures not just APIs but also object scopes, message queues, internal services, and egress destinations. For MCP-based systems, a capability map expresses the real blast radius of the server, which is why it should be treated as a governance artifact rather than a deployment note. That framing aligns with the NIST Cybersecurity Framework 2.0 emphasis on controlling access and continuously monitoring operational exposure.
Definitions vary across vendors, especially when “capability map” is used interchangeably with policy, permission set, or tool registry. NHI Management Group treats it more narrowly: it should describe what the server can actually do at runtime, not what the developer intended it to do. The most common misapplication is using a static architecture diagram as a capability map, which occurs when the runtime paths, delegated tokens, and downstream service permissions are never validated against live execution.
Examples and Use Cases
Implementing a capability map rigorously often introduces operational friction, because every added permission must be justified, tested, and reviewed against the server’s real task scope. That extra discipline reduces overreach, but it also slows informal “just give it access” workflows.
- An MCP server for ticket triage is limited to reading a specific queue, creating comments, and calling one internal workflow API, with all other tools blocked.
- A data-analysis agent may query approved warehouses but cannot open outbound internet connections, reducing the chance of data exfiltration through unexpected egress.
- A deployment helper can start a single CI/CD action and read release metadata, but it cannot modify build definitions or access production secrets.
- During due diligence, security teams compare the declared capability map against actual logs to confirm the server has not drifted into broader access.
For NHI-focused governance, this is where the concept becomes operational: the Ultimate Guide to NHIs shows why excessive privilege is such a recurring failure mode, and capability maps are one of the few practical ways to make that risk visible. The same control logic also fits broader identity guidance in the NIST Cybersecurity Framework 2.0, where access scope must be explicit and continuously managed.
Why It Matters in NHI Security
Capability maps matter because NHI compromise is often about reachable authority, not credential theft alone. If a server can call sensitive tools, traverse internal networks, or invoke privileged APIs, the attacker inherits that runtime reach once the identity is abused. This is especially important in agentic environments, where an agent may chain tools in ways the original developer never anticipated. A weak capability map turns a narrow service identity into a lateral-movement platform. NHI Management Group data shows that 97% of NHIs carry excessive privileges, which is exactly the kind of condition a capability map is meant to surface and reduce.
In governance terms, the map becomes the evidence base for least privilege, Zero Trust enforcement, and incident scoping. It helps answer three questions quickly: what was reachable, what should have been reachable, and what must be revoked now. Organisations typically encounter the need for a capability map only after an agent starts touching systems it was never meant to reach, at which point containment, investigation, and privilege reduction become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses excessive permissions and runtime reach for non-human identities. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agent tool access must be bounded by explicit runtime capability constraints. |
| NIST Zero Trust (SP 800-207) | PA-1 | Zero Trust requires explicit policy for what a workload may access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control depends on clearly defined permitted actions. |
| CSA MAESTRO | Agentic systems need bounded tool use and explicit operational guardrails. |
Define and review each server's allowed actions, resources, and egress paths against NHI-02.
Related resources from NHI Mgmt Group
- What is the difference between a static data map and a living data inventory?
- What breaks when organisations do not map the access path of AI and SaaS integrations?
- How do you know whether an agent’s self-map is actually useful?
- What breaks when organisations cannot map sensitive data to service accounts and application identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
