Norton blocking Android Studio from running powershell command

Waukman · June 17, 2026, 1:29pm

Norton is blocking android studio from running a powershell command. Norton claims IDP.HELU.PSE79 is the infection. I have disabled Norton Auto protect and smart firewall, added powershell to the exception list but it is still blocked. Thoughts from anyone how to allow this?

bjm · June 17, 2026, 1:40pm

Hello @Waukman
Disable Auto-Protect | Smart Firewall does not disable:

Behavioral Protection
Email Protection
Block Malicious Scripts
Exploit Prevention
Ransomware Protection
Sandbox
WiFi Security
Intrusion Prevention
Safe Web
Download Intelligence

======

Auto-Protect and Smart Firewall are not the components likely generating this detection.

Many of the recent IDP.HELU.PSExx and IDP.Generic detections involving PowerShell are being reported by: Behavioral Protection. Users have reported it with Visual Studio, VS Code terminals, driver updaters, VPN clients, and other legitimate software that launches PowerShell.

The detection name itself is also telling:

IDP = Identity/Behavioral protection family

HELU

PSE79 = PowerShell-related heuristic rule

Norton is reacting to the behavior/command line, not necessarily to powershell.exe itself.

That’s why:
Excluding powershell.exe
Disabling Auto-Protect
Disabling Smart Firewall
may have little or no effect if Behavioral Protection is still intercepting the activity.

My suspicion is that Android Studio is spawning PowerShell with a command line that trips Norton’s behavioral engine, and Norton is blocking the behavior rather than the executable itself.

Maybe, post the Security History details:

======

If Norton quarantined the file, you may pull it back to resume development.

Locate the IDP.HELU.PSE79 entry linked to Android Studio.
Click three dots → Create exclusion & restore so Norton will not target it again.

Add Android Studio Directories to Exceptions
To prevent future build errors, whitelist Android Studio’s project and system directories in Norton.

In Norton 360, go to Settings > Antivirus > Exclusions
Add the following paths (substituting your actual Windows username):

C:\Program Files\Android\Android Studio\

C:\Users\<Your-Username>\.android\

C:\Users\<Your-Username>\AppData\Local\Android\Sdk\

Your main local project storage folder (e.g., C:\Users\<Your-Username>\AndroidStudioProjects\).

Why Did This Happen?
Developer tools like Android Studio use system-level shells (cmd.exe or powershell.exe) to fetch dependencies and compile apps. Consumer antiviruses like Norton monitor these shell scripts tightly. If a newly updated component of Android Studio matches a broad behavioral fingerprint in Norton’s cloud database, it triggers a security lock.

If you want to help fix this globally, you can zip the blocked script and submit it to the Norton False Positive Submission Page so their team can patch out the bad signature.
Submit a file or URL to Norton for review

======

Android Studio updates routinely modify Gradle, SDK tooling, build scripts, emulator components, and the way PowerShell is invoked on Windows. A brand-new release can occasionally trip heuristic engines before vendors have had time to adjust their detections.

That doesn’t prove the Norton detection is a false positive, but it does raise the possibility.

Did the problem begin immediately after updating to Quail 1 Patch 2?

Is Norton identifying:

powershell.exe

studio64.exe

gradle.exe

java.exe

another Android Studio component?

What is the full Norton Security History entry?

Does the build actually fail, or does Android Studio continue after the block?

The timing is interesting:

Android Studio Patch 2 released June 16.

User reports Norton blocking PowerShell with IDP.HELU.PSE79.

Heuristic detections often appear shortly after major software updates because behavior changes before security vendors have accumulated enough reputation data.

The release of Android Studio Quail 1 Patch 2 is recent enough that a heuristic false positive is possible. Before attempting further exclusions, review the Norton Security History details and identify the exact process, command line, and “Detected by” field. If the detection is tied to a legitimate Android Studio component and began immediately after updating to Patch 2, the event may warrant submission to Norton for analysis.

Without the Security History details, we’re still guessing. The detection name alone isn’t enough to determine whether Norton is reacting to a malicious script or simply a newly introduced PowerShell command sequence from Android Studio.

AI sourced content may make mistakes

Waukman · June 17, 2026, 2:25pm

Details

