Ruslan Murtuzaliyev 花 8 個月打造 AEGIS，為本機 AI 智能體提供安全防護

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.