DEV Community: Riyan Dhiman

I watched what Claude Code does when you're not looking

Riyan Dhiman — Mon, 30 Mar 2026 08:11:05 +0000

I ran my AI coding agent in observe mode for a week. No blocking, no restrictions, just logging every action it took. What I found changed how I think about agent access.

The setup

I wrote a small tool that hooks into Claude Code's pre-execution layer. It logs every tool call, bash command, file read, and web request to an audit database without interfering with anything. The agent doesn't know it's being watched. Nothing gets blocked.

I turned it on and kept coding normally for a week. Then I looked at the logs.

What Claude did without being asked

In a normal coding session, Claude doesn't just do what you tell it. It explores. It reads files to understand context. It runs commands to check state. Most of this is helpful. Some of it is not what you'd expect.

In one session I asked it to help push a package to PyPI. It grabbed my .env file on its own to find the token. Made sense from its perspective, it needed the credential to complete the task. But now my PyPI token was sitting in the conversation context. If that had been a Stripe secret key or a database URL, same thing would have happened.

Across a week of sessions, the analysis flagged:

Multiple reads to .env and credential files I never asked it to touch
Shell commands I didn't prompt for, mostly harmless but some touching git config and system paths
File access outside the project directory
A pattern where it read a sensitive file and then made an external web request within the same session

That last one is the one that stuck with me.

The pattern nobody talks about

Most agent security discussions focus on blocking single actions. Don't let it run rm. Don't let it read .env. That's useful but it misses something.

The real risk isn't a single action. It's a sequence. Your agent reads a credential file. Two minutes later it makes an external HTTP request. Each action on its own looks fine. Together they form an exfiltration chain.

I started calling these cross-layer threats. A file read is one layer (what the agent can see). A web request is another (what the agent sends out). Individually they pass any policy. Combined within a time window, they're a problem.

When I added sequence detection to the analysis, sessions that looked clean on a per-action basis suddenly had findings. Not because any single action was malicious, but because the chain of actions told a different story.

The 5 layers of agent security

After digging into this, I started thinking about agent security as 5 distinct layers:

Layer 1: What the agent can DO. Destructive commands like rm, DROP TABLE, git reset --hard, force push. This is where most tools focus. It's the obvious stuff.

Layer 2: What the agent can SEE. Your .env, SSH keys, AWS credentials, service account files. Even if the agent doesn't do anything destructive, the fact that it read your secrets means those secrets are now in the model's context window.

Layer 3: What the agent SENDS OUT. Web requests, API calls, anything that leaves your machine. If the agent read a credential and then makes an outbound request, that's a potential exfiltration path.

Layer 4: What the agent REMEMBERS. Context poisoning and memory injection. Research shows 87% of downstream decisions get compromised within 4 hours of memory poisoning. This one is mostly unsolved.

Layer 5: MCP supply chain. Malicious MCP servers, tool poisoning. A recent audit found 71% of MCP servers scored F on security. Including Anthropic's own reference implementations.

Most agent security tools cover layer 1. Some partially cover layer 2. Nobody covers layer 3. Layers 4 and 5 are wide open.

Why observing matters more than blocking

Most developers won't install a security tool because they think they need one. They'll install it because they're curious. Observation has zero friction. It doesn't change your workflow. It doesn't block anything. It just shows you what's happening.

Once you see the logs, you don't need convincing that guardrails are needed. You ask for them.

The scary part isn't what gets blocked. It's what you see in the logs that you never knew was happening.

What I'm doing about it

I've been building a tool around this idea. It started as a simple policy engine for blocking dangerous actions but the observe and analyze workflow turned out to be more valuable than the blocking itself. It works with Claude Code, Codex, Cursor, and a few other agents.

It's open source and still early but I've been running it on my own workflow daily.

If you're curious: https://github.com/riyandhiman14/Agent-Sec

Would love to hear if anyone else has noticed similar patterns with their agents.

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

Riyan Dhiman — Sat, 28 Mar 2026 16:44:22 +0000

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

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"]

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

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

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.

Crafting Clear Code: A Beginner’s Guide to Writing Neat and Understandable Code

Riyan Dhiman — Wed, 31 Jan 2024 05:45:07 +0000

Hey there, fellow code enthusiasts! Today, I want to talk to you about something that’s often overlooked but incredibly crucial in the world of programming—writing clean code. Now, I know the term might sound a bit intimidating, but fear not! I’m here to guide you through the basics of clean code in a way that’s easy to understand.

Understand the Importance of Clean Code:
Imagine walking into a room with everything scattered around—books, clothes, and gadgets all over the place. It’s chaotic and confusing, right? Well, the same goes for code. Clean code is like having a well-organized room—it makes your work more manageable, understandable, and less prone to errors.

