Build an AI Agent That Can Safely Execute PowerShell Commands

Ask an agent to "restart the print spooler on WKS-4471" and something has to decide, between that sentence and an actual service restarting, whether the command that runs is Restart-Service -Name Spooler or Restart-Service -Name Spooler; Remove-Item C:\Windows\System32\* -Recurse -Force. Both are syntactically valid PowerShell. Both could plausibly follow from an agent reasoning about "fix the print spooler." Only one of them should ever be allowed to execute, and the difference between a system that enforces that and one that doesn't isn't the model, it's the architecture sitting between the model and the shell.

PowerShell is a uniquely dangerous surface to hand an agent, more so than most APIs a tool-calling system typically wraps. It's the primary administrative interface for Windows, Active Directory, Entra ID, Exchange, and most endpoint management tooling, including everything this site has covered about Intune. One PowerShell session, run with the wrong privileges, can read any file, modify the registry, disable Defender, create a scheduled task, or add a domain admin. That's not a flaw in PowerShell, it's the entire point of PowerShell, which is exactly why "let the agent run PowerShell commands" needs a real answer to "which commands, as who, and who's watching," not a prompt asking the model to be careful.

The Layered Architecture

Never Let the Model Write PowerShell Text

The single most important decision in this entire system happens before any of the layers above: the agent is never given a free-text PowerShell parameter to fill in. It's given a fixed menu of named actions with typed arguments.

# WRONG: the model constructs raw PowerShell text
@mcp.tool()
def run_powershell(script: str) -> str:
    """Run a PowerShell script."""
    ...  # this is Invoke-Expression waiting to happen

# RIGHT: the model picks a name and fills typed slots
ALLOWED_ACTIONS = {
    "restart_service": {"params": ["service_name", "computer"], "state_changing": True},
    "get_service_status": {"params": ["service_name", "computer"], "state_changing": False},
    "get_disk_space": {"params": ["computer"], "state_changing": False},
}
 
@mcp.tool()
def run_action(action: str, service_name: str = "", computer: str = "") -> dict:
    """Run a pre-approved administrative action.
 
    Args:
        action: One of: restart_service, get_service_status, get_disk_space
        service_name: Windows service name, required for service actions
        computer: Target computer name
    """
    if action not in ALLOWED_ACTIONS:
        return {"ok": False, "error": f"Unknown action '{action}'"}
    return dispatch(action, service_name=service_name, computer=computer)

dispatch() is the function that turns action="restart_service" into an actual, fixed PowerShell command, Restart-Service -Name $service_name -ComputerName $computer, with $service_name passed as a parameter value, never concatenated into a command string. The model chose which action and which target. It never touched the command's syntax.

Constraining What the Shell Itself Will Run

The tool layer above is one boundary. It's not the only one, because tool-layer code can have bugs, and a second, independent enforcement point matters. This is where JEA, Just Enough Administration, does the actual work.

# AgentOperator.psrc
@{
    VisibleCmdlets = @(
        'Restart-Service',
        'Get-Service',
        @{ Name = 'Get-PSDrive'; Parameters = @{ Name = 'PSProvider'; ValidateSet = 'FileSystem' } }
    )
    VisibleFunctions = @()
    VisibleExternalCommands = @()
}

New-PSSessionConfigurationFile -Path .\AgentEndpoint.pssc `
    -SessionType RestrictedRemoteServer `
    -RunAsVirtualAccount `
    -RoleDefinitions @{ 'DOMAIN\AgentServiceAccount' = @{ RoleCapabilities = 'AgentOperator' } }
 
Register-PSSessionConfiguration -Path .\AgentEndpoint.pssc -Name 'AgentOps'

Invoke-Command -ComputerName WKS-4471 -ConfigurationName 'AgentOps' `
    -ScriptBlock { Restart-Service -Name $using:ServiceName }

Constrained Language Mode as a Backstop

