JetBrains AI Assistant and Junie Security: Admin, Data and Agent Controls

Once AI Assistant and the Junie coding agent are switched on in JetBrains IDEs, source code, prompts and terminal output start flowing to language models, and an agent gains the ability to edit files and run commands on developer machines. JetBrains gives administrators a layered set of controls for this: AI Enterprise in IDE Services decides who gets AI, which model providers are used and whether MCP servers and third-party agents are allowed; project files such as .noai and .aiignore fence off code; and the Junie Action Allowlist decides which commands run without a human click. This guide walks through those controls for platform engineers, developer experience teams and security reviewers who are rolling JetBrains AI out across an organisation. For the wider discipline of securing AI coding tools across products, see the AI IDE and Coding Agent Security Guide.

This is an independent guide from NHI Mgmt Group, based on JetBrains' public documentation as of November 2026. It is not sponsored or reviewed by JetBrains. Product features change, so confirm settings against JetBrains' current documentation.

Key takeaways

• Govern AI through profiles, not individual IDEs. With AI Enterprise in IDE Services, developers only get AI features once a provider is enabled for their assigned profile, which makes profiles the access control boundary.
• Choose the model provider deliberately. Administrators can use JetBrains AI or route traffic to their own OpenAI Platform, Azure OpenAI, Google Vertex AI, Amazon Bedrock or OpenAI compatible endpoint, which changes where prompts and code are processed.
• Keep detailed data collection off unless you have decided otherwise. Detailed data (full prompts, responses and code snippets) is disabled by default for organisational use and is controlled per profile by the administrator.
• Fence code with project files. An empty .noai file disables AI Assistant for a whole project, and .aiignore excludes the contents of specific files and folders using .gitignore syntax.
• Use the Action Allowlist instead of Brave Mode. Junie asks before terminal commands, MCP tool calls and sensitive file access by default; narrow allowlist rules keep that safety net while removing friction.

How identity and access work in JetBrains AI

JetBrains AI reaches developers through two routes. Individual and team licences connect the IDE to the JetBrains AI service through a JetBrains Account. Organisations that want central control use AI Enterprise, a module of IDE Services (self-hosted or IDE Services Cloud). In that model the developer connects to the organisation's IDE Services instance through the Toolbox App, and the profile assigned to that user decides what AI is available. The JetBrains documentation states that until a provider is enabled for a profile, developers have no access to AI features or the AI Assistant plugin, and that if the Toolbox App is disconnected, no JetBrains AI option is available to the user.

Two things follow for access design. First, identity for AI is inherited from the IDE Services user and profile, so the same joiner, mover and leaver process that assigns profiles controls AI access. Second, project files work regardless of licence route, which makes them the control that follows sensitive code to any machine that opens it.

Model providers and where data goes

Under Settings | AI Providers | Add provider an administrator selects where model calls go. The documentation lists the options below; the choice determines which contract and region apply to prompts and code.

The IDE Services data collection page notes that with custom providers no behavioural data goes to JetBrains: it goes directly to the selected provider. For code completion a separate tab offers JetBrains Mellum as a self-hosted option. Individual developers can also connect Ollama or LM Studio under Settings | Tools | AI Assistant | Providers & API keys; as of November 2026 the documentation describes local models serving AI Chat and the features assigned to them in Models Assignment, with agents and MCP tool calls running on cloud providers.

Admin roles and privileged access

The IDE Services administrator is the privileged identity for JetBrains AI. That role can enable or disable AI Enterprise for the whole organisation, add providers with their API keys and cloud credentials, change which profiles get AI and Junie, turn detailed data collection on, and approve MCP servers and agents. Treat it like any SaaS super administrator.

• Limit the number of IDE Services administrators: two or three named people, each signing in through your identity provider with phishing-resistant MFA, and reviewed quarterly.
• Separate profile design from provider credentials: the person who manages the Azure OpenAI or Bedrock credentials does not need to be the person who assigns developers to profiles. Keep provider keys in your secrets manager and enter them in IDE Services from there.
• Record every change to AI Enterprise: enabling, disabling, adding a provider, changing the default provider or turning on Allow detailed data collection should go through a change ticket, because each one changes where code goes.
• Use usage limits as a guard rail: in AI Enterprise Settings you can turn off Unlimited number of users and set a user limit. Users above the limit receive restricted feature access, which stops unplanned spread.

