JupiterOne MCP directory listing expands security graph access

At a glance

What this is: JupiterOne’s MCP directory listing makes its security graph directly queryable from Claude for exposure, blast-radius, and change analysis.

Why it matters: It matters because IAM and security teams now have to govern how AI workflows consume asset, identity, and vulnerability context without weakening access boundaries or overextending trust.

👉 Read JupiterOne's blog post on Anthropic's MCP directory listing for JupiterOne

Context

MCP gives AI systems a standard way to query tools and data sources, which means the security question shifts from whether a model can answer to whether the identity and access behind that answer are governed. In this case, JupiterOne is exposing its security graph to Claude through Anthropic’s directory, which turns graph context into part of an AI workflow.

For IAM and NHI programmes, the risk is not that the graph is wrong. The risk is that machine-readable context becomes reusable in ways the original access model did not anticipate, especially when vulnerability, identity, and asset relationships are stitched into conversational workflows.

This is a workload identity and access governance problem as much as an AI integration story. The starting position is typical of modern security operations, where teams want faster context retrieval, but the control assumptions need to keep pace with how the tool is being consumed.

Key questions

Q: How should security teams govern AI access to a security graph?

A: Treat AI access to a security graph like any other privileged integration. Scope the data the assistant can query, filter sensitive fields, and require full audit logging for prompts, returned context, and downstream actions. If the assistant can infer exposure or blast radius, the access path needs ownership, review, and offboarding controls just like other NHIs.

Q: Why does natural-language querying create governance risk for IAM teams?

A: Natural-language querying lowers the barrier to broad data access, which can expand who asks what and how often. The risk is not the language itself. It is that an AI workflow may surface identity, asset, and vulnerability context beyond the intent of the original access model, especially if query permissions are too coarse.

Q: What should teams check before connecting AI tools to operational security data?

A: Check whether the AI client has explicit scope limits, whether the data returned is redacted where necessary, and whether query activity is auditable. If the integration can reach relationships, not just records, confirm that relationship traversal is restricted to the use case and that the path is owned like a privileged account.

Q: How do security graphs change blast-radius analysis for practitioners?

A: They move blast-radius analysis from isolated findings to relationship-driven exposure. Instead of asking only whether an asset is vulnerable, teams can ask what the asset touches, what identity can reach it, and what the next-hop impact would be. That improves triage, but only if the graph access path is tightly governed.

Technical breakdown

How MCP turns a security graph into an AI-accessible tool

MCP is an open protocol that lets an AI client call external tools and data sources in a standardised way. In this pattern, the security graph remains the source of truth, but the assistant can query it at runtime instead of relying on static exports or manual pivots. The architectural change is that access is no longer just human-to-console. It becomes model-to-tool, which introduces a new identity boundary around the client, the server, and the underlying data scope.

Practical implication: treat MCP exposure as a governed integration surface, not a convenience feature.

Why graph context changes blast-radius analysis

A security graph links assets, identities, vulnerabilities, and relationships so queries can answer not just what is exposed, but what an attacker could reach next. That makes blast-radius analysis materially better than isolated findings because the path matters as much as the asset. The MCP layer does not create the graph, but it makes those relational queries available to an AI workflow, which increases the need for strong entitlement scoping on what the assistant can ask and retrieve.

Practical implication: scope graph queries to the minimum relationship set needed for the use case.

What changes when natural-language access replaces query syntax

Natural-language access removes the need for users to know a domain query language, but it also reduces friction for broader and less predictable querying. That can be useful for triage, yet it can also widen access to sensitive context if the underlying authorisation model is coarse. The governance issue is not the prompt itself. It is whether the assistant is limited to the same data boundaries, filtration rules, and audit expectations that would apply if a human analyst were running the query directly.

Practical implication: align conversational access with the same approval and logging standards used for privileged analytical access.

NHI Mgmt Group analysis

MCP is becoming a control-plane issue, not just an integration pattern. When a security graph is exposed through an AI-readable protocol, the identity question is no longer only who can log in. It is what the AI client can query, infer, and reuse at runtime. That moves MCP from a developer convenience into identity governance territory, because the access boundary now spans tools, context, and downstream interpretation.

Security graphs create value only when relationship context is reachable, which is also where exposure concentrates. The more useful the graph, the more it contains sensitivity about assets, identities, and attack paths. That makes the old assumption that context can be broadly queryable but harmless much harder to defend. Practitioners should treat graph relationships as governed identity data, not just operational metadata.

Blast-radius queries are the right use case for MCP, but they also sharpen the access question. The phrase itself is a useful concept here: security graph blast-radius exposure describes the point where relational visibility becomes operationally valuable and security-sensitive at the same time. That is a strong fit for security operations, but only if the assistant’s permissions, redaction rules, and audit trail are designed for that sensitivity.

There is a workload identity lesson here for every AI workflow that reaches into security data. The real governance gap is not whether the model can speak natural language, but whether its runtime access is constrained like any other privileged automation path. That means the same lifecycle discipline used for service accounts and other NHIs now applies to AI-mediated tooling paths as well.

AI workflows will increasingly consume the same evidence humans use, which collapses the distance between analytics and authorisation. Once the assistant can pull identity, asset, and vulnerability context on demand, the trust model shifts from static reports to live retrieval. Practitioners should assume that every AI query path is now part of the security programme’s identity surface, not outside it.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
• The governance gap is widening as AI systems inherit machine identity patterns that most programmes still struggle to secure consistently.

What this signals

Security graph access is now part of the NHI problem set. When AI workflows can query identity and asset relationships directly, the programme has to govern the integration path as an NHI, not just the database behind it. That is why lifecycle ownership, scoped access, and traceable usage matter as much as the underlying graph data.

From our research: only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security. That confidence gap is exactly what AI-mediated security operations will expose if query boundaries are left informal.

Security teams should expect conversational access to operational data to expand faster than their governance model. The next control question is not whether Claude can answer, but whether every answer path is owned, logged, and constrained like a privileged machine identity.

For practitioners

• Govern MCP access as a privileged integration Define which AI clients can reach the security graph, what data domains they can query, and which response fields must be filtered or suppressed.
• Apply least-privilege to graph relationships Limit assistants to the minimum asset, identity, and vulnerability relationships required for the workflow, rather than exposing the entire graph by default.
• Log AI-mediated security queries end to end Record the prompt, the queried objects, the returned context, and the downstream action so review teams can trace how sensitive security data was used.
• Review NHI lifecycle controls for AI tool paths Treat the connection between Claude and JupiterOne as a governed non-human identity path with ownership, rotation, and offboarding requirements.

Key takeaways

• MCP turns AI access to security data into an identity governance problem, not just an interface choice.
• Graph-based blast-radius analysis is more powerful than isolated findings, but it also makes access scoping and auditability non-negotiable.
• AI workflows that query security graphs should be governed like privileged non-human identities with ownership, least privilege, and lifecycle controls.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Security Graph: A security graph is a relationship map that shows how AI components connect to each other and to surrounding systems. In this context, it is more useful than a flat inventory because it reveals trust paths, data flows, and the likely blast radius of a model, agent, or tool integration.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

JupiterOne's full blog post covers the operational detail this post intentionally leaves for the source:

• How to connect Claude to the JupiterOne MCP server and authenticate with an existing account
• The specific questions the security graph can answer in live triage workflows
• Examples of the graph relationships the integration can return for exposure and blast-radius analysis
• The implementation path for teams that want to use the existing JupiterOne instance without rebuilding their stack

👉 JupiterOne's full post shows how the MCP server is used in live triage and graph-based exposure queries.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.