Step 6 of the series is here! This one is perfect for a “security and governance” themed article. Here is the Medium-style content for Part 6, focusing on Dynamic Tools and Runtime Security.

When building AI agents for the enterprise, the biggest fear isn’t “hallucination” — it’s unauthorized action.

Imagine an SRE (Site Reliability Engineering) agent with the power to delete a namespace in a production Kubernetes cluster. You don’t want a Junior developer to accidentally trigger that command, nor do you want the AI to “rushing” into a destructive action without a conversation.

In Part 5, we learned about dynamic models. Today, we’re applying that same “runtime intelligence” to Tools. We’re going to build a Triple-Lock Security Gatekeeper using LangChain 1.2.

The Problem: Static Tool Overload

Most agents are created with a static list of tools: agent = create_agent(model=model, tools=[read_logs, delete_db])

The problem? The LLM sees delete_db as an option every single time. This increases the "surface area" for errors. A better approach is Dynamic Tool Filtering—deciding which tools the AI even knows about based on three layers of security.

1. The Triple-Lock Architecture

To ensure total safety, our “DevOps Guardian” middleware inspects every tool request against three distinct data sources in real-time:

1. Context (Who?): Does the current user have the required role (e.g., ‘Admin’)?
2. Store (Where?): Is the specific cluster currently locked for deletions?
3. State (When?): Has the user discussed this enough, or are they trying to delete things in the very first message?

2. Implementing the “DevOps Guardian”

Using the @wrap_model_call middleware, we can intercept the agent's tool "menu" and prune it before the LLM even sees it.

@wrap_model_call
def devops_guardian(request: ModelRequest, handler):
    # LAYER 1: Role-based Access (Context)
    role = request.runtime.context.role
        # LAYER 2: Cluster-specific Locks (Store)
    cluster_config = request.runtime.store.get(("config",), request.runtime.context.cluster)
    is_locked = cluster_config.value.get("locked", True)
    # LAYER 3: Conversation Depth (State)
    chat_depth = len(request.state["messages"])
    # Filter the tools
    allowed_tools = []
    for tool in request.tools:
        if tool.name == "delete_namespace":
            # ALL THREE locks must open
            if role == "admin" and not is_locked and chat_depth > 3:
                allowed_tools.append(tool)
        else:
            allowed_tools.append(tool)
    return handler(request.override(tools=allowed_tools))

3. Real-World Execution Scenarios

Let’s look at how this changes the AI’s behavior in different scenarios:

Scenario A: The Junior Developer on Prod

• Action: Try to restart a service.
• Result: BLOCKED. The middleware sees the junior role and simply hides the
• restart and
• delete tools. To the AI, these tools don’t even exist.

Scenario B: The Admin on a Locked Cluster

• Action: Delete a namespace.
• Result: BLOCKED. Even though the user is an admin, the Store (our configuration database) indicates that the production cluster is currently locked for deletions.

Scenario C: The Admin Rushing a Deletion

• Action: Delete a namespace in the first message.
• Result: BLOCKED. The State check sees that chat_depth is only 1. The gatekeeper forces a conversation first to prevent accidental destructive "one-shot" commands.

Conclusion: Governance as a Feature

By moving security logic out of the tools and into the Middleware Layer, you ensure that your safety rules are consistent across your entire application. Your tools stay simple (“how to delete”), while your middleware handles the complex “who, when, and where.”

This “Triple-Lock” pattern turns your AI from a risky experiment into a governed, enterprise-ready assistant.

💬 What do you think?
Drop your thoughts, questions, or suggestions in the comments below!

Check out my YouTube channel for more exciting content! [YouTube Channel Link — Harsha Selvi]

Disclaimer: This text has been rephrased using AI tools, and some parts are derived from various sources to provide a comprehensive overview.

#AI #CyberSecurity #LangChain #DevOps #SecurityAwareness #Python #AIEngineering #CloudSecurity