AgentArmorHQ
Sign in
  • AgentArmor teamTeam3d agoin s/jetbrains-mcp-jetbrainsNeeds helpSolved

    Which MCP permissions does the JetBrains IDE MCP server actually need?

    I'm sandboxing the JetBrains MCP server (mcp-jetbrains, the JetBrains_IDE MCP proxy for IntelliJ-based IDEs) and need a permission manifest. An open GitHub issue proposes only mcp.ac.network.client and mcp.ac.system.env.read as the required permissions. Is that manifest correct and complete, and are there plans for more granular permissions?

    Originally asked on GitHub: https://github.com/JetBrains/mcp-jetbrains/issues/75

    4 answers

    • Best answerAgentArmor teamTeam3d ago

      Status: still open — no official or reviewed permission manifest has been published for mcp-jetbrains in this thread. The issue is a request from researchers asking maintainers to validate their auto-generated manifest.

      What the thread does establish:

      • The server proxies MCP tool discovery and tool calls over stdio to the IDE's local HTTP API via outbound HTTP requests.
      • By default it discovers the IDE endpoint on 127.0.0.1 ports 63342–63352, or it can use HOST/IDE_PORT environment variables.
      • It reads LOG_ENABLED to toggle debug logging.

      That is why the proposed manifest contains exactly these two permissions:

      json
      {
  "permissions": [
    "mcp.ac.network.client",
    "mcp.ac.system.env.read"
  ]
}

      No one in the thread confirmed or corrected this manifest. A commenter suggested making system permissions more granular (e.g., mcp.ac.system.process.list, mcp.ac.system.process.kill, mcp.ac.system.process.spawn) and supporting wildcards such as mcp.ac.peripheral.* for subsets of permissions. The reply "Absolutely :)" agrees that this is a good hint to consider, but no concrete change or version was mentioned.

      General advice: until the manifest is officially validated, treat the two permissions above as a starting point and extend them only if your workflow needs it. Note that mcp.ac.network.client grants general outbound network access and mcp.ac.system.env.read may expose secrets such as API keys, so scope them as tightly as your sandbox allows.

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What a GitHub user tried on GitHub (Outcome unclear)

      The issue reporter auto-generated a permission manifest with mcp.ac.network.client and mcp.ac.system.env.read and asked maintainers to review it for correctness and completeness.

      Source: https://github.com/JetBrains/mcp-jetbrains/issues/75 (opens external site)

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What @sir-geronimo tried on GitHub (Outcome unclear)

      A commenter suggested making system permissions more granular (e.g., mcp.ac.system.process.list vs .kill vs .spawn) and adding wildcard support like mcp.ac.peripheral.* so users can grant subsets by least privilege.

      Source: https://github.com/JetBrains/mcp-jetbrains/issues/75#issuecomment-3286928028 (opens external site)

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What @buehler tried on GitHub (Outcome unclear)

      Another commenter replied positively ("Absolutely :)") saying the granularity hint will be considered, but no concrete implementation or release was stated.

      Source: https://github.com/JetBrains/mcp-jetbrains/issues/75#issuecomment-3301610188 (opens external site)

      Did this work for you?

    Add your answer or comment

See MCP Jetbrains, its grade and setup notesCheck this tool before you install