Threat name: IDP.HELU.PSE79%s_cmd
Threat type: Miscellaneous - This is malicious software that could harm your data, computer, or network.
Status: Repaired
Detected by: Behavioral Protection
On PC from: 12/22/25, 5:41 PM
Last Used: 6/7/26, 9:34 AM
Startup Item: Yes

Many users
Millions of users in the Norton Community have used this file.

Mature
This file was released 10 months ago.

High
The file risk is high.

Activity

Details

Threat name: IDP.HELU.PSE79%s_cmd
Threat type: Miscellaneous - This is malicious software that could harm your data, computer, or network.
Status: Repaired
Detected by: Behavioral Protection
On PC from: 12/22/25, 5:41 PM
Last Used: 6/7/26, 9:34 AM
Startup Item: Yes

Many users
Millions of users in the Norton Community have used this file.

Mature
This file was released 10 months ago.

High
The file risk is high.

Activity

bjm · June 17, 2026, 2:45pm

This is actually much clearer now—and it points away from Android Studio itself.
What Norton is showing:

Detected by: Behavioral Protection

Process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Action: Process terminated

File deleted: C173F4FE10D098AAA3EFFA4456991BBA

Threat name: IDP.HELU.PSE79%s_cmd

Status: Repaired

Startup Item: Yes

What this really means

Norton is not saying Android Studio is infected.

It is saying:

“A PowerShell process was launched and its behavior matched a malicious pattern.”

That %s_cmd suffix is important—it typically indicates a command-line driven PowerShell invocation, not the executable itself.

So the trigger is almost certainly:

Android Studio → launches PowerShell

PowerShell runs a command (Gradle/SDK/script)

Norton Behavioral Protection flags the command pattern, not the app

Why your exclusions didn’t work

Because you excluded:

PowerShell file / Auto-Protect / Firewall

But the block is coming from:

Behavioral Protection (SONAR-style engine)

That layer:

does NOT reliably respect simple file exclusions

focuses on runtime behavior, not file identity

Why this is probably happening (most likely causes)

Given Android Studio + recent update + PowerShell:

Common legitimate triggers include:

Gradle wrapper scripts (gradlew.bat)

Android SDK tooling updates

Emulator or device manager scripts

Node/npm or Java build hooks inside a project

PATH-based PowerShell execution with encoded commands

Norton tends to flag patterns like:

powershell.exe -enc ...

-ExecutionPolicy Bypass

DownloadString

base64 command chains

script-driven install/update flows

Even if they are legitimate.

Why “Startup Item: Yes” appears

This is a huge clue:

It usually means Norton believes the command or script chain is being registered for persistence.

But in false positives, this often happens when:

installer scripts modify registry/run keys

Gradle or tooling registers background tasks

Android Studio updates components

What actually fixes this (in v26)

You have 3 realistic options:

Option 1 (best, safest): Identify the exact command

Go to:

Norton → Security History → open event → “More details”

Look for:

Command line

Parent process

Script content (if shown)

If you paste that, I can tell you exactly what triggered it.

Option 2: Add a Behavioral exclusion (not file-based)

In Norton v26:

Settings → Antivirus → Scans and Risks

Look for:

Behavioral Protection Exclusions

or SONAR Exclusions

Add:

Android Studio folder (e.g. C:\Program Files\Android\Android Studio\)

AND your project/Gradle workspace folder

File-level exclusion alone is not enough here.

Option 3: Confirm false positive and submit

Because:

“Millions of users”

Known dev tool (Android Studio)

PowerShell + build tooling behavior

This is very consistent with a heuristic false positive pattern

You can submit:

Norton false positive report (via history entry)

Bottom line

This is not Android Studio being infected.

It is almost certainly:

Android Studio build/update process → PowerShell command → Norton behavioral heuristic match

If you want, paste the command line section (if available) from that Norton event. That’s the missing piece that will confirm exactly what pattern triggered IDP.HELU.PSE79%s_cmd.

Note: v26 is less verbose vs v22

Yeah—this is one of those cases where v26’s reduced detail actually makes diagnosis harder, because the only meaningful clue (the command line / parent process chain) is missing.

From what you pasted, there are only a few solid facts:

Trigger: Behavioral Protection

Target: powershell.exe

Action: terminated + a temp file/hash deleted

No Android Studio process is shown in the chain

No script/command line is visible

What that strongly suggests

