Explyt AI Agent

AI Security Review

Evidence context: threat category none; evidence quality moderate.

What the plugin is

Explyt AI Agent (version 5.20.0-IJ-262-mp, publisher Explyt, 9,761 users on the JetBrains marketplace) adds an AI coding assistant to the IDE. It ships a .NET bootstrap layer under bootstrap/dotnet/, which is where both critical findings land.

Filesystem and process access

A coding agent reads and writes project files, launches a local agent process and talks to a model backend. That is the stated job, and no finding describes workspace reads paired with an outbound upload. The plugin declares no IDE permissions and the scan lists none. Nothing matches a path outside the project: no reads of ~/.ssh, no .env access, no .git/config lookup, no call into the IDE's credential store. The secret category is empty across all 3,151 findings.

Network endpoints

The endpoint list is not a list of contacted hosts. Entries like "0k.bs", "0c.fr", "1alpha-2-3-map.properties", "0x04g-testing-cryptography.md" and "0좄k.nc" mix country-code suffixes with numeric prefixes, unicode characters and file names. That pattern comes from a bundled public suffix table and locale resource files, both normal in a plugin that parses URLs and ships translations.

The obfuscation findings

OBFUSCATION-supply_chain_binary fires on bootstrap/dotnet/Plugin.dll and bootstrap/dotnet/Rd.dll and marks them critical. Those are .NET assemblies run through a commercial obfuscator. This is the strongest argument against treating the scan as noise: obfuscation hides behaviour, and a plugin with workspace access running obfuscated binaries cannot be fully audited from static evidence alone.

Three things weigh against that reading. .NET obfuscation is routine when shipping a commercial runtime without handing over source. The DLLs sit in a bootstrap directory, matching how IDE plugins stage an agent binary. And a hidden payload needs somewhere to go: a download during activation, a credential read, a host it reports to. The scan found none of those. Malware signatures, malware, secrets, dependency and tool-poisoning all came back empty, and the 659 code-smell matches are the generic fetch, exec, fs and process.env patterns that fire on any JavaScript of this size. The 2,102 IoC hits are medium-severity extractor output drawn from the same bundled data files, not from contacted infrastructure.

If something were hidden in those assemblies, the surrounding evidence would show the handoff. It does not.

Key Reasons

• Zero malware, malware-signature, secret, dependency or tool-poisoning findings across 3,151 total matches
• The only critical findings are OBFUSCATION-supply_chain_binary on commercial .NET assemblies at bootstrap/dotnet/Plugin.dll and bootstrap/dotnet/Rd.dll
• The endpoint list ("0k.bs", "0좄k.nc", "1alpha-2-3-map.properties", "0x04g-testing-cryptography.md") is a public-suffix and locale data dump, not contacted hosts
• The 659 code-smell matches are generic Node.js fetch/exec/fs/process.env patterns with no credential-read or exfiltration path
• Established JetBrains publisher with 9,761 users; an AI coding agent reading and writing workspace files is its stated function

False Positive Considerations

• IoC extractor generating 2,102 medium-severity hits from bundled public-suffix and locale resource files
• Code-smell YARA rules matching generic Node.js patterns (fs, exec, fetch, process.env)
• .NET assembly obfuscation in commercial build output classified as supply_chain_binary
• Endpoint list contains non-resolvable fragments with country-code suffixes, numeric prefixes and unicode characters

Reviewed 2026-10-10; recommended action: no action; model confidence 76%.