Read-Only PowerShell With an Admin Command Policy

July 14, 2026 · InfraScout Team

Much of what an assessment does on a Windows host comes down to running PowerShell: read a setting, list a service, pull a configuration value, and reason about what it finds. That work is meant to observe, not change. This release gives the AI a PowerShell tool built for exactly that intent — agent_exec_powershell_readonly — and backs it with a command policy that checks every script before it runs, so anything that looks like it would alter the host is stopped rather than dispatched.

A PowerShell tool built to read, not change

agent_exec_powershell_readonly is a dedicated read-only tool the AI reaches for when an assessment needs to inspect a host with PowerShell. It behaves like the general execution tool in every way that matters for gathering information — it opens a session against the target, runs the script, and returns the output — with one deliberate difference: it is meant only to read state, and the platform holds it to that promise.

The distinction is not a label the AI is trusted to honor. Before a script reaches a host, InfraScout validates it against a command policy. A script that reads is dispatched and runs as usual. A script that appears to modify the host — stopping a service, editing the registry, writing a file, changing a configuration — is denied and never sent. The check happens on the server, on the way to the host, so a blocked script produces no effect on the machine it targeted.

Blocked before dispatch, with feedback the AI can act on

When the policy denies a script, the AI does not get a dead end. It gets structured feedback explaining that the script was blocked and why it read as host-mutating. That matters because the AI can then adjust — rewrite the check as a genuine read, split a mixed script into its read-only parts, or report plainly that the task needs a change it is not permitted to make here.

The result is an assessment that stays inside read-only boundaries without grinding to a halt at the first rejected command. The AI learns the boundary from the feedback and works within it, the same way it adapts to any other tool result.

Reading is safe; changing runs through you

A read-only tool is for the observation that makes up most of an assessment. When an assessment genuinely needs to change a host, that remains a separate, deliberate path: in a live conversation the AI tells you what it intends to change and waits for your go-ahead before acting.

An admin-managed command policy

The rules the tool enforces are not fixed. InfraScout ships a safe-by-default floor — a curated set of high-risk cmdlets that are always treated as host-mutating — and tenant admins layer their own allow and deny lists on top of it. A command policy is a reusable ruleset you create and manage in the administration area, alongside the other controls that govern how agents run work.

Allow and deny entries let you tune the boundary to your environment. If a cmdlet the floor treats cautiously is safe and useful for your assessments, an allow entry lets it through. If there is something you never want a read-only script to touch, a deny entry blocks it outright. Because the floor is always in effect underneath, tuning the policy adjusts the edges without weakening the baseline.

Policies attach to agent groups, so different parts of your estate can carry different rules. Where an agent belongs to more than one group, the applicable policies combine to the most restrictive result: if any group that governs an agent denies a command, it is denied for that agent. The strictest rule wins, so adding an agent to an additional group can only tighten what runs on it, never loosen it.

Enforcement governs the run, not the viewer

A command policy governs what actually runs on an agent, independent of who can see the policy in the portal. The boundary is applied at execution time to the work itself, which is what makes it a dependable control rather than a suggestion.

Blocked attempts show up in the audit trail

Every blocked script is recorded. Alongside the executions that ran, the audit trail now carries blocked executions — attempts the policy stopped before dispatch — marked distinctly so they stand apart from work that reached a host. You can filter the executions view down to just the blocked ones to see, at a glance, where a script was turned away and what it was trying to do.

That record is useful in both directions. It confirms the policy is doing its job, and it gives you a trail to review when you are tuning allow and deny lists — you can see exactly which commands are being stopped and decide whether each one should stay blocked or be allowed through.

Read-only assessment runs get it automatically

Because the tool is genuinely read-only, it fits naturally into the parts of InfraScout that are read-only by design. When the AI delegates self-contained work to a Task Agent, those runs are read-only unless they explicitly ask for more — and the read-only PowerShell tool flows into them as part of the toolset they are handed. A delegated run investigating a host can gather everything it needs with PowerShell while the command policy keeps it from changing anything on the machine it is assessing.

Try it

Open a conversation in the InfraScout portal and ask for a review that leans on Windows PowerShell — a service inventory, a configuration check, a look at how a host is set up. The AI runs those reads through the read-only tool, and anything that would change the host is stopped before it leaves the server. Then head to the administration area to shape a command policy for your environment and attach it to the agent groups that need it, and check the executions view to see any blocked attempts recorded in the audit trail.

Questions or feedback? Reach us at info@infrascout.cloud.