On the developer side, Junie itself is a privileged actor: in Code mode it can run terminal commands, create and edit files and run tests with the developer's own operating system rights and credentials. Ask mode is read-only. Default sensitive teams to Ask mode for exploration and make Code mode an explicit choice.

Integrations, API tokens and service accounts

Three kinds of non-human credential appear in a JetBrains AI rollout, and each needs an owner, a rotation date and a narrow scope.

MCP servers and third-party agents

In AI Enterprise the Model Context Protocol tab has a setting, Allow users to add MCP in their IDE, which is on by default. Turning it off prevents it being re-enabled at profile level. Administrators can then add approved Command or Remote MCP servers centrally and assign them to profiles. The Agent Registry tab works the same way for agents: with Allow all agents off, only agents added to profiles are provisioned. For most organisations the safe pattern is a curated list: switch off self-service, approve servers after review and assign them only to the profiles that need them. Junie reads project MCP configuration from .junie/mcp/mcp.json and global configuration from ~/.junie/mcp/mcp.json, managed at Settings | Tools | Junie | MCP Settings. See the MCP Security Guide for server review criteria.

Junie approvals and the Action Allowlist

By default Junie needs explicit approval before most terminal commands, code execution and MCP tool calls. From the tool window a developer can allow one command, allow similar commands (Junie generates a pattern) or allow all actions of a type. Rules are reviewed at Settings | Tools | Junie | Action Allowlist. Junie CLI keeps its rules in ~/.junie/allowlist.json with a defaultBehavior, an allowReadonlyCommands flag and a rules object.

Rules use allow or ask with either a literal prefix or a glob pattern, and the first match wins. The documentation explains two behaviours that make careful rules effective: in chained commands every part must be allowed, and commands inside substitutions such as $(...) or backticks are checked at any depth. Write prefixes at the subcommand level: a bare git prefix also allows git push, while git status and git diff do not. Brave Mode is a checkbox that skips approval for sensitive actions; the JetBrains documentation advises against it and recommends allowlisting instead, and notes that files listed in .aiignore can still be reached in Brave Mode.

Logging and detection

Visibility comes from four places. Combine them rather than relying on one.

• IDE Services analytics: the Users and Adoption and AI Activity and Impact tabs show who is using AI Enterprise and how much. Review them monthly against the profiles you meant to enable.
• Model provider logs: when you route through your own Azure OpenAI, Vertex AI, Bedrock or OpenAI account, that platform's own logging and usage records apply to the traffic. Alert on spikes and on calls from unexpected regions or identities.
• Network egress: the AI Assistant documentation lists the base URLs https://api.jetbrains.ai/ and https://api.app.prod.grazie.aws.intellij.net/. Logging traffic to them shows JetBrains AI use outside the governed route, and blocking them is the documented network-level way to switch the service off.
• Endpoint and repository signals: watch for new or changed .junie/ files, .aiignore removals, and edits to build scripts in pull requests. Endpoint tooling that records process creation from the IDE shows which commands an agent actually ran.

Hardening baseline

The baseline below assumes AI Enterprise. Smaller teams on individual or team licences can apply the project file, allowlist and network items directly.

