A developer built an open-source 'antivirus' for AI coding agents over eight months
Coding agents with terminal access can install software and reach files and credentials. AEGIS is an open-source attempt to approve or block those actions before they run.
The short version
- AEGIS is open source under the MIT license; the downloadable Windows release is 0.20.1-beta.
- It can deny a configured command before the process starts, on routes you explicitly connect.
- MCP tool calls can require approval tied to the exact tool and arguments, used once.
- It reviews skills, projects and agent profiles for risky patterns before you trust them.
- You can pause, resume or stop a selected agent process, and export audit records.
Why it matters
Anyone letting an AI agent work on their own machine is handing it real power over files, software and logins. This project shows what a sensible safety layer looks like: approval before action, not a log read afterwards. Even if you never use this tool, its checklist is a useful way to judge any agent setup.
What an agent can do when you look away
As dev.to reported in a first-person post, a coding agent with terminal access can do much more than edit code. It can install a package, run a script, start a child process and connect to a server. Those are the same building blocks an attacker would want.
The author adds that skills, hooks and MCP tools make this reach wider. MCP, the Model Context Protocol, is a way of plugging extra tools and outside services into an agent. With those add-ons, a plain request like asking the agent to fix the build can turn into a chain of actions that touch your files and credentials.
The post argues that each of those actions is a security decision. Which command may run? Which tool call did I actually approve? What happens when the agent reaches for a sensitive folder? Most people never make these decisions explicitly; they just let the agent proceed.
The core idea: say no before it runs
The author calls the project AEGIS and describes it as an antivirus for local AI agents. The part they care about most is the ability to refuse an action before it executes, not just record it afterward.
The catch is that this works on routes you set up. You choose which commands and MCP tools to connect to AEGIS, then define the rules they must pass. For a command routed this way, a policy looks at the program, the folder it runs in, its arguments and selected environment settings. If the policy says deny, the process never starts.
Permission is narrow. An approval is tied to this program, these arguments, this folder and this attempt. Policies can be written in Cedar, a policy language, or in supported JSON formats.
Approvals that cannot be reused
The post gives a simple example. Imagine a file-writing tool. One request writes to a notes file, another writes to a file holding secrets. The tool name is the same, but the risk is very different, so the decision has to include the arguments.
AEGIS's MCP gateway handles this by requiring approval for the exact tool call and its arguments. The approval is single-use and is consumed before the call is forwarded. If the request changes, it needs a fresh approval, so permission for one operation cannot quietly become permission for another.
The gateway can also filter known secrets. You can configure particular credentials, and if one appears in the metadata, arguments or results on a routed connection, including in recognized encodings, that route rejects it.
Check add-ons before you trust them
A downloaded skill or package brings someone else's commands into your workspace. AEGIS includes a static review, meaning it reads the files without running them. It looks for patterns such as:
- running code that was just downloaded
- commands that upload credentials
- destructive deletion
- bypassing permissions
- install scripts and dependencies that can change under you
- instructions to hide actions from the user
It can inspect projects, skill folders and agent profiles for Codex, Claude, Cursor and Gemini. You can save a snapshot of a configuration and compare it later to see what was added, changed or removed.
If something does go wrong mid-session, you can pause, resume or stop a selected agent process. AEGIS rechecks the process's identity first, which matters because an operating system can reuse a process number after one ends. After a session, you can export activity as JSON or CSV, generate an HTML report, and export audit records that are linked together so tampering can be checked locally.
Limits to keep in mind
This is one developer's description of their own project, and we have not tested it. How reliably it catches real attacks is not something the post establishes.
The author is open about some limits. The public release is Windows-first, and macOS and Linux versions are still experimental. The protections apply only to commands and tools you deliberately route through it. Some hook integrations for Claude and Gemini also depend on those products loading and honoring the configured hook.
There is an optional cloud step too. If you ask for an Anthropic-based activity assessment, you supply your own API key and confirm what activity data gets sent, and that use can cost money. The author also warns that exported reports can contain paths, process names and network addresses, so check them before attaching one to a public bug report.
The habit matters more than the product
You do not need AEGIS to take its lesson. Treat an agent as a capable but unvetted helper. Give it a limited folder, decide in advance which logins and files it never sees, and read install commands before they run.
Treat every new skill or tool as code from a stranger. The more add-ons you connect, the more places an unreviewed action can come from. A tool that asks you first, and asks again when the request changes, is a reasonable model for what to demand from any agent setup.
What to watch
- Independent testing of how well AEGIS-style controls catch real malicious agent behavior.
- Whether macOS and Linux versions move beyond experimental status.
- Whether the newer development-branch work, such as project-folder change watching, reaches a stable release.
Try it
Before your next agent session, write down two lists: folders the agent may touch, and files or logins it must never reach. Then give it only the first, and read each install command before approving it.
Sources and links
- Reportingdev.to: the article we sourced
Liked it? Say why
Add a line for other readers.
No account needed. We never show your email. Comments with links, ads or abuse are held and not shown. Your comment shows after a quick check.
Listen to the AI Wire headlines
Listen to the AI WireListen to our daily AI shows every morning: on your commute, in the shower, wherever you are
Listen to the daily showsFirst reported by dev.to · Read the original. Written by the SI Agent News Desk from the reporting above.Written with AI from the source above. Every number is checked against the source. Spot a mistake? Corrections.
