Add-Type

What Add-Type Changes in a PowerShell Session

Add-Type is a runtime extension mechanism, not just a convenience wrapper. It lets a script bring in new .NET types or compile source code on the fly, which can make an automation task possible without rebuilding the whole application. That flexibility is powerful, but it also means the session can gain new behavior, new execution paths, and new dependencies at runtime.

Because the cmdlet changes what the current session can do, it sits at the boundary between scripting and code execution. In practice, that means the security posture of the script is no longer limited to the original PowerShell commands, it now includes whatever code is introduced, compiled, or loaded through the cmdlet.

Why Add-Type Matters for Security

From a security perspective, Add-Type expands the blast radius of a trusted script. If an attacker can influence the source code, assembly path, or surrounding script logic, they may be able to introduce unmanaged calls, custom classes, or additional runtime capability that the original author did not intend. That makes source integrity and script trust especially important.

The cmdlet is also relevant because it can bridge into lower-level APIs and compiled code. That does not make it inherently malicious, but it does mean reviewers should treat it as a higher-risk construct than ordinary variable or function usage. The main question is not whether Add-Type is allowed, but whether the added code is expected, reviewed, and necessary for the task at hand.

Common Uses and Operational Trade-offs

Developers and administrators use Add-Type for legitimate reasons: creating small helper types, calling platform APIs, or loading assemblies that provide functionality PowerShell does not natively expose. This can reduce dependency on external binaries or modules and can simplify a workflow when the code is tightly controlled.

The trade-off is that runtime compilation and type loading can reduce transparency. A script may appear simple on the surface while actually embedding significant logic inside a type definition or a compiled code block. That makes code review, logging, and change control more important, especially in administrative automation, build pipelines, or scripts that run with elevated privileges.

What Reviewers Should Look For

Security review should focus on where the type source comes from, whether it is static or dynamically constructed, and whether the script loads only the types it genuinely needs. Add-Type is not risky because it exists; it is risky when it hides behavior, widens execution authority, or introduces opaque code paths that are hard to inspect later.

A practical review also checks whether the script is compiling code on every run, importing unnecessary assemblies, or using the cmdlet as a workaround for a design problem that should be solved elsewhere. Those patterns can create maintainability issues as well as security blind spots.

Risk and Threat Considerations

Add-Type can become a code-injection or privilege-abuse vector when untrusted input influences the generated source, the loaded assembly, or the script that invokes it. The security concern is not the cmdlet itself, but the fact that it can turn a scripting surface into a code-loading surface with much less visibility than a normal compiled application.

Failure mechanism: An attacker or careless operator supplies malicious or altered source, and the session compiles or loads it with the permissions of the running process. That can introduce arbitrary behavior, enable unmanaged API calls, or create a persistence-friendly execution path inside administrative tooling.

Impact: The result can be command execution, expanded local privilege abuse, hidden functionality in automation, or harder-to-detect compromise of scripts that otherwise look benign. Review of script provenance, input handling, and loaded code becomes essential when this cmdlet is present.

Practitioner Guidance

Why practitioners should care: Use Add-Type only when runtime type creation or assembly loading is genuinely required, because it changes the trust boundary of the script. Code that compiles or loads additional types should be treated as part of the security-sensitive attack surface, not as a harmless scripting shortcut.

What to watch for: Pay close attention to dynamically built source strings, unexpected assembly paths, and scripts that rely on Add-Type to hide complex logic. Those patterns deserve the same level of scrutiny you would apply to any other code supply chain issue inside an automation workflow.

Related resources from NHI Mgmt Group

• When do passkeys reduce risk, and when do they just add another credential type?
• PowerShell Add-Type
• When should organisations add continuous controls for AI agents?
• When does an independent control layer add more value than native controls?