A coding agent with terminal access can install a package, run a script, start a child process and connect to a server. Add skills, hooks and MCP tools, and a request like “fix the build” can become a chain of actions with access to your files and credentials.
Those actions need security decisions. Which command may run? Which tool call did I actually approve? What should happen when an agent touches a sensitive path?
I've spent eight months building AEGIS: an open-source security and protection app for local AI agents. “Antivirus for AI agents” is how I describe the project. Its protective controls are concrete: deny a configured command before it starts, require approval for an exact MCP request, reject known secrets on configured MCP routes, review skills before use, and pause or stop a selected agent process.
The part I care about most is being able to say no before a routed action executes. You explicitly connect the commands and MCP tools you want AEGIS to govern, then define the decisions they must pass. The activity views and investigation tools help you choose those rules and respond when something needs attention.
Here is the security workflow I am building around:
- Before launch: inspect a skill, project or agent configuration for suspicious command patterns and changes.
- At execution: apply command policies and exact, single-use MCP approvals on the routes you configure.
- During a session: investigate sensitive activity, receive alerts, and pause or stop the process you selected.
- After a session: review the evidence, refine rules and export an audit record.
Cover: AI-generated editorial artwork from the AEGIS project. A conceptual illustration, rather than recorded activity.
In my March post, I shared an early monitoring-focused build. Since then, command policies, precise tool approvals and security review have become central to AEGIS. The downloadable Windows release is 0.20.1-beta, under the MIT license. The workflows below describe that beta; the final development section covers newer source work.
Block a denied command before it starts
A destructive command is easier to deal with before it starts. This is where AEGIS puts a policy decision directly in the execution path.
For a command deliberately routed through AEGIS, a selected-action policy evaluates the executable, working directory, arguments and selected environment. A denied decision stops that route before process creation. Eligible actions can require fresh terminal confirmation; a policy deny stays denied.
You explicitly route a command through AEGIS. Its permission is tied to this executable, these arguments, this directory and this attempt. That gives you a practical place to enforce a rule before launch.
Compatible policies can use Cedar, alongside the supported JSON policy formats. You can expose a fixed selected command, or a bounded catalog of commands, as MCP tools backed by those execution checks. Changes to the selected policy and request are checked as part of the operation.
There is also a separate controlled deletion route: one selected regular-file path, an explicit policy and mandatory terminal confirmation. This gives a deliberate cleanup action its own review step.
For specialized Windows workflows, AEGIS includes opt-in Job and AppContainer launch routes. A Job keeps the launched process and its ordinary member descendants under a shared lifetime. The selected offline AppContainer route uses a fresh workspace and a restricted Windows token with no additional capabilities. You select these routes per action and set up their documented native helpers and runtime requirements. The execution documentation explains how to configure them.
The Action control workspace helps inspect that setup. It separates a configuration check from observing a running route and seeing whether a call actually reached it. That distinction matters when connecting a real client: a settings file on disk is only one part of the path.
Protect MCP access with exact approvals and secret filtering
Consider a hypothetical file-writing tool. One request targets notes/review.md; another targets .env. The tool name is identical. The decision should include the arguments.
AEGIS's validating MCP gateway checks the accepted tool catalog and schema, then requires approval bound to the exact tool call and arguments. It consumes the one-use grant before forwarding the call. A changed request needs its own approval. Permission for one operation cannot silently become permission for another through that gateway.
The gateway supports explicitly configured stdio, loopback HTTP and pinned HTTPS routes. Expiring grants can be retained across restarts. Selected-command policies and gateway approvals perform separate jobs; the selected-action adapter is the route that connects an MCP tool to command-policy execution.
Credentials deserve a decision point too. You can configure known-secret filtering for routed MCP metadata, arguments and results, including recognized encodings. When a configured known value matches, that route rejects it. This lets you protect a particular credential from being passed through that connection.
The source includes narrow Claude and Gemini hook integrations as well. They depend on the provider loading and honoring the configured hook. Gemini's helper checks the exact complete shell input and working directory; the newer Claude setup work is described below.
Review skills and configurations before trusting them
A downloaded skill or package brings another author's commands and configuration into your workspace. Reviewing those components before use is a security decision: what am I about to let this agent execute?
AEGIS's Local security workspace lets you select a project, a skill or package directory, or a supported agent profile. Its static review looks for patterns such as downloaded-code execution, credential-upload commands, destructive deletion, permission bypass, installation scripts, mutable dependencies and instructions to conceal actions.
It inspects supported shell, JavaScript and Python command flows alongside package and configuration evidence. Project inventory collects recognized package and lock files, Git/configuration evidence and supported profile layouts. Profiles include Codex, Claude, Cursor and Gemini. You can also inspect fingerprints from an explicitly selected offline MCP tool catalog without starting that server.
Each finding gives you something specific to investigate. A command downloading and executing a script deserves a different decision from an ordinary dependency declaration.
You can save an inventory snapshot, capture it again later, and compare added, changed or removed observations. Accepting a snapshot involves fresh revalidation, so the recorded review stays tied to the configuration you actually inspected.
AEGIS also imports supported Cisco JSON and SARIF reports. You can compare an external report with a fresh built-in review while keeping its origin visible. That makes an existing report useful inside the same investigation.
Actual AEGIS source UI with simulated data, captured 11 October 2026. Source: AEGIS project screenshots.
Pause or stop the agent process that needs attention
When an observed process needs attention, AEGIS gives you a direct response: pause, resume or stop the selected instance. It rechecks the process identity before dispatching the action, and Stop requires confirmation.
That detail matters because a process identifier can be reused after a process exits. The intervention needs to stay attached to the instance whose evidence you were reviewing.
Sensitive-activity notifications can appear as native desktop popups, while in-app review and anomaly notifications keep the investigation accessible. Popup preferences and throttling let you fit alerts around normal work.
Investigate the activity behind a security alert
To make a useful security decision, I need to connect an observation to the process behind it. An unfamiliar endpoint, a sensitive-directory change or a new child process is a reason to inspect the evidence.
During a session, the Monitoring workspace identifies recognized local agents and shows separate running instances. You can select an instance, follow process relationships, filter the view and open its activity details.
Recognition uses bundled signatures and available parent-process or IDE-host evidence. The agent catalog is editable: add validated custom definitions and import or export them for your own tools.
File investigation brings together configured sensitive-directory changes, recognized agent configuration paths and available platform observations. Events retain the attribution evidence that supports them. Network views show TCP endpoints associated with detected agent processes, with destination classifications and available verified names.
CPU and memory history help explain a busy session. Where available, NVIDIA VRAM samples add hardware context. Statistics separates AEGIS's own resource use from the processes it monitors.
Local environment discovery can also surface WSL distribution names and Docker container or image candidates; Linux has a local Podman discovery path. Those entries help locate environments worth investigating, with their candidate status visible.
Coverage and freshness belong in this workspace too. AEGIS exposes sensor health and stale observations so you can judge the record in front of you.
Actual AEGIS source UI with simulated data, captured 11 October 2026. Source: AEGIS project screenshots.
Detect unusual behavior and build useful security rules
Security alerts need context. A process touching a sensitive path is worth examining; a change in its recent behavior can make that observation more useful.
AEGIS maintains live behavior separately for process instances and retains recent completed-session profiles per agent. With enough history, it compares dimensions such as file volume, sensitive activity, directories, endpoints and active hours against earlier sessions.
Risk explanations show the captured factors contributing to a score. Older events lose influence over time. Anomaly warnings identify deviations for investigation, and sequence rules can connect ordered observations into a reviewable detection record.
The interface gives you ways to manage the resulting noise: review sensitive observations, record false-positive exceptions, and put an agent instance on a watchlist for alerts. You can search sensitive-path rules, enable or disable them, reload them and add schema-validated custom YAML rules.
Rules & permissions also saves agent- or instance-scoped category preferences and profiles. Those review preferences sit alongside the explicitly configured execution controls described earlier. Keeping the chosen route visible makes it easier to understand which decision governs a particular action.
Keep an audit trail for security review
An investigation often continues after the agent session ends.
AEGIS retains audit history and statistics. You can export activity as JSON or CSV, generate an HTML session report, save a diagnostic ZIP, and export retained audit records. Daily audit records carry sequence numbers and SHA-256 linkage for local chain verification.
Reports preserve the context needed for review. Paths, process names and endpoints can still be sensitive, so I would inspect an export before attaching it to a public issue.
Actual AEGIS source UI with simulated data, captured 11 October 2026. Source: AEGIS project screenshots.
There is an optional Anthropic activity assessment as well. You explicitly request it, supply an API key and confirm the external activity metadata being sent; that provider usage can incur charges. The beta can assess an agent-name group or the session and produce a threat report. Local static review remains a separate workflow.
For Claude Code, Statistics shows observed input, output and cache token subtotals from matching readable local session data, together with model labels, source samples and collection health. Estimated USD costs help make a long session easier to understand. They are estimates based on the observed usage and pricing data.
Make security fit daily work
I want the security workspace to fit beside an editor: stay accessible, keep useful exclusions and make alerts manageable.
AEGIS can live in the tray, start with Windows, start minimized, pause monitoring and quit explicitly. Scan intervals and presets, build-directory exclusions, custom exclusions and sensitive-path patterns let you adjust collection to the workspace.
Validated configuration import/export makes that setup portable. API-key fields are omitted from settings exports, and configured keys use encrypted persistence.
The desktop includes light and dark themes, high-contrast variants, reduced motion, English and Brazilian Portuguese, Simple and Advanced navigation, and task search. Hardware-acceleration settings provide a restart path when changing rendering behavior.
Windows update actions verify downloaded artifacts before reporting them ready and verify them again before installation. The public delivery is Windows-first; macOS and Linux source paths remain experimental. Core monitoring and review records stay local. Requested updates, network naming and explicitly confirmed provider analysis have their own external traffic.
Newer protection work in the development branch
Current source contains work beyond the 0.20.1 installer.
One addition is a persisted, explicitly selected project folder for change watching, with its own Coverage state and select, clear and refresh controls. Another is live Claude Tool context explanation, connecting captured events with matching local main-session metadata and showing the evidence behind the association.
Optional AI analysis now targets a concrete observed process instance with identity revalidation. Network interruptions retain observations with clearer freshness information, and notifications follow valid process instances more precisely.
A particularly important protection workflow is the separate Claude hook profile: review a policy, install it into an app-owned settings profile, inspect or remove the recognized hook, and launch Claude with that selected profile. The current implementation record documents an installed-Claude allow/deny run through a private unpacked application package. Using a separate test profile, the allowed marker was created, the denied action received an explicit AEGIS denial, and its marker was absent.
That is a specific development result on the recorded package and provider version. It belongs to the newer source work, separate from the public beta download.
Put a security check around your next agent workflow
Start with the Windows beta and its installer-verification guide. Choose a local project or skill folder for review. Inspect a detected agent instance. If you want command or MCP controls, deliberately configure the relevant route using the linked documentation.
The illustrated overview is a quick way to see the workspace before installing. The source and issue tracker are open under MIT.
If this is useful, star AEGIS on GitHub. It is a small, voluntary way to help people discover the project and follow its progress.
If someone on your team gives agents terminal, repository or MCP access, send them this post. A practical walkthrough, an honest review or a demonstration of your own workflow would help introduce AEGIS to the people it is being built for.
And if you want to help build it, contributions are welcome: agent signatures, detection rules, documentation, reproducible bug reports and focused pull requests all have a place.
I've put eight months into building AEGIS because giving an agent access to a computer also creates a security responsibility. I want developers to be able to inspect what they install, define which actions are allowed, and intervene when a process needs to stop. Which action in your workflow would you put behind a security check first?
Ruslan Murtuzaliyev · Escape Studio / AEGIS. AI generated this draft with little human editing. Feature descriptions were checked against the linked release and development source.
Top comments (19)
The exact-approval point is what separates this from every 'approve all tool calls' popup — a changed request needing its own approval means permission can't silently slide from one operation to another. That's the right unit of trust for an agent with terminal access. How does the single-use grant hold up under an agent that legitimately retries the same call — does the user get approval fatigue, or does the gateway learn which retries are safe?
That’s a great edge case to consider! The goal is to balance strict security with a smooth workflow. Ideally, safe retries should be handled through explicit, narrowly scoped policies, while any change in arguments or context triggers fresh approval. Security shouldn’t come at the cost of usability. 🔐
The narrowly-scoped policy is the right middle ground — it stops approval fatigue without letting permission slide, since only the exact pre-approved retry passes. The test I'd watch is how narrow 'narrow' stays in practice: does the policy scope by tool, arguments, and target, or can a retry drift within the same policy?
Good question. An identical call can still cause duplicate side effects. I’d use an idempotency key to track the original operation and return its result when available. A single-use approval shouldn’t automatically authorize another execution
That's the cleaner answer than a retry policy — an idempotency key turns the second call into a lookup, not a second execution, so the approval question disappears for the identical case. The boundary I'd watch is where the key lives: if the gateway holds it, a tool that executed but never reported back still leaves the gateway unsure whether to replay or return. Does AEGIS store the result with the key, or just the key itself?
Agreed. The key is defining “safe retry” precisely. Matching arguments alone aren’t enough, since the underlying state may have changed. Any retry policy should be explicit, limited, and visible to the use
State change is the part matching-arguments checks miss — the same call against a different world isn't the same call at all. 'Explicit, limited, and visible' is a good bar; the visible part is where I'd push hardest, since a policy nobody can inspect at approval time is just a blanket permission with better wording. What does visibility look like in AEGIS — a log entry after the fact, or something the user sees before the retry runs?
I like that AEGIS combines visibility with controls: seeing what an agent does is useful, and having a way to review or deny selected actions makes the idea even more interesting. Curious to see where the project goes.
Thanks, Lauren! That’s the direction I’m working toward,making it easier to understand what happened and decide what to allow.
Interesting approach. Reviewing agent skills before use and putting specific MCP calls behind approval seems like a practical way to make workflows safer.
Thanks, John! I wanted skill review to happen before you bring something into your workflow.
exact approvals for MCP tools is the part most agent setups skip.
AI agents are becoming more powerful, but security needs to evolve alongside them. 🔐 I especially like the focus on blocking risky actions before they execute rather than just monitoring them afterward. Open-source tools like AEGIS could be valuable for developers working with AI agents. Great initiative! 👏
Cool project! MCP approvals are a smart addition. Definitely keeping an eye on this.
Thanks! MCP approvals were important to me because the arguments matter just as much as the tool itself.
The hardest part of an agent security product is choosing an intervention that is both safe and usable. I’d be interested in the false-positive story: which behaviors can be observed, blocked, or held for approval without training users to dismiss every warning?
The exact, single-use MCP approval is the part I'd stress-test most aggressively. A useful negative test would approve one payload and then change the target path, working directory, arguments or resolved symlink before execution. The enforcement layer should evaluate the actual resolved request at execution time and reject anything outside that approved scope, even if the model presents it as the same task. That is consistent with OWASP's emphasis on independent tool-policy enforcement and least privilege: cheatsheetseries.owasp.org/cheatsh...
antivirus for AI agents, cool one. glad there's a windows beta too
Some comments may only be visible to logged-in visitors. Sign in to view all comments.