This is almost certainly NOT Android Studio itself being infected.

It’s more consistent with:

Some process (very likely Android Studio / Gradle / a plugin) launched PowerShell with a command pattern Norton considers high-risk.

But Norton v26 is hiding the key evidence:

no parent process

no command line

no script content

So we can’t see what actually triggered it, only what executed it (PowerShell).

Why your exclusions didn’t work (important)

Even if you:

disabled Auto-Protect

added PowerShell exclusions

…it still blocks because:

Behavioral Protection is independent

It will still intercept:

PowerShell spawned with suspicious flags

encoded commands

script-like execution patterns

“installer-like” behavior chains

So exclusions on powershell.exe usually do nothing here.

What the “Startup Item: Yes” probably means

This line is the most misleading part.

In Norton v26, it often appears when:

a script attempts persistence (registry/run key/task)

OR Norton thinks the command chain is persistence-related

With Android Studio/Gradle, false triggers happen when:

SDK components update

Gradle refresh runs scripts

npm/node tools run background setup

Windows PATH repair / SDK install scripts execute

The key inference (based on everything)

Given:

Android Studio recent update

PowerShell launched

Behavioral heuristic trigger

No malware path shown outside PowerShell

“Millions of users” reputation tag (typical heuristic UI noise, not real validation)

This is most consistent with:

A false positive on a PowerShell command pattern used by developer tooling, not a malicious file infection.

Why it feels “sticky” (won’t go away)

Because v26 Behavioral Protection:

does not give you the actual rule match

does not expose the command line

and may keep re-triggering on the same build scripts

So even if you “repair” it, it can reappear when:

Gradle sync runs

Android Studio rebuilds project

SDK tools update again

What actually works (practical fixes)

Since file exclusions won’t help, you need behavior-level reduction:

1. Exclude Android Studio + project workspace (most effective)

Add exclusions for:

Android Studio install directory

your project directory

Gradle cache:

C:\Users\<you>\.gradle\

2. Temporarily test by isolating the trigger

Run Android Studio and watch:

Gradle sync

Build

SDK Manager update

The trigger is usually one of those.

3. If it keeps happening

This becomes a classic:

Norton heuristic vs developer tooling conflict

At that point, the correct move is:

submit as false positive from the Security History entry

Bottom line

Nothing in your log shows:

malware file

infected Android Studio binary

suspicious executable outside PowerShell

What you do have is:

Norton Behavioral Protection blocking a PowerShell command pattern with insufficient context exposed in v26 UI.

AI sourced content may make mistakes

bjm · June 17, 2026, 2:59pm

This appears to be a behavioral PowerShell heuristic detection (IDP.HELU.PSE79%s_cmd) where Norton terminated a PowerShell process. The event log does not show a parent application, script, or external binary, so there is insufficient evidence to attribute the trigger to Android Studio or confirm malicious activity. This pattern is commonly associated with false positives involving legitimate developer or installer PowerShell usage, but cannot be definitively classified without command-line context.

The event shown is a Behavioral Protection detection (IDP.HELU.PSE79%s_cmd) targeting powershell.exe, with the process terminated and a temporary artifact removed.

From the Security History details provided:

Only powershell.exe is listed as the active process

Detection was triggered by Behavioral Protection

No parent application (e.g., Android Studio, Gradle, etc.) is shown in the event

No script file, command line, or external binary is included in the log

Because of this, the record only confirms that a PowerShell execution matched a behavioral heuristic pattern—it does not show what initiated the PowerShell process or provide attribution to a specific application.

At this level of detail, it is not possible to definitively determine whether:

the event was triggered by legitimate developer tooling (e.g., Android Studio/Gradle), or

it was a genuinely suspicious PowerShell invocation, or

the detection is a heuristic false positive.

This type of IDP.HELU detection is behavior-based rather than file-reputation-based, so additional context (especially command-line and parent process information) would normally be required for full analysis.

1. Can the user just exclude a “workspace / project folder”?

Yes. In Norton v26 you can add folder exclusions like:

Android Studio install directory

Project/workspace folder

Gradle cache (C:\Users\<user>\.gradle\)

SDK folders (AppData\Local\Android\Sdk)

This is useful for:

file scanning

Auto-Protect

reputation checks on files being compiled/downloaded