Meaningful names matter:
Just like calling your pet dog by its actual name makes communication easier, giving your variables and functions meaningful names is key. Instead of using cryptic abbreviations, opt for descriptive names that convey the purpose of the variable or function. This simple practice makes your code self-explanatory.

Keep It Short and Sweet:
Have you ever received a text that seemed to go on forever without getting to the point? Code can be like that too. Break down your code into smaller, logically organized functions. Each function should have a specific job, making your code more readable and easier to troubleshoot.

Comments—Use Wisely:
Imagine reading a book where every sentence had a footnote explaining it. Annoying, right? Similarly, while comments are helpful, they should clarify the why, not the what. Write comments sparingly and focus on explaining the reasoning behind certain choices in your code.

Consistency is key:
Just like having a consistent bedtime routine helps you sleep better, maintaining consistency in your code makes it more predictable. Stick to a consistent coding style, indentation, and naming conventions throughout your project. This makes collaboration smoother and your codebase more harmonious.

DRY—Don't Repeat Yourself:
If you find yourself copying and pasting code, it’s time to take a step back. Duplicating code not only increases the chances of errors but also makes your codebase harder to maintain. Create reusable functions or classes instead, following the golden rule of DRY—Don't Repeat Yourself.

Conclusion:
So there you have it—the basics of writing clean code. Think of coding as telling a story; make it engaging, easy to follow, and enjoyable. By incorporating these simple practices into your coding routine, you’ll not only become a better programmer but also make the coding experience more pleasant for everyone involved. Happy coding!

REST vs gRPC: A Comparison

Riyan Dhiman — Tue, 30 Jan 2024 07:52:23 +0000

When it comes to designing and implementing APIs (Application programming Interfaces), developers often face the choice between REST (Representational State Transfer) and gRPC (gRPC Remote Procedure Call). Both are widely used in the software industry for building distributed systems, but they differ in terms of architecture, communication style, and features. In this article, I will explore the key differences between REST and gRPC to help you make an informed decision based on your project requirements.

REST (Representational State Transfer)

REST is like sending letters. Each time you want something, you write a letter (request) to the other person (server). The letter contains all the information needed, and they send you a reply. Here are the key points:

Letters are Independent: Each letter is separate and doesn't rely on previous ones. This makes it simple and easy to manage.

Common Language: Everyone uses the same language (HTTP methods like GET, POST, etc.). It's like having a common way to write letters so that everyone understands.

Easy to Read: The address on the envelope (URL) is human-readable, like an address in your neighborhood.

Flexible: You can use different types of mail services (protocols) like regular mail, email, etc.

gRPC (gRPC Remote Procedure Call)

gRPC is like making a phone call. You and the other person can talk back and forth more efficiently. Here are the key points:

Quick Conversations: Instead of sending letters, you have a live conversation. You can ask and answer questions without writing and waiting for letters.

Special Language: You both speak a specific language (Protocol Buffers). It's like having a secret code that makes communication faster.

Clear Instructions: You provide specific instructions, and the other person follows them. This reduces misunderstandings.

Automatic Translator: There's a tool that translates your words into the language the other person understands (automatic code generation).

Choosing Between Them

Choose REST if: You want a simple way of communicating, like sending letters. It's widely used, and everyone understands it.

Choose gRPC if: You need a faster and more direct conversation. It's like talking on the phone – quick and to the point. If you like having clear instructions and automatic translation, gRPC is a good choice.

In the end, it's like choosing between sending letters (REST) or having a quick phone call (gRPC). Both work well, but the best choice depends on how you prefer to communicate.

Fast Track to Efficient Data Retrieval: Mastering Key Strategies in Software Engineering

Riyan Dhiman — Sat, 13 Jan 2024 07:52:46 +0000

Data retrieval is a crucial step in software engineering. The speed at which we can access data significantly impacts the quality of our product. In today's fast-paced world, even a millisecond optimization in data retrieval can lead to substantial cost savings. Let's explore some commonly used techniques to optimize data retrieval.

Indexing

Indexing is a fundamental technique in which we create indexes on frequently used columns. The index kind of acts as a pathway that improves query retrieval speed at the cost of write time. We can create a composite index if there are multiple columns for indexes. We should carefully analyze the query and usage pattern and decide on our indexes to improve the overall data retrieval time. We should also not blindly use any index because creating indexes increases write query time, so we should carefully select the indexes.

Denormalization

While creating a database schema, we are often advised to normalize our data. However, excessive normalization can sometimes impact our data retrieval time. The process of removing normalization and introducing redundancy in the database schema for faster retrieval is called denormalization. Denormalization reduces the number of joins in our queries, which significantly improves data retrieval time. Like any technique, it has its drawbacks. Denormalization can complicate updates and introduce data inconsistency. It's crucial to carefully assess the specific needs of your application before opting for denormalization.

