DEV Community: Hassan Mehmood

Your AI agent has sudo. I built a tool to take it away.

Hassan Mehmood — Sun, 21 Jun 2026 12:49:08 +0000

A few weeks ago I gave an AI agent access to my machine through MCP. It read files, opened PRs, queried a database. It was great — until I looked at what it could have done if a tool description had been poisoned, or a prompt injection had slipped through.

The answer was: anything. ~/.ssh/id_rsa. DROP TABLE users. rm -rf /. The agent had sudo, and nobody had voted for that.

So I built AgentPerms — a CLI that gives MCP agents least-privilege permissions the same way you'd lock down any other process: figure out the minimum it actually needs, pin it, prove it, and enforce it.

pip install agentperms

The gap nobody was filling

MCP (the Model Context Protocol) is quietly becoming the USB-C of AI tooling. Claude Desktop, Cursor, VS Code, Windsurf, Gemini CLI — they all speak it. Which is wonderful, and also means your agent is one config file away from your filesystem, your repos, your inbox, and prod.

The existing tools each do part of the job:

Scanners tell you something looks risky. Then they leave. You still have a risky thing.
Firewalls / allowlists make you hand-write YAML up front — before you have any idea what the agent will actually use.

Neither closes the loop. What I wanted was the boring, proven security workflow we already use for everything else: observe real behavior → derive least privilege → enforce it → keep it honest in CI.

That's the whole thesis of AgentPerms, as a pipeline:

record → infer → lock → replay → enforce

See it in 30 seconds (no setup, no network)

AgentPerms ships with a deliberately over-privileged demo MCP server, so you can watch a real policy decision without wiring anything up:

# Flag risky config: a ~/.ssh mount and an unpinned npx server
agentperms scan --path examples/vulnerable-mcp-demo

# Replay a pack of canned attacks against an example policy
agentperms replay --policy examples/policies/example.mcp.policy.yaml

Output:

8/8 attacks blocked.

SSH-key exfiltration, .env reads, rm -rf /, unapproved email, force-push, repo deletion, destructive SQL — every one denied or routed to human approval before it would ever reach a server.

The trick: be the proxy

Here's the part I'm proud of. AgentPerms doesn't ask your agent to cooperate, and it doesn't patch the client. It rewrites the MCP client's config so every server launches through a transparent stdio proxy:

Agent  →  AgentPerms proxy  →  MCP server
              │
              ├─ record:  log every tools/call, then forward
              └─ enforce: allow / deny / require-approval before forwarding

The proxy spawns the real server as a subprocess and pumps newline-delimited JSON-RPC both ways. It intercepts tools/call requests and captures tools/list responses. That's it. The agent has no idea it's there.

A server entry goes from this:

{ "command": "python3", "args": ["server.py"] }

to this (original command preserved after --, with a .agentperms.bak so you can roll back):

{
  "command": "/usr/bin/python3",
  "args": ["-m", "agentperms", "_proxy",
           "--mode", "enforce", "--server", "demo",
           "--policy", "/abs/path/mcp.policy.yaml",
           "--", "python3", "server.py"]
}

In record mode it logs and forwards. In enforce mode it evaluates first and, on a DENY, returns a synthetic JSON-RPC error to the client without forwarding. Denied calls never touch the server.

Record what's real, infer the minimum

You don't write the policy. You run your agent normally for a while with recording on:

agentperms record --client cursor
#   ... use your agent ...
agentperms infer        # traces -> mcp.policy.yaml

infer is the killer command. It reads the traces and emits the minimum policy that still lets the agent do what it actually did:

the tools it called become allowed_tools
the directories it touched collapse into the smallest covering set of allowed_paths
known-dangerous categories (shell, repo deletion, email send, DB writes) get seeded straight into denied_tools / human-approval

The result reads like a security review wrote it for you:

Your agent only used read-only GitHub calls and local ./src access. It does not need shell, home directory, secrets, Gmail send, or database write access.

One decision authority

Whatever you do, there must be exactly one place that says allow/deny/approve — otherwise your offline tests and your live enforcement drift apart and you're testing a lie.