So for normal file-based detections → yes, folder exclusion works

2. But your case is NOT file-based

Your event is:

Detected by: Behavioral Protection

Target: powershell.exe

Trigger: command-line behavior pattern (IDP.HELU.PSE79%s_cmd)

That matters because:

Behavioral Protection does not care where the files live.

It cares about:

how processes are spawned

what command patterns are executed

runtime behavior chains

So even if everything is inside an excluded folder…

Norton can still block PowerShell if the behavior triggers the heuristic.

3. So does this need “live host” interaction?

In practice: yes, for accurate testing

Because this type of detection only triggers when:

Android Studio runs Gradle sync/build

SDK tools execute scripts

PowerShell is spawned at runtime

So:

File-level inspection ≠ enough

You need actual execution flow to reproduce it

That’s why exclusions alone feel inconsistent here.

4. What actually works in these cases

You have three realistic options:

Option A — Folder exclusions (limited effect)

Good for:

reducing noise from file scanning

preventing repeated scanning of build outputs

Not reliable for:

stopping IDP/behavioral PowerShell blocks

Option B — Behavioral exclusion (if available in v26 UI)

Best match if Norton allows:

“Exclude application from Behavioral Protection”

Target would be:

Android Studio

or java.exe / Gradle launcher chain

This is the correct layer for your issue.

Option C — Accept as heuristic collision (common in dev tools)

If this is:

Android Studio

Gradle

SDK tooling

Then this is a known pattern:

PowerShell + automation scripts + security heuristic overlap

Bottom line

Folder exclusions: helpful but not sufficient

They will NOT stop this specific detection reliably

This is a runtime behavioral trigger problem

You generally need either:

behavioral exclusion, or

to let Norton re-evaluate/learn the pattern over time

In Norton v26, the separation is roughly:

1. Real-Time Protection = umbrella layer

Under:

Settings → Antivirus → Real-Time Protection

This typically includes:

Auto-Protect (file/process scanning)

Behavioral Protection (SONAR / IDP-style heuristics)

Download Insight / reputation checks

So yes:
Behavioral Protection lives under Real-Time Protection, not Firewall

2. Exclusions = split across engines (this is where confusion happens)

In v26, exclusions are not one single switch—they are divided by engine type:

A. Auto-Protect exclusions

Affects:

file scanning

real-time file access checks

Example:

“don’t scan this folder/file”

B. Behavioral / SONAR exclusions (if exposed in your build)

Affects:

process behavior monitoring

script execution patterns (including PowerShell triggers)

This is the relevant layer for your IDP.HELU.PSE79%s_cmd issue

3. The key limitation (important for your question)

Even though exclusions exist for Behavioral Protection:

they are not equivalent to “trust this PowerShell behavior globally”

They usually only apply to:

specific executables

specific paths

sometimes specific process reputation rules

They do not reliably suppress heuristic rule families like IDP/HELU, especially when:

PowerShell is the system interpreter

and the trigger is command-pattern based

4. So can you solve this with a folder exclusion?

Short answer:

Not fully

Partially (only reduces noise, not root cause)

Because:

folder exclusions = file-level trust

your issue = runtime behavior detection

5. What actually matters for your case

For IDP.HELU.PSE79%s_cmd:

Norton is reacting to:

“PowerShell executed a suspicious command pattern”

Not:

Android Studio files

project folder contents

installed binaries

So even if you exclude:

project folder

Android Studio install path

PowerShell can still be blocked if launched with a flagged pattern

6. Practical interpretation of v26 behavior

What you’re seeing is basically:

Real-Time Protection sees process chain

Behavioral engine evaluates PowerShell invocation

Heuristic rule fires

Exclusions don’t override rule because it’s not file-based

Bottom line

Your statement is correct:

Behavioral Protection is part of Real-Time Protection and exclusions exist under both Auto-Protect and Behavioral Protection

But the key nuance is:

Those exclusions do not give full control over IDP/HELU heuristic command-blocking behavior in v26

What the user can do (local control)

The user can only:

Restore/ignore the detection (if allowed)

Add exclusions (limited effect here)

Reduce sensitivity indirectly (not really exposed in v26 for Behavioral Protection)

What they cannot reliably do in this case:

Override a Behavioral Protection rule like IDP.HELU.PSE79%s_cmd