1. Classify repositories first. Decide which codebases may use cloud models, which may only use your own provider or an on-premises endpoint, and which get no AI. Add an empty .noai file to the root of the last group; it disables all AI Assistant features for that project in any IDE that opens it.
2. Pick providers per data class. Configure one or more providers and set defaults. For code that must stay in your cloud tenancy, use your own Azure OpenAI, Vertex AI or Bedrock account, or an OpenAI compatible endpoint inside your network.
3. Keep detailed data collection off. In the AI Enterprise General tab leave Allow detailed data collection disabled for each profile unless there is a documented reason. When it is disabled in IDE Services, that choice applies to every user in the profile.
4. Lock down MCP and agents. Switch off Allow users to add MCP in their IDE and Allow all agents, then add approved servers and agents to the profiles that need them.
5. Enable Junie per profile. Turn Junie on for a pilot profile first. Publish a starter allowlist with exact test and build commands, and make Brave Mode a policy exception.
6. Add .aiignore to every sensitive repository. Enable it under Settings | Tools | AI Assistant | Project Settings and list secrets files, customer data fixtures and key material. The documentation notes that some other common AI ignore files are also honoured, and that only file contents are protected: names stay visible.
7. Review agent instructions as code. Junie reads .junie/AGENTS.md first, otherwise the root AGENTS.md with .junie/playbook.md and .junie/rules/*.md. Put these paths under CODEOWNERS so a pull request cannot quietly change what the agent is told to do.
8. Restrict the ungoverned route. Use the JetBrains Account option that allows JetBrains AI only for your IDE Services instance, and log or block the AI Assistant base URLs from networks where governed use is required.
9. Keep the IDE current. Apply JetBrains security updates promptly and track the vendor's Fixed security issues page.

Testing and rollback: pilot each profile change with a small group for two weeks, check the analytics and egress logs, then widen. Rolling back is quick: remove the provider from the profile, disable Junie for the profile, or click Disable in the AI Enterprise section to switch AI off for the organisation.

Data handling decisions

JetBrains' data collection notice (version 1.6 when checked) separates behavioural data, which excludes source code and personal data and is not used to train models that generate code or text, from detailed code-related data, which is the full text of prompts, responses and code snippets. For organisational licences detailed data is disallowed by default and can only be enabled by a company administrator; the notice gives a one-year retention period for it and says collected data is stored in the European Economic Area. Record your choice in the supplier assessment alongside the terms of the provider you route to. See the AI and GDPR Guide where personal data may appear in code or prompts.

Common misconfigurations

• Profiles enabled before repositories are classified: AI arrives on every project at once. Add .noai and .aiignore to sensitive repositories before the profile goes live.
• Self-service MCP left on: developers add community servers with broad tokens. Turn off Allow users to add MCP in their IDE and assign reviewed servers instead.
• Broad allowlist prefixes: a prefix such as git, npm or curl allows every subcommand. Allow the specific subcommands and keep publish, push and network fetches on ask.
• Brave Mode as the default habit: it removes the approval step and reaches .aiignore protected files. Make it an exception for disposable environments only.
• Secrets in committed MCP config: tokens in .junie/mcp/mcp.json spread with every clone. Use an environment file outside the repository.
• Provider keys with wide cloud permissions: a Bedrock or Vertex identity that can do more than invoke the selected models becomes a cloud foothold. Scope it to model invocation and rotate it.

Framework mapping

Practitioner checklist

• Classify repositories into cloud AI, own-provider only and no AI, and add .noai to the last group.
• Enable AI Enterprise per profile, starting with a pilot, and set a user limit.
• Choose providers per data class and keep their credentials in a secrets manager with rotation dates.
• Leave Allow detailed data collection off unless a recorded decision says otherwise.
• Turn off Allow users to add MCP in their IDE and Allow all agents; assign approved servers and agents to profiles.
• Publish a Junie starter allowlist with exact subcommands, keep readSecretFile and readOutsideProject on ask, and treat Brave Mode as an exception.
• Add .aiignore to sensitive repositories and put .junie/ and AGENTS.md under CODEOWNERS.
• Restrict JetBrains AI to your IDE Services instance and monitor the AI Assistant base URLs.
• Review IDE Services analytics and provider usage monthly, and administrators quarterly.

Standards and references

• JetBrains: Managing AI Enterprise (IDE Services Cloud)
• JetBrains: IDE Services data collection
• JetBrains: Product data collection and use notice
• JetBrains: Disable or restrict AI Assistant
• JetBrains: Use custom and local models in AI Assistant
• JetBrains: Junie IDE plugin
• JetBrains: Junie CLI action allowlist
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: AI IDE and Coding Agent Security Guide · MCP Security Guide · JetBrains TeamCity Hardening Guide · Generative AI Data Loss Prevention Guide · API Key Management Guide