Table View

Sometimes, we can't denormalize our database for various reasons, and the increasing number of joins is affecting our read time. In such cases, creating a view table for a specific query can be a solution. A view table is more like a temporary table that stores the data of the query. When retrieving data, we can directly use that view table, significantly improving read time compared to the query itself. Creating views for complex queries can be beneficial, especially when dealing with frequently used or intricate query patterns. Views encapsulate complex logic, making querying more straightforward for application developers. If we are using the view mechanism, it's crucial to update the view table regularly. If the view is not updated, users will see only old data, potentially impacting the business more than a delay in the query.

The above techniques are not the only ones that can improve data retrieval. There are several additional strategies such as caching, database sharding, and more, each with its own merits and applications. In future articles, we will explore these techniques to provide you with a comprehensive understanding of optimizing data retrieval. Feel free to ask any question you have!!!

Tips and tricks for optimizing Python code performance (Part 1)

Riyan Dhiman — Mon, 08 May 2023 06:15:25 +0000

Python is a robust programming language that boasts a multitude of applications. Nonetheless, as is the case with any programming language, it is essential to write efficient and performant code. With this in mind, here are several useful tips and tricks for optimizing Python code performance:

Caching

Caching is a method of storing commonly used information in memory to enable swift and easy access. In Python, there are several libraries available, including LRU cache, Redis, and Memcached, that offer a straightforward and adaptable approach to caching data in your code.

Redis is a commonly utilized caching solution in Python applications. It serves as an in-memory data store that can cache regularly accessed data. Below is an instance of implementing Redis for caching:

import redis

# Connect to Redis server
r = redis.Redis(host='localhost', port=6379, db=0)

def expensive_function(arg1, arg2):
    # Check if result is in cache
    cache_key = str(arg1) + ':' + str(arg2)
    cached_result = r.get(cache_key)
    if cached_result is not None:
        # If result is in cache, return it
        return int(cached_result)

    # If result is not in cache, perform expensive computation
    result = arg1 * arg2

    # Store result in cache for future use
    r.set(cache_key, result)
    return result