In AgentPerms that's a single evaluate(policy, server, tool, args) function, called by both the live proxy and offline replay. First-match-wins:

On the human-approval list → require approval
In denied_tools → deny
A path argument hits denied_paths / denied_patterns → deny
allowed_tools set and tool not in it → deny (default-deny)
allowed_paths set and a path falls outside it → deny
Otherwise → allow

An empty policy allows everything. The moment any server is constrained, unknown servers default-deny. What you test in replay is byte-for-byte what runs in production, because it's the same code path.

The policy itself stays small and reviewable:

version: 1
servers:
  github:
    allowed_tools: [list_repos, read_file, create_issue]
    denied_tools:  [delete_repo, write_secret, force_push]
  filesystem:
    allowed_paths:    [./src, ./docs]
    denied_paths:     [~/.ssh, ~/.env, /etc]
    denied_patterns:  ["*.pem", "*.key"]
approvals:
  require_human_approval: [gmail.send_email, github.merge_pr, shell.exec]
redaction: { secrets: true, emails: true, api_keys: true }

Tool poisoning: pin the identity

There's a sneaky MCP attack class where a server silently changes a tool's description or schema after you've trusted it — the model re-reads it and gets quietly re-instructed. So AgentPerms also locks tool identity:

agentperms lock          # hash every tool's name/description/schema
agentperms lock --check  # fail if any of them changed

Drop lock --check in CI and a poisoned tool fails the build instead of your users.

Make it a part of the codebase

agentperms init   # scaffolds .github/workflows/agentperms.yml

On every push/PR it runs:

agentperms scan --path .     # surface risky configs
agentperms lock --check      # fail on tool poisoning
agentperms replay            # fail if the policy stops blocking attacks

Commit mcp.policy.yaml and mcp.lock, and your agent's permissions become a reviewable, version-controlled, enforceable artifact — like any other part of your security posture.

What it doesn't do (yet)

I'd rather be honest than oversell:

Transport: local stdio MCP servers today. HTTP/SSE is on the roadmap.
Approvals prompt on the terminal — fine for dev, not yet a fleet-grade workflow.
A live dashboard and a Node wrapper are next.

Try it

pip install agentperms
agentperms scan --path examples/vulnerable-mcp-demo
agentperms replay --policy examples/policies/example.mcp.policy.yaml

PyPI: https://pypi.org/project/agentperms/
GitHub: https://github.com/hasanmehmood/agentperms

If you're running agents with real access to real systems, I'd genuinely love your feedback — especially on the policy model and what attack shapes you'd want in the replay pack. Issues and PRs welcome.

Your agent doesn't need sudo. Let's take it away.

Knowledge Graph Index with NebulaGraph and OpenAI LLM

Hassan Mehmood — Wed, 06 Dec 2023 04:49:01 +0000

This tutorial contains code to set up a Knowledge Graph Index using NebulaGraph as the storage backend and OpenAI's Language Model (LLM) for query processing.

Setup

Environment Configuration

Load Environment Variables: Ensure you have a .env file set up with required environment variables. Use dotenv to load them in your Python environment.

OPENAI_API_KEY=ak**

```python
import os
from dotenv import load_dotenv

load_dotenv()
```

Logging Configuration: Configure the logging settings.

import logging
import sys

logging.basicConfig(
    stream=sys.stdout, level=logging.INFO
)  # logging.DEBUG for more verbose output

Import Dependencies: Import necessary libraries and modules.

# Import necessary modules and libraries
from llama_index import (
    KnowledgeGraphIndex,
    LLMPredictor,
    ServiceContext,
    SimpleDirectoryReader,
)
from llama_index.storage.storage_context import StorageContext
from llama_index.graph_stores import NebulaGraphStore
from llama_index.llms import OpenAI
from IPython.display import Markdown, display

NebulaGraph Setup

Ensure NebulaGraph (version 3.5.0 or newer) is set up with the following steps:

Cluster Creation: Create a NebulaGraph cluster using one of the following options:

