The "Kernel" release of the Agent Control Plane is finally here.

In my original post, I argued that intelligence without governance is a bug. I wrote about how we need to stop treating LLMs as magic boxes and start treating them as raw compute components that require a "kernel" to manage permissions, resources, and safety.

Today, I’m moving from theory to code.

I’ve released Agent Control Plane v0.1, and in this post, I want to walk you through the three features that turn that architectural concept into a tangible reality: Async Support, ABAC, and the Flight Recorder.

The Problem: Single-Threaded, Unsafe Agents

Most agent demos today are simple loops: User Input -> LLM -> Tool Call -> Output. This works fine for a chatbot, but it breaks down in production. What happens when you have five agents trying to access the same database? What happens when a "Support Agent" tries to refund $10,000 without approval?

We need a layer that sits between the agent and the world. We need a Kernel.

Feature 1: Async Support (Non-Blocking Operations)

Real production environments are concurrent. You can't have your entire system lock up while one agent waits for a tool to finish.

In v0.1, I’ve introduced fully async support. This allows the Kernel to intercept and mediate tool execution for multiple agents simultaneously without blocking the main event loop.

Here is how it looks in the demo. Notice how we can now run multiple agents (agent-1 and agent-2) concurrently:

# Multiple agents can operate concurrently
results = await asyncio.gather(
    kernel.intercept_tool_execution_async("agent-1", "read_data", {}),
    kernel.intercept_tool_execution_async("agent-2", "write_report", {}),
    kernel.intercept_tool_execution_async("agent-1", "analyze", {}),
)

This isn't just about speed; it's about throughput. If you are building a swarm or a multi-agent system, blocking calls are the enemy.

Feature 2: ABAC (Context-Aware Permissions)

This is the feature I am most excited about. Standard "Guardrails" usually just look at the text output (e.g., "Did the agent say something rude?"). But in an enterprise setting, we care about logic.

Attribute-Based Access Control (ABAC) lets us define permissions based on the state of the world, not just the role of the agent.

Take a look at this policy rule from the code. We don't just say "Finance Agent can refund." We say "Finance Agent can refund IF the user is verified AND the amount is under $1000."

# Setup: Finance agent can refund IF:
# 1. User is verified, AND
# 2. Amount is under $1000
conditions = [
    Condition("user_status", "eq", "verified"), 
    Condition("args.amount", "lt", 1000)
]

permission = ConditionalPermission("refund_user", conditions, require_all=True)
policy.add_conditional_permission("finance-agent", permission)

When I ran this in the demo, the results were deterministic:

• Verified user, $500 refund: ✅ ALLOWED
• Verified user, $1500 refund: ❌ BLOCKED
• Unverified user, $500 refund: ❌ BLOCKED

This moves safety from "prompt engineering" (begging the model to be good) to "policy engineering" (enforcing rules in code).

Feature 3: Flight Recorder (Audit Logging)

If an agent deletes a file or leaks data, you need to know exactly why it happened. Was it a prompt injection? A hallucination? A policy misconfiguration?

The Flight Recorder is a black-box audit logger that captures every decision the Kernel makes. It doesn't just log "Success/Fail"; it logs the policy verdict, the tool arguments, and the violation reason.

# Action: Blocked write (protected path)
kernel.intercept_tool_execution(
    "audit-agent", 
    "write_file", 
    {"path": "/etc/passwd"}, 
    input_prompt="User: Update system file"
)
# Result: ❌ Logged as BLOCKED

In the demo, I included a get_statistics() method that gives you an instant view of your agent's compliance health:

• Total actions: 3
• Allowed: 1
• Blocked: 2

What I Missed: The "Shadow Mode"

While building this demo, I realized there is a critical piece of the puzzle I didn't include in this specific file, but it is part of the broader architecture: Shadow Mode.

One of the biggest risks in deploying agents is fear. "What if it deletes the database?"

The Kernel architecture enables a "Shadow Mode" where you can run the agent against production inputs, have the Kernel intercept the tool calls, validate them against the ABAC policies, log the outcome (Success/Blocked), but never actually execute the tool.

This lets you "red team" your agents in production with zero risk. You can see "The agent would have processed this $5,000 refund, but the policy would have blocked it."

Code Availability

You can find the full source code for the demo, including the AgentKernel and PolicyEngine classes, in the repository:
github.com/imran-siddique/agent-control-plane