JEA sessions run in Constrained Language Mode by default, which is worth understanding on its own, because it's what actually neutralizes the more creative escape attempts. Full PowerShell language mode allows arbitrary .NET method calls, COM object creation, and script block manipulation, which is exactly the toolkit an attacker (or a manipulated agent) would reach for to escape a cmdlet allowlist. Constrained Language Mode disables all of that, permitting only the approved cmdlets and basic language elements, so even a technically creative attempt to reach outside the sandbox from inside an allowed cmdlet's parameters has nowhere to go.

Human Approval, Tied to Blast Radius

Not every action in ALLOWED_ACTIONS deserves the same gate. get_service_status is read-only and safe to auto-approve. restart_service changes running state on a production machine and deserves a human in the loop before it executes, and the tool layer's state_changing flag from earlier is what drives that decision automatically rather than leaving it to be remembered per-action:

def dispatch(action: str, **kwargs) -> dict:
    spec = ALLOWED_ACTIONS[action]
    if spec["state_changing"] and not human_approved(action, kwargs):
        return {"ok": False, "status": "pending_approval", "action": action, "args": kwargs}
    return execute_via_jea(action, **kwargs)

Logging Every Command, Twice

JEA sessions write a transcript automatically, a full record of every command and its output, without the tool layer having to implement anything. Turning on script block logging as well, via Group Policy or, on a managed fleet, through Intune's PowerShell script settings, captures the exact script block that ran even if a cmdlet's parameters were built dynamically:

# Applied via GPO or Intune administrative template
# Turn on Script Block Logging
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' `
    -Name 'EnableScriptBlockLogging' -Value 1

The tool layer should log a third, independent record of its own: which agent run requested the action, what arguments the model supplied, and the approval decision, all before the JEA session ever starts. Three overlapping logs sounds redundant until the one time a JEA transcript is missing or an event log has rolled over, and the tool layer's own record is what actually answers "what did the agent try to do and why." This full discipline, tracing a decision back to its exact cause across every layer it passed through, is the subject of AI Observability.

Scoping the Credential the Agent Never Sees

The agent itself should never hold a credential capable of connecting to a machine directly. It calls a tool; the tool layer, using its own short-lived, narrowly-scoped service credential, connects to the JEA endpoint, which then runs as the virtual account defined in the role. Three separate identities are involved in one action, the agent's own identity for logging and auditing purposes, the tool layer's service credential for the WinRM connection, and the JEA virtual account that actually executes the command, and none of them are a standing domain-admin account sitting in a config file. The full reasoning behind keeping these identities distinct, including why "the agent acting on someone's behalf" and "the agent acting with its own authority" need to be separately auditable, is covered in AI Agent Identity.

What a Full Round Trip Actually Looks Like

Tracing the print-spooler example through every layer above, in order:

Every one of those seven steps is independently auditable, and a failure at any single step stops the action rather than silently falling through to a less constrained path.

What Happens When Something Tries to Go Wrong

This is the actual argument for building the system this way instead of relying on the model to recognize an injection attempt and refuse. It doesn't need to recognize anything. The architecture doesn't offer a path for a disallowed action to reach a real machine, regardless of how convincing the reasoning that requested it was.

The Bottom Line

An agent that can restart a stuck service, check disk space, or pull a service status without paging a human at 2 AM is a genuinely useful thing to build, and PowerShell is the right tool for an agent to reach for on a Windows estate specifically because it's so capable. That capability is exactly why the system around it, a fixed action menu instead of free-text scripts, a JEA endpoint that can't execute anything outside its role, Constrained Language Mode closing the escape routes, approval gated to actual blast radius, and logging that doesn't depend on any single layer working correctly, has to be built deliberately rather than assumed. None of these mechanisms were invented for AI agents. They were built for exactly this problem, a caller that shouldn't be fully trusted, running commands on a system that matters, and an agent is just the newest kind of caller that needs them.