In the present instance, the Redis library is employed to establish a connection with a Redis server operating on the same machine, specifically on port 6379. The function expensive_function (Can't think of some at the time of writing) conducts a computationally expensive operation based on the input arguments arg1 and arg2.

Prior to executing the computation, the function first verifies whether the Redis cache already contains the result. This is achieved by constructing a cache key that is based on the input arguments. In the event that the result is present in the cache, it is retrieved instantly. If not, the function proceeds to perform the resource-intensive computation, and subsequently stores the result in the cache for future reference.

Memoization

Memoization is a technique that has become quite common to optimize the performance of functions by caching the output of previous computations, which is then retrieved when the same input occurs again. This technique can be particularly helpful for expensive function calls that are frequently repeated. Python has a built-in memoization library called functools, which can be used to apply memoization in your code with ease. With the assistance of functools, it's possible to cache the results of function calls promptly and enhance the performance of your code.

Memcached is a caching system that distributes data across multiple servers and stores it in memory, providing efficient handling of large volumes of read and write requests with minimal latency. Memcached is commonly used in web applications to cache frequently accessed data, including database queries, API responses, and HTML templates, allowing for rapid retrieval and delivery of this information.

To use memcached, you first need to install memcached library using pip
pip install pymemcache

Once pymemcache has been successfully installed, you can utilize the pymemcache.client module of the library to efficiently cache results and enhance the performance of your code.

from pymemcache.client.base import Client
import time

# Connect to Memcached server
client = Client(('localhost', 11211))

In the code snippet provided, a client object has been instantiated to establish a connection with a Memcached server that is running on the local machine and listening on port 11211. Prior to running the code, it is necessary to install the Memcached server software and launch it on the system in order to execute the example code below.

To demonstrate how memoization can optimize a recursive function, I have utilized the most fundamental example of all - the Fibonacci sequence. This sequence is comprised of numbers where each subsequent number is the sum of the two preceding numbers, starting from 0 and 1.

I have developed two Fibonacci functions: the first is a conventional function that is widely available on the internet (expensive_fib), while the second is an optimized Fibonacci function(cached_fib) that leverages memcached to cache the output and enhance the performance of the function.

def expensive_fib(n):
    if n <= 1:
        return n
    return expensive_fib(n-1) + expensive_fib(n-2)

def cached_fib(n):
    # Retrieve data from Memcached
    key  = str(n)
    value = client.get(key)

    if value is not None:
        # if data is present in the cache, then return it
        return value
    cur_value = int(cached_fib(n-1)) + int(cached_fib(n-2))

    # Store data in Memcached
    client.set(key, cur_value)
    return cur_value

#initial value
client.set("1", 1)
client.set("0", 0)


start_time = time.time()
result = expensive_fib(50)
end_time = time.time()
execution_time = end_time - start_time
print("Execution time of expensive fib:", execution_time)

start_time = time.time()
result = cached_fib(50)
end_time = time.time()
execution_time = end_time - start_time
print("Execution time of cached fib:", execution_time)

Upon execution of the preceding code, the resulting output is shown below:

Generators

Python generators offer the ability to generate large data sets on-the-fly, which can be more efficient in terms of memory usage than storing the entire data set in memory at once. The generator functions utilize the yield keyword to generate a sequence of values on-the-fly, in a similar manner to how a function generates values. Upon being invoked, the generator function returns a generator object that can be iterated through to produce each value in the sequence one-by-one. This method is ideal for generating sequences of values or conducting matrix operations while optimizing memory usage.

To illustrate how a generator can enhance the efficiency of a mathematical sequence, consider the following example. Suppose you wished to generate the first 100,000 prime numbers. Rather than generating the entire sequence simultaneously, which would necessitate storing all 100,000 numbers in memory, you could utilize a generator function to generate each prime number sequentially, as needed.

def is_prime(n):
    if n <= 1:
        return False
    for i in range(2, int(n ** 0.5) + 1):
        if n % i == 0:
            return False
    return True

def primes(n):
    count = 0
    i = 2
    while count < n:
        if is_prime(i):
            yield i
            count += 1
        i += 1

In the aforementioned example, the function primes() utilizes another function, is_prime(), to ascertain if a number is a prime number or not. Upon confirmation of the primality of a number by is_prime(), primes() generates the number. By calling primes(100000), the generation of each prime number on-the-fly replaces the necessity of storing all 100,000 numbers in memory, which consequently eliminates the need for excessive memory usage.

In the next post, I will discuss more performance optimization methods such as Cython, multithreading and multiprocessing

Pros and cons of cloud computing

Riyan Dhiman — Sun, 07 May 2023 12:45:37 +0000

Cloud computing has transformed the landscape of data storage and processing by providing access to a shared pool of computing resources, such as servers, storage, applications, and services, through the internet. This technology enables businesses and individuals to operate on a larger scale without being constrained by local hardware and infrastructure, resulting in significant savings of both time and money.

Before making a decision about adopting cloud computing, it is important for businesses to carefully consider both the advantages and disadvantages. In the following paragraphs, we will outline the potential benefits first, followed by the potential drawbacks.

Pros:

Cost savings: Did you know that cloud computing can be a real game-changer for businesses looking to save money? By using cloud services, companies can eliminate the need for expensive hardware and instead pay for the resources they need on-demand. This means that businesses don't have to worry about investing in and maintaining their own IT infrastructure, which can be a big relief.
Scalability: Cloud computing is a game-changer for businesses as it offers the flexibility to easily adjust IT resources based on their ever-changing needs. This means businesses can swiftly adapt to market fluctuations or surges in demand during peak seasons.
Accessibility: Cloud computing allows employees to access applications and data effortlessly, regardless of their location, as long as they have an internet connection. As a result, remote or dispersed teams can collaborate more efficiently and increase productivity.
Reliability: With cloud computing, you can count on providers to be there for you when you need them most!. Cloud computing providers typically offer high levels of reliability and uptime, with redundant backups and failover systems to ensure continuity of service.

Cons:

Security risks: When it comes to cloud computing, it's important to keep security in mind. To ensure the safety of your business's data and applications, it's essential to work with a cloud provider that has strong security protocols in place. Additionally, taking your own security measures is crucial to safeguard your information.
Internet dependency: Cloud computing is reliant on internet connectivity, which can be a potential point of concern. If a business experiences any disruptions to their internet connection, they may encounter downtime or other issues.
Lack of control: Cloud computing providers take care of the infrastructure, which can make it difficult for businesses to control their IT environment. Companies have to depend on their provider to manage maintenance and upgrades, which can limit their ability to customize their systems.
Data ownership and portability: Data stored in the cloud can be subject to data privacy rules and businesses may face issues regarding data ownership and transferability. Companies should make sure they have the ability to access and transfer their data, especially if they decide to switch providers.

As we come to the end, it's essential for businesses to weigh the benefits and drawbacks of cloud computing before transitioning. With careful consideration of their specific needs and taking measures to minimize risks, businesses can enjoy the advantages of cloud computing while safeguarding the security and integrity of their data and applications.