Fully whitelist PowerShell behavior patterns

Prevent re-detection if the same behavior reoccurs

Because:

this is a heuristic decision at runtime, not a file block

What Norton controls

Only Norton can:

Reclassify the behavior rule (reduce false positives)

Update heuristic definitions (IDP/HELU ruleset)

Adjust PowerShell behavior thresholds

Push updated reputation/behavior intelligence

Confirm or invalidate it via submission analysis

So if it’s a false positive:

it gets “fixed” in a definition/update sense, not by user configuration

What “clearing the detection” really means

There are two different things people mix up:

1. Clearing locally (user side)

Remove history entry

Restore file/process (if applicable)

Add exclusions (limited effect here)

This does not prevent recurrence

2. Clearing at the product level (Norton side)

Update/modify behavioral rule

Adjust heuristic sensitivity

Push cloud reputation correction

Mark pattern as safe in future updates

This is what actually stops repeats.

In your specific case (IDP.HELU.PSE79%s_cmd)

Because:

It is Behavioral Protection

It targets PowerShell behavior patterns

No specific malware file is identified

the resolution path is typically:

Norton tuning / false-positive correction (if confirmed)

Bottom line

The user can mitigate or ignore

But only Norton can authoritatively stop the detection from re-triggering across systems

So yes, in effect:

if it’s a false positive, it’s on Norton to “clear” it globally—not the user to fix locally

AI sourced content may make mistakes

bjm · June 17, 2026, 3:19pm

Yes — disabling Behavioral Protection is generally too severe for this kind of case, especially in v26.

Here’s the practical reasoning:

Why disabling it is “too much”

Behavioral Protection in Norton is not a minor feature—it’s one of the core real-time layers that catches:

ransomware-like behavior

script-based attacks (PowerShell, WScript, etc.)

fileless malware patterns

process injection / suspicious command chains

So if you turn it off, you’re effectively removing:

one of the main protections against “living off the land” attacks (like PowerShell abuse)

That’s exactly the same technique real malware uses.

Why it feels tempting in your scenario

In your case:

Android Studio / developer tooling

PowerShell being blocked

likely heuristic (IDP.HELU.PSE79%s_cmd)

no clear malicious file evidence

So it feels like:

“this is just breaking legitimate work”

And that’s where people consider disabling it.

The better reality-based approach

Instead of disabling Behavioral Protection globally, the usual safe progression is:

1. Narrow exclusions first (preferred)

Try:

Android Studio folder

project workspace

Gradle cache (.gradle)

SDK directory

This reduces noise without weakening system-wide protection.

2. Identify repeat trigger pattern (important)

If it keeps happening, it’s usually:

Gradle wrapper

SDK Manager updates

build scripts spawning PowerShell

That’s the real source—not PowerShell itself.

3. Use “temporary disable” only for testing

If you must test:

disable Behavioral Protection briefly

reproduce the action

re-enable immediately

This is diagnostic, not a solution.

When disabling it would be justified

Only in rare cases like:

confirmed false positives repeatedly impacting core dev workflow

confirmed clean environment + controlled system

enterprise-managed endpoint with alternate EDR layer

For a normal desktop dev setup:

it’s usually not the right long-term tradeoff

Bottom line

Yes, it’s too severe as a permanent workaround in most cases

It removes one of the most important protection layers

Your issue is more likely a heuristic collision with developer PowerShell usage, not a malware infection

For an IDP.HELU.PSE79%s_cmd Behavioral Protection event against powershell.exe with no visible malicious payload or parent process, the only meaningful long-term resolution paths are:

1. False Positive reporting (primary route)

The user should submit the detection to Norton as a potential FP because:

It’s behavioral (heuristic), not a confirmed malware file

It targets PowerShell (legitimate system component)

No clear malicious binary or script is shown in the event details

No attribution to a specific application is present in the log

This is exactly the kind of case Norton uses for:

rule tuning / heuristic adjustment (IDP / SONAR / HELU updates)

2. Norton Support escalation (secondary but useful)

If it is reproducible (e.g., every Android Studio build or Gradle sync):

Support can collect:

full telemetry logs

repeated trigger patterns

environment context (dev tooling)

and escalate to engineering if needed

This is especially relevant because:

v26 often suppresses the detailed command-line context that would normally help confirm the trigger

