AEGIS: reviewing local tool inputs and denying selected commands before launch

[Escape Studio (antropos17)]

I'm Ruslan from Escape Studio, the maintainer of AEGIS. AI assisted development and this write-up. I'm sharing an MIT-licensed Windows-first security beta for people developing agent workflows on their own machines.

A local tool call eventually becomes a concrete action: an executable, arguments, a working directory and an environment. That is a useful place to make the protection decision reviewable. In AEGIS's selected-command route, the operator supplies an explicit request and policy. A denied decision never produces a launch for the execution owner to start; a request requiring approval needs its own terminal confirmation.

The preparation workflow is local static review: select a project, skill or supported agent profile, inspect risky command/configuration patterns, and retain a snapshot for comparison after an update. During a session, observed process and file/network evidence can inform a manual pause or confirmed stop of a selected process, with an identity recheck before the action.

For MCP, a separate configured gateway validates an accepted tool catalog/schema and requires one-use approval bound to the exact tool and arguments. These controls apply to the routes deliberately configured through AEGIS. AutoGen-specific integration has not been validated; this is a separate host-side review/control workflow, rather than a claim that installing AEGIS automatically mediates AutoGen's tools.

Actual source UI preview, simulated data, captured 11 October 2026. The image illustrates the review workspace; it is not a live blocking test.

Selected-command execution owner at the beta revision · Public beta

For developers exposing local commands as agent tools: which request fields do you need beside the command itself to make an approval useful? I'd especially value examples involving a changed working directory or environment, with private values omitted.

[srpadmanabhuni]

Beyond the command, I would want the resolved absolute path of the executable (not just the name), the argv as a list rather than one string, the working directory after symlink resolution, and the environment as a diff against a baseline with values masked but key names visible. Without the diff, an approval for the same command with a changed PATH or LD_PRELOAD looks identical. I would also bind the approval to a hash of those fields plus the tool-call ID, so a retried or replayed call cannot reuse it. For testing, I would replay one recorded approved request with a single field mutated (cwd, one env key, an extra argument) and assert it is denied, and check that approvals expire after an interrupted session resumes.

[Escape Studio (antropos17)]

Thanks, this makes the acceptance cases much more concrete. The environment delta is particularly useful: identical argv with a changed PATH or loader-related variable should not look like the same reviewed request. For sensitive key names, I would keep the exact diff local and share a redacted summary.

I would also distinguish a resolved pathname from executable identity: replacing a file at the same path must not inherit approval just because the spelling is unchanged. Your independent cwd/env/argument changes, replay case and interrupted-session expiry form a useful test matrix. These are qualification requirements, not a claim that our current route already validates an AutoGen integration.

I maintain AEGIS, and this reply was prepared with AI assistance. If you want to help turn one bounded case into a reproducible fixture, our contribution entry points separate small documentation/testing tasks from the native acceptance work.