DEV Community

Cover image for I built an IAM-style firewall for AI agents after Claude read my .env
Riyan Dhiman
Riyan Dhiman

Posted on

I built an IAM-style firewall for AI agents after Claude read my .env

#ai #python #security #opensource

I've been using Claude Code to build stuff for a while now. It's fast, it writes decent code, and it saves me hours. But a few days ago I had a moment that made me stop and think.

The moment that got me was when Claude grabbed my .env file on its own while trying to push a package. PyPI token sitting right there in the chat. No warning, no confirmation, nothing. If that was my Stripe key or a database URL it would have been the same story.

And that's the problem. These AI agents have real access to your filesystem, your shell, your git history, your secrets. They don't have bad intentions, they just don't have boundaries. If you ask it to rm -rf something, it will. If you ask it to force push to main, it will. If it decides the fastest path to completing a task involves reading a credentials file, it's going to read it.

So I built agsec.

What it is

agsec is a policy engine that sits between the AI agent and your system. Before the agent can do anything (run a command, read a file, make a web request), the action gets checked against your policies. If the policy says no, the action doesn't happen. The agent doesn't get a say.

Think of it like AWS IAM but for AI agents. You write declarative YAML policies that define what's allowed, what's blocked, and what needs a human to sign off on.

How it works 

Agent wants to act  -->  agsec evaluates policy  -->  allow / block / review  -->  real world
Enter fullscreen mode Exit fullscreen mode

The enforcement happens at the hook level. Most AI coding agents (Claude Code, Codex, Cursor, etc.) support pre-execution hooks that fire before any tool call. agsec plugs into these hooks. The agent can't reason its way around it or write a script to bypass the check. The action simply doesn't execute unless the policy allows it.

What a policy looks like 

version: "1.0"
default: deny

statements:
  - sid: "AllowReadOps"
    effect: allow
    actions: ["file.read", "file.glob", "file.grep"]

  - sid: "BlockFileDelete"
    effect: deny
    actions: ["bash.execute"]
    conditions:
      params.command:
        op: "regex"
        value: "\\brm\\s"
    reason: "Agents should not delete files"

  - sid: "BlockEnvAccess"
    effect: deny
    actions: ["file.read"]
    conditions:
      params.file_path:
        op: "regex"
        value: "\\.env$"
    reason: "Block access to environment files"

  - sid: "AllowBash"
    effect: allow
    actions: ["bash.execute"]
Enter fullscreen mode Exit fullscreen mode

Deny always wins over allow. Same precedence as AWS IAM. If you've ever written an IAM policy, this will feel familiar.

You can match on action types (bash.execute, file.read, file.write, web.fetch), use regex and glob patterns on parameters, and set conditions with 12+ operators (equals, contains, regex, greater than, starts_with, etc.).

Getting started 

pip install agsec
agsec init                     # creates default policies
agsec install claude-code      # activates the firewall
Enter fullscreen mode Exit fullscreen mode

That's it. Three commands and every tool call is now checked. rm blocked, .env access blocked, force push blocked, all out of the box.

The default policies cover the obvious stuff:

  • 01_base.yaml: default deny, allow read operations
  • 02_bash.yaml: block rm, DROP TABLE, secret access, data exfiltration
  • 03_files.yaml: block writes to .env, credentials.json, system dirs
  • 04_web.yaml: review external HTTP requests
  • 05_git.yaml: block force push, hard resets, protected branches

Observe mode

If you're not ready to start blocking things, you can run in observe mode first:

agsec init --observe           # log only, no blocking
agsec audit --stats            # see what would have been blocked
agsec enforce                  # start blocking when ready
Enter fullscreen mode Exit fullscreen mode

This lets you see what your agent is actually doing before you put any guardrails in place. The audit trail alone is worth it. You'll be surprised how many things the agent does that you never explicitly asked for.

What platforms it supports

Right now it works with Claude Code, Codex, Cursor, Windsurf, Cline, and GitHub Copilot. Claude Code is fully tested, the others are functional but could use more community testing.

It also has Python SDK integrations for LangChain, OpenAI, and Anthropic clients if you're building agent workflows in code.

Why not just use the agent's built-in restrictions?

Most agents have some form of deny rules or permission settings. The problem is these are usually stored in project config files that the agent itself can modify. And they're typically simple string matching without conditions or precedence logic.

agsec policies live outside the agent's reach. The evaluation is done externally before the action runs. The agent can't edit the policy, can't skip the check, and can't convince itself that an exception is warranted.

What's next

I'm actively working on a web UI for policy management, better audit dashboards, and more platform integrations. The core policy engine is solid and I'm using it daily on my own workflow.

If you're using AI agents for real work and you've ever had that "wait what did it just do" moment, give it a try. Or just run it in observe mode and look at the audit logs. That alone might change how you think about agent access.

GitHub: https://github.com/riyandhiman14/Agent-Sec
PyPI: https://pypi.org/project/agsec/

Would love feedback, especially edge cases and bypass attempts. That's how this gets better.

Top comments (0)