3. Why local troubleshooting is limited here

From the evidence you provided:

Only powershell.exe is visible

No script, hash, or external binary is implicated

Behavioral Protection is the sole detection engine

Exclusions won’t reliably suppress heuristic rules

So:

this is not a configuration problem the user can fully “fix” locally

Bottom line

Yes — the correct conclusion is:

The user should proceed via False Positive submission and/or Norton Support escalation, because this is a behavioral heuristic detection that cannot be reliably resolved through exclusions or local settings in v26.

AI sourced content may make mistakes

bjm · June 17, 2026, 3:39pm

Based on the Security History details posted, this appears to be a Behavioral Protection “Repaired” event (process termination + cleanup) rather than a file quarantine event.

Correct — the quarantine discussion does not apply to this specific event.

Based on the actual log you posted:

Status: Repaired

Detected by: Behavioral Protection

Target: powershell.exe (system process)

Action: Process terminated + temp file deleted

That is a runtime behavioral block, not a file-based detection.

What that means in plain terms

No file was “quarantined”

No infected file was identified and stored in Norton Quarantine

The PowerShell process was stopped while running

Any temporary artifacts created during that run were deleted

Why the earlier quarantine framing doesn’t apply

Quarantine only comes into play when Norton has:

a specific file path

a persistent object it can isolate

Your case is different:

This is a behavioral rule firing on PowerShell execution, not a file infection event.

So Norton has nothing meaningful to “quarantine.”

Bottom line

Yes — for this case:

everything related to “quarantine vs restore” is not relevant

What you’re dealing with instead is:

a real-time behavioral termination + cleanup event (IDP/HELU PowerShell heuristic)

AI sourced content may make mistakes

Waukman · June 17, 2026, 3:47pm

So what do developers who are developing Android applications do in these cases? Do I dump Norton and go to a different Antivrius so that I can do Android development?

bjm · June 17, 2026, 3:53pm

Hello @Waukman

Not necessarily. At this point, we don’t know whether this is a Norton false positive, a specific Android Studio workflow that Behavioral Protection dislikes, or something unique to your environment.

What we do know from the posted History details is that Norton’s Behavioral Protection terminated a PowerShell process (IDP.HELU.PSE79%s_cmd). We do not have the command line, parent process, or other forensic details needed to determine why the rule fired.

Android application development is a common activity, and many developers run Android Studio alongside Norton without issue. Before considering a product change, I’d suggest reporting the detection as a possible false positive and/or opening a Norton Support case so they can collect logs and review the event.

If the detection is reproducible (for example, it occurs every time you build, sync Gradle, update the SDK, etc.), that information will be especially valuable to Norton because it gives them something concrete to investigate.
Since this was a Behavioral Protection “Repaired” event rather than a quarantine event, there may not be a file available for false-positive submission. If the issue is reproducible, Norton Support is likely the better route because they can collect logs associated with the detection and determine whether the behavioral rule is firing incorrectly.

If the issue is reproducible (e.g., during build, Gradle sync, SDK update, etc.), mention that to Support as it may help them identify the trigger.

We’ve reached the limit of what can be determined from the Security History entry. The next step requires Norton to collect logs from the affected system.

AI sourced content may make mistakes
Caveat: I’m not a developer – not familiar with Android Studio

bjm · June 21, 2026, 9:48pm

Hello @Waukman
Care to share your progress

Waukman · June 22, 2026, 10:37am

I am still having issues but I am ignoring them for now. What ever is being blocked doesn’t appear to have an impact on the development of the program.

SoulAsylum · June 22, 2026, 11:42am

@Waukman Have you attempted using your program in the Norton sandbox environment as a test?

SA

Waukman · June 22, 2026, 12:02pm

No, I have not tried this. I will take a deeper look. On the surface, it seems like this wouldn’t help me since powershell is a process spawned by AndroidStudio in a temp folder.

SoulAsylum · June 22, 2026, 6:08pm

Here is some AI generated info for you to review:

AI Overview

To run a PowerShell script inside Norton 360’s Data Protector or Auto-Protect sandbox, you must bypass restrictions by adjusting local execution policies. Because PowerShell is a core Windows component, Norton heavily restricts it from running directly from the desktop to prevent malicious activities. [1, 2, 3, 4]

