For a given buffer, AMSI might provide a corresponding backing file name. ENS can use the file name to decide whether a given file or script should be excluded from scanning.

The buffer attributes provided by AMSI are heavily application-specific. For example, JavaScript and VBScript engines tend to consistently provide a file name, and as a result, ENS can often honor exclusions. But, AMSI attributes provided for a PowerShell buffer aren't consistent in the same way. Sometimes, a file name is returned as an AMSI_ATTRIBUTE, whereas sometimes it isn't. Even if a PowerShell script isn't elected to be scanned through an on-access scanner exclusion, ENS receives a second scanning request that doesn't contain a file name.

When the buffer comes for scanning, the AMSI_ATTRIBUTE_CONTENT_NAME attribute that comes with the buffer doesn't always provide a corresponding file name. Sometimes, the file name corresponds to an internal script name (for example, Microsoft.PowerShell.Utility.psd1). As a result, it isn't possible to reliably correlate the buffer with the file name. Microsoft considers this behavior by design, as their documentation for AMSI_ATTRIBUTE enumeration states that the content name value might contain several different identifiers, among which the file name is just one option.

PowerShell doesn't track the original source of all script blocks that run. For example, a script file that contains text scripts submits those text script blocks to AMSI. But, PowerShell doesn't contain the file name of the script file where the text script blocks are defined.

This behavior is expected according to Microsoft's design of AMSI. It's not possible for ENS exclusions to reliably correlate the buffer with a file name.