Docker Installation (Machines with Docker Installed):
- Option 0: Run the command: curl -fsSL nebula-up.siwei.io/install.sh | bash
Desktop Installation:
- Option 1: Install NebulaGraph Docker Extension from Docker Hub.
Manual Setup via NebulaGraph Console: If the above options are not applicable, manually create the NebulaGraph space, tags, edges, and indexes using the NebulaGraph console. Refer to the provided commands in the code comments.

Environment Configuration: Set NebulaGraph environment variables.

os.environ["NEBULA_USER"] = "root"
os.environ["NEBULA_PASSWORD"] = "nebula"  # default is "nebula"
os.environ["NEBULA_ADDRESS"] = "127.0.0.1:9669"  # assumed NebulaGraph installed locally

Knowledge Graph Indexing

Define Graph Structure: Define the graph structure (space, tags, edges).

space_name = "llamaindex"
edge_types, rel_prop_names = ["relationship"], ["relationship"]
tags = ["entity"]

Initialize NebulaGraph Store and Storage Context:

graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
)
storage_context = StorageContext.from_defaults(graph_store=graph_store)

Load Data: Load documents/data to be indexed.

documents = SimpleDirectoryReader("data").load_data()

Create Knowledge Graph Index:

kg_index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    max_triplets_per_chunk=10,
    service_context=service_context,
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
    include_embeddings=True,
)

Querying the Knowledge Graph

Initialize Query Engine:

from llama_index.query_engine import KnowledgeGraphQueryEngine

query_engine = KnowledgeGraphQueryEngine(
    storage_context=storage_context,
    service_context=service_context,
    llm=llm,
    verbose=True,
)

Querying:

response = query_engine.query(
    "your question on the data?",
)
display(Markdown(f"<b>{response}</b>"))

Further Customization

Adjust parameters and configurations in the code based on specific requirements or environment setup.

GITHUB REPO

https://github.com/hasanmehmood/llamaindex-knowledge-graph

Github is now free for teams!!

Hassan Mehmood — Tue, 14 Apr 2020 19:03:44 +0000

Visit the below link to get full details, Thanks.

https://github.blog/2020-04-14-github-is-now-free-for-teams/

Docker Cheat Sheet

Hassan Mehmood — Sun, 12 Apr 2020 16:00:22 +0000

CONTAINERS

Start a running container from an image
docker run -ti ubuntu bash
List running containers
docker ps
List all containers (running + stopped)
docker ps -a
List last container
docker -l
Delete a container after it finishes
docker run -ti --rm ubuntu bash
Commit a container and create a new image from it. First find the container id or its name then run the following command. Lets say 1234 is container id and my_container is the name
docker commit 1234 new_image_name
OR
docker commit my_container new_image_name
Attach an existing running container
docker attach name_of_container
Now leaving container wihtout exiting it
press and hold ctrl + p, ctrl + q
docker exec creates a new process in the existing container. Although it will die automatically if you close the original process
docker logs will print the logs of the container
docker logs container_name
docker kill will kill the running container
docker kill container_name
Removing containers
docker rm container_name
If the outside ports are not assigned then it will choose any available port. To see which port it choose, run the following command
docker port container_name

NETWORKS

For displaying list of already existing networks.
docker network ls
For creating a new network
docker network create new_network_name
for starting a container within a network
docker run -ti --net my_network_name --name my_container_name ubuntu bash

VOLUMES

2 main varieties of volumes
Persistent --> they will still exist when the contaner is stopped
Ephemeral --> they will be gone when no one (container) is using them
- Sharing a volume with the host (Persistant)
  
  docker run -ti -v /full/path/to/folder:/shared_folder ubuntu bash
- Sharing a volume b/w containers using volume-from (Ephemeral)
  docker run -ti -v /shared-data ubuntu bash
  - In above command Im creating a shared volume on the container that is not shared with the host
  - Now create another container and shared the above volume with the new continer
    
    docker run -ti --volume-from above_container_name ubuntu bash
  - Now important note: The above volume will be available as long as atleast one container is still using it. when no container is active that volume will disappear

Git Repo: https://github.com/hasanmehmood/docker-cheat-sheet