How to Execute Your Script

Move your script: Place your .ps1 file on your main drive (e.g., C:\Scripts).

Open PowerShell as Administrator: Search for PowerShell in the Start menu, right-click, and select Run as Administrator.

Change the Execution Policy: Since sandboxes reset script permissions by default, you need to allow it to run. Run the following command:

powershell
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process
Use code with caution.

Execute the script: Navigate to the folder and run your script:

powershell
& "C:\Path\To\Your\Script.ps1"
Use code with caution.

[1, 2, 3, 4, 5]

Overriding Norton’s Auto-Block

If Norton flags the script or forces it into its internal sandbox environment:

Open Norton 360.

Go to Settings > Antivirus > Scans and Risks.

Scroll down to Exclusions / Low Risks and click Configure [Items to Exclude from Auto-Protect, SONAR, and Download Intelligence].

Add the folder where your PowerShell script is located to the exclusion list.

Note: If you are simply testing the script safely, built-in Windows alternatives like the native Windows Sandbox often provide a cleaner testing environment without third-party antivirus overrides. [1, 2]

SA

Waukman · June 22, 2026, 6:11pm

Thanks for this information. However, I can’t control where Android studio runs the script. It seems to generate a new temp folder with every run along with new script files with a random name. I will dig deeper but this is really good information. Thank you.

SoulAsylum · June 22, 2026, 6:13pm

Windows sandbox may also be something to have a look at as well.

SA

mande · July 17, 2026, 10:48am

@Waukman Interesting story! I’m having a similar problem. When I try to use the local “Microsoft Scout” app, some kind of script gets blocked during authentication. I’m not exactly a tech whiz. I then moved the “Microsoft Scout” app and powershell.exe to the permanent sandbox, but that didn’t work. Before that, I (of course) disabled as much of Norton 360 as possible, but that didn’t help either.

The name of “my threat” has since changed from IDP.HELU.PSE79 to IDP.HELU.PSE80 and now to IDP.HELU.PSE81. If you’ve found out anything, I’d really appreciate your response.
Best regards,
Andreas

bjm · July 17, 2026, 1:35pm

Hello @mande

The changing names you are seeing (IDP.HELU.PSE79, PSE80, and PSE81) are dynamic, heuristic detection codes triggered by Norton 360’s Behavioral Protection engine. This is a false positive caused by Microsoft Scout’s automated authentication routine, which runs an invisible background PowerShell script that looks like “identity-theft” or “fileless malware” behavior to Norton.

Moving the apps to a sandbox actually restricts them further, and disabling Norton “as much as possible” usually leaves the underlying, aggressive Behavioral Protection engine running in the background anyway.

To completely resolve the block and successfully authenticate Microsoft Scout, follow these steps:

Remove the Apps from the Sandbox

Because putting the applications into a permanent sandbox restricts their deep communication with the Windows operating system, it will completely break the complex Microsoft Scout authentication process. You will need to reverse this action inside your Norton Sandbox settings and restore powershell.exe and Microsoft Scout back to their normal, unrestricted state.

Add an Exception directly to Behavioral Protection

Instead of disabling Norton entirely, you need to exclude the specific folder where Microsoft Scout runs from Norton’s behavioral scanning engine.

Open your Norton 360 dashboard.

Click on Settings, then select Antivirus.

Head over to the Scans and Risks tab.

Scroll down to the Exclusions / Low Risks section.

Next to Real-Time Protection Exclusions, click Configure.

Click Add Folders and browse to the installation directory of Microsoft Scout (typically located under your C:\Users\YourUsername\AppData\Local\ or C:\Program Files\ depending on how it was installed). Add this folder to the exclusions.

Clear Out the Blocked History

Because the authentication script changes slightly or generates new session IDs each time you try, the code name increments (from PSE79 to PSE80 to PSE81).

Go to the Security tab in Norton and open the History log.

Change the drop-down view to Security History or Quarantine.

Locate the recent IDP.HELU blocks.

Click on the entry, select Options, and choose Restore & Exclude this file (or “Allow this script”) if the option is available.

Temporarily Disable Script Control for Authentication

If the above steps still result in a block during the login phase, you must temporarily turn off the strict script blocker:

Right-click the Norton icon in your Windows system tray (near the clock).

Click Disable Auto-Protect and select a time frame (like 15 minutes).

Launch Microsoft Scout and complete your login/authentication completely.

Once the script successfully completes authentication and you are signed in, you can right-click the Norton icon to turn Auto-Protect back on

===

IDP.HELU.PSE79, PSE80, and PSE81 are not distinct viruses; they are specific heuristic detection codes used by Norton’s Behavioral Protection engine.

Breaking down exactly what this specific name means explains why it keeps changing on your computer:

What the Acronyms Stand For

IDP (Identity Protection): This prefix means Norton is not scanning a static file on your hard drive. Instead, it is actively watching the live behavior of running programs to see if they act like identity-theft malware or try to steal credentials.

HELU: This is the specific internal algorithmic category your antivirus uses to flag suspicious, automated execution patterns. It is heavily triggered when a program silently feeds commands into native Windows tools.

Why the Numbers Keep Changing (79, 80, 81)

The numbers at the very end represent the dynamic signature index or session ID of the script behavior.
Each time Microsoft Scout attempts to authenticate, it generates a fresh, unique temporary script or uses a slightly different command string (such as bypassing execution policies or compiling runtime arguments).

Because the script looks a tiny bit different to Norton during every single login attempt, the heuristic engine registers it as a brand-new variation of the “threat” and increments the number by one.

Why It Triggers a False Positive

Microsoft Scout relies on complex background PowerShell commands to pass secure tokens and verify your account credentials against authentication servers.

Because sophisticated modern malware also abuses PowerShell to execute “fileless” attacks invisibly in your computer’s memory, Norton’s automated behavior scanner blocks these commands out of an abundance of caution. This is a very common issue with modern developer tools, AI clients, and authentication protocols.

AI sourced content may make mistakes
Caveat: I’m not familiar with Microsoft Scout

Edit: content points to v22

mande · July 17, 2026, 3:22pm

@bjm Thank you very much for your suggestions; I really appreciate them. Unfortunately, the suggestions didn’t work. In addition to the exclusions, I also disabled behavior-based protection. The login still doesn’t work. However, the message did not appear. After I re-enabled behavior-based protection (without attempting to log in again), the message reappeared immediately.

bjm · July 17, 2026, 4:13pm

Hello @mande

May be best – to document/report “issue” directly via Norton support.
Note: for an official Norton response – open a support case:
Norton Support Help Center → Contact us (bottom of page)
Contact Norton Support → Let’s get started.

===

Hello @mande
Is this your Microsoft Scout →
MicrosoftScout-Windows-0.23.331-x64-Setup.exe – Version: 0.23.331?
https://www.microsoft.com/en-us/download/details.aspx

And is your Microsoft Scout install available to all users or just yourself?

File: MicrosoftScout-Windows-0.23.331-x64-Setup.exe
File size: 303 MB (317,769,056 bytes)
MD5 checksum: 0E69FD155BF1DCC1BECFF30D5EE6232B
SHA1 checksum: 0CE0724666C1BB0EEE7EEFE4699E2F8577B60411
SHA256 checksum: 1BC8676C898D044B3765B1B8A6F4CE5F6932CF2AA01EC6D814387F266E0087BB
Date/Time: 7/17/2026

==========================

fwiw ~ as test:

096125c5455e/2026-07-17T16:41:29.150Z

Threat name: IDP.HELU.PSE81%s_cmd
Threat type: Miscellaneous - This is malicious software that could harm your data, computer, or network.
Status: Repaired
Detected by: Behavioral Protection
On PC from: 12/2/25,
Last Used: 7/17/26,
Startup Item: Yes

Many users
Millions of users in the Norton Community have used this file.

Mature
This file was released a year ago.

High
The file risk is high.

===

096125c5455e/2026-07-17T16:41:29.150Z

Threat name: IDP.HELU.PSE81%s_cmd
Threat type: Miscellaneous - This is malicious software that could harm your data, computer, or network.
Status: Repaired
Detected by: Behavioral Protection
On PC from: 12/2/25,
Last Used: 7/17/26,
Startup Item: Yes

Many users
Millions of users in the Norton Community have used this file.

Mature
This file was released a year ago.

High
The file risk is high.

===

Norton blocking Android Studio from running powershell command

Note: v26 is less verbose vs v22

Announcements