DEV Community: Imran Siddique

A signed JWT proves who called your API. It proves nothing about the agent that made the call. Not which system prompt...

Imran Siddique — Mon, 29 Jun 2026 21:20:55 +0000

A signed JWT proves who called your API. It proves nothing about the agent that made the call.

Not which system prompt defined its behavior. Not which model version ran. Not which tools were authorized. Not whether the policy bundle in memory matches what your security team reviewed. Not whether a human approved the configuration before it shipped.

Authentication answers "who is calling." Attestation answers "is the thing running right now the thing we approved." In regulated environments, it is the second question that gets your deployment signed off, and today almost nobody can answer it with anything stronger than operator documentation.

Every AI agent has ten surfaces that define its full trust boundary: system prompt, policy bundle, tool manifest, model identity, RAG corpus, memory baseline, decision trace, delegation, supply chain, and human approvals. None of them have a standard attestation mechanism. Each one is an unguarded door.

Agent Manifest binds all ten into one signed, hardware-attestable record, so a third party who does not trust the operator can still prove what actually ran. Open spec, on track for the Linux Foundation, shipped last week at the Confidential Computing Summit. Full breakdown in my newsletter, Proof, Not Promises.

If you are deploying agents against regulated data: which of those ten surfaces can you prove today, and which are still running on trust?

AIGovernance #AgentSecurity #ConfidentialComputing #OpenStandards #AgentManifest

New edition of Proof, Not Promises is live.

Imran Siddique — Mon, 29 Jun 2026 15:11:58 +0000

New edition of Proof, Not Promises is live.

Here: https://www.linkedin.com/pulse/prove-what-your-agent-just-who-called-imran-siddique-xtyuc/?trackingId=0NWBZruyTrSojWvmpDzYLw%3D%3D

AIGovernance #AgentSecurity #ConfidentialComputing #OpenStandards #AgentManifest

[Part 5] 20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Fri, 26 Jun 2026 20:36:44 +0000

If your agent processes data in Region A, reasons using a model in Region B, calls a tool in Region C, and stores results in Region D, whose laws apply?

As we move toward a global Agent OS, we have to face the fact that “Sovereignty” is actually two distinct problems stacked on top of each other.

1. The Sovereignty Stack

Deployment Jurisdiction: This is the physical reality of where your bits live. It’s about data residency, server location, and the local laws governing the hardware.
Operating-Model Jurisdiction: This is the governance framework that travels with the agent, regardless of where it’s hosted. It’s the set of rules that must apply even if the agent is operating in a “neutral” or cross-border environment.

Separating these is critical. You can have a sovereign deployment but a failed governance model, or a strict framework operating on insecure residency. To solve both, I built the Agent Governance Toolkit (AGT) with a zero-vendor-dependency architecture. It allows for air-gapped deployments while maintaining a consistent governance layer that doesn’t drift when the agent crosses digital borders.

2. The Illusion Delta and the Non-Deterministic OS

In Part 1, I introduced the Illusion Delta , the gap between an agent’s perceived safety and its actual behavior over time. This is why the traditional OS metaphor is breaking.

Traditional operating systems assume deterministic processes where functional correctness is a guarantee. LLM-powered agents are fundamentally non-deterministic. Because an agent can declare one intent and perform another, pre-action policy gates are no longer enough. The “Illusion Delta” exists precisely because agents can deviate after the gate has opened.

3. The Unified Architecture of Governance

To bridge this gap, we need a unified architectural stance rather than a list of parallel features. My philosophy for the future of Agent OS is built on three legs:

Continuous Observability fills the determinism gap by monitoring behavior in real-time.
Adaptive Trust solves the time-decay problem, adjusting permissions as observed behavior diverges from intent.
Human Authority is the load-bearing constraint that makes the other two viable.

Without human authority as the ultimate root of trust, observability and trust scoring have no baseline for “correctness.”

4. The Non-Negotiable Principle

In the future, agents will consume governance. They will read policies, suggest optimizations, and draft new rules. But the super-control , the ultimate authority to approve those rules, must never transfer to the agent.

This is the core of the AGT project: humans set the rules, agents follow them, and no amount of agent capability should change that hierarchy.

Series Wrap-Up

These 20 questions are the roadmap for the next generation of large-scale system design.

Observability is the new security.
Trust is earned and adaptive, never static.
Scale by Subtraction remains the goal: removing the complexity of manual oversight to make room for governed autonomy.

If you’re building with AI agents, these questions will find you. Better to answer them now.

Originally published at https://www.linkedin.com.

If you want to understand what Agent Governance Toolkit actually does, this is the best place to start. This video explains...

Imran Siddique — Thu, 25 Jun 2026 20:26:09 +0000

If you want to understand what Agent Governance Toolkit actually does, this is the best place to start. This video explains the thinking behind it better than most of what I've written.

Worth watching if you're building with agents, evaluating governance tools, or just trying to understand what responsible deployment actually looks like at the infrastructure level.

https://lnkd.in/gvYHDhqy

A few things you'll see covered:

🔒 Policy evaluation at the agent boundary, not the app layer

📋 Audit trails that work without touching your agent code

⚖️ Human-in-the-loop escalation chains

🛡️ Sandbox enforcement with command denylists

🌐 Python, TypeScript, .NET, Rust, Go — all supported

Open source, MIT licensed.

AgentGovernance #AIAgents #ResponsibleAI #OpenSource #AIInfrastructure #MultiAgentSystems #LLMOps #AICompliance #AgentGovernanceToolkit #AIEngineering

[Part 4] 20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Tue, 02 Jun 2026 20:02:34 +0000

Part 4: The Next SolarWinds Will Be an MCP Server

The agent supply chain is currently in a “pre-SolarWinds” era. While we are seeing an explosion in agentic capabilities, the security infrastructure is lagging behind.

The early telemetry from 2026 is a wake-up call:

492 exposed Model Context Protocol (MCP) servers have been discovered in recent scans.
1,184+ malicious skill packages are already circulating in open repositories.
Remote code execution (RCE) via tool metadata is no longer a theoretical risk; it’s a verified vulnerability.

We are currently doing “trust-on-first-use” for many agentic tools. That is the equivalent of running npm packages without checking signatures. It isn’t a matter of if a major supply chain attack happens through an agent tool, but when.

1. Governing the Supply Chain

In building the Agent Governance Toolkit (AGT), I’ve focused on a tiered defense strategy to secure this “negative space”:

Shift-Left Governance: We must validate tool definitions and MCP server configurations during the CI/CD process, catching violations before they ever reach production.
The MCP Governance Proxy: A deterministic enforcement layer that intercepts every tools/call. If the call doesn’t match a pre-approved signature or violates a safety constraint, the execution is blocked instantly.
Zero-Trust for Tools: Treat every third-party MCP server as untrusted by default. Governance must sit as a kernel-level layer between the reasoning model and the tool execution environment.

2. We Need a “Decision BOM”

Software has SBOMs (Software Bill of Materials) to track dependencies. Autonomous systems need a Decision BOM, a verifiable, immutable record that traces a decision back to its root signals.

A Decision BOM allows you to audit the entire chain of thought:

The Model: Which version and reasoning trace was used?
The Retrieved Context: What specific data (RAG) grounded the decision?
The Tool Outputs: Which external data points influenced the next step?
The Policies: Which specific rules were active at the millisecond of execution?

This is the foundation of root cause analysis. When an agent fails, you shouldn’t be guessing why; you should be auditing the Decision BOM.

3. Debugging Architectures, Not Just Prompts

Today, when an agent makes a mistake, the reflex is to “fix the prompt.” But in a complex supply chain, the failure is often architectural, a poisoned context, a compromised tool, or a logic collision between agents.

By implementing a Decision BOM, we move from reactive prompt engineering to proactive Forensic Engineering. This is the next frontier for AGT: making the “why” behind every agent action transparent, deterministic, and tamper-proof.

What’s Next?

In Part 5, we look at the map: Sovereignty and Jurisdiction. Where does “reasoning” actually happen, and whose laws apply when an agent processes data across digital borders?

Originally published at https://www.linkedin.com.

[Part 3] 20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Tue, 02 Jun 2026 19:59:44 +0000

Part 3: Who Controls the Money (And Who Is Liable)?

Agents are no longer just “chatting.” They are transacting. Stripe payments, autonomous procurement, and automated cloud resource allocation are the new baseline. But the industry’s financial governance for agents is currently a blank page.

It is not enough to ask, “Can this agent call the payment API?” We’ve solved that. The real question is: “ Should this agent spend $50,000 on cloud compute at 2 AM without human escalation? ”

1. Financial Governance is Tool Call Parameter Governance

We must move beyond binary tool permissions toward parameter-level policies.

The Old Way: “The agent has permission to use the Stripe Tool.”
The AGT Way: “The agent can call the Stripe Tool, but the amount parameter cannot exceed $X, and the recipient must be on a pre-approved whitelist. Anything else triggers a hard block.”

In the Agent Governance Toolkit (AGT), cost is a first-class citizen. We prioritize deterministic caps (hard budget limits) first, using non-deterministic anomaly detection only as a secondary fallback.

2. Human-in-the-loop is a 2026 Fiction

The EU AI Act and global safety standards often mandate “human oversight.” But let’s look at the Manager’s Math:

AGT benchmarks show 47,000 governed actions per second across 1,000 concurrent agents. No human, no matter the team size, can “oversee” that in real-time. If you put a human in the hot path of an autonomous system, you aren’t governing; you’re bottlenecking.

The Evolution: We must move from Human-in-the-loop to Human-over-the-loop:

Humans define the boundaries: We set the policies and constraints.
Humans monitor the health: We build dashboards for system-wide SLOs.
Humans investigate the anomalies: We respond to alerts, not individual actions.

This is the same maturation process we saw in infrastructure. We don’t approve every packet in a firewall; we set the rules and monitor the telemetry. Agent governance must follow the same path.

3. AGT as the Underwriting Layer for AI Insurance

Insurance giants like Munich Re, Armilla AI, and Coalition are entering the AI liability space. However, premiums remain volatile because they lack standardized governance telemetry.

AGT produces exactly what they need: Append-only, hash-chained, tamper-evident audit trails with full action attribution.

This isn’t just a log; it’s Underwriting Data. By showing insurance companies exactly how policies were enforced and how trust scores evolved over time, we build the necessary bridge between technical telemetry and actuarial models.

4. Who is Liable for the “Bug”?

When a coding agent ships a vulnerability, where does the buck stop?

*The Developer who approved the PR? * Yes.
*The Company that deployed the agent? * Yes.
The Agent Framework? No. They provide tools, not decisions.
The Toolkit? Only if the engine failed to enforce a set policy.

Liability follows the decision-maker, not the enforcement mechanism. This is why AGT puts policies outside the toolkit. The toolkit is the enforcement engine; the user is the policy author. Liability stays with the human who defines what “Safe” looks like.

What’s Next?

In Part 4, we face the supply chain. The next SolarWinds won’t be a library; it will be a malicious MCP Server. We’ll talk about the “Decision BOM” and how to trace the root cause of a failed agent decision.

Originally published at https://www.linkedin.com.

[Part 2] 20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Sun, 10 May 2026 00:10:28 +0000

Part 2: Governing the Flock, Not Just the Bird

Current agent governance, including the initial versions of AGT , was built for a world of single-agent actions. But the scariest risks we are seeing in 2026 are emergent : swarms of individually compliant agents producing collectively dangerous behavior.

Collusion. Feedback loops. Race dynamics.

These don’t happen in a sandbox; they happen when “safe” agents interact in production. New research, like the SWARM framework and the Multi-Agent System Safety Standard (MASSS), is finally catching up. But the industry still lacks a runtime enforcement mechanism for collective behavior.

The Solution: Two Critical Architectural Moves

1. Policies Must Become Multi-Agent Aware

Today, a policy evaluates one agent’s one action. Tomorrow, it needs to evaluate across agents: “What are all agents doing collectively? Does this pattern, though individually permitted, look like a coordinated attack or market manipulation?”

2. Agent Mesh Needs Its Own Policy Layer

Agent OS governs individual actions. Agent Mesh needs policies governing inter-agent behavior. This is a distinct policy surface that handles the “handshake” between agents, ensuring that the intent of the sender matches the capability of the receiver.

Who is accountable in a delegation chain?

If Agent A delegates to Agent B, who delegates to Agent C, and Agent C causes harm, who do you fire? More importantly, who does the governance layer penalize?

My Principle: Accountability flows upward.

Agent B is responsible because B trusted C.
Agent A is responsible because A trusted B.

While Accountability flows upward, Harm Impac t flows downward: it’s highest at the point of execution (Agent C). To bridge this, delegating agents must inherit partial accountability for their delegates. If your delegate misbehaves, your trust score should decay alongside theirs.

Can agents from different organizations ever truly trust each other?

No. And they shouldn’t.

Agents should never fully trust each other, just like humans don’t. We need to move away from binary “Trust/No-Trust” states toward a Human Interaction Model :

Verify Identity : Is this agent who it says it is?
Verify Capability : Does it actually do what it claims?
Experience-Based Trust : Trust is earned through repeated, successful interactions.
Bounded Autonomy : Never give full trust; give only enough to get the specific task done.

Cross-org trust is not a shared global score. It is experiential and local. Each organization must build and maintain its own trust profile for external agents.

The “Illusion Delta”

The biggest trap of 2026 is the Illusion Delta , the gap between how safe an agent looks in a short-horizon interaction and how unstable it actually is when replayed at scale. Governance that doesn’t account for this delta isn’t governance; it’s a false sense of security.

What’s Next?

In Part 3, we move into the “Money” phase: Financial Governance. Your agents might be building a pricing cartel or spending $50K while you sleep. How do we govern the wallet?

Originally published at https://www.linkedin.com.

20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Mon, 04 May 2026 23:19:56 +0000

Part 1: Can You Actually Prove an Agent Is Safe?

I’ve spent the last year building the Agent Governance Toolkit (AGT), an open-source runtime governance layer for AI agents.

13,000+ tests
5 SDK languages
19+ framework integrations
Coverage for all 10 OWASP Agentic Top 10 risks

But the more I build, the more I realize: the hardest problems in agent governance aren’t the ones we’ve solved. They’re the ones nobody is even asking about yet.

Here are the questions I think the industry needs to wrestle with.

“You’re measuring the wrong thing.”

AGT enforces policy with a 0.00% violation rate in red-team testing. Sounds impressive, right?

But here’s the uncomfortable truth: we’re proving the policy layer works, not that the agent is safe.

When an agent says, “I want to do a file operation,” we check the policy and say yes or no. But what happens after we say yes? Did the agent actually do what it claimed?

Maybe it asked for a file read but triggered a secondary, unauthorized tool call. We have audit logs, but by the time you read them, the damage is done.

My Answer: The Continuous Loop

Governance can’t be a one-time gate check. It has to be a dynamic, multi-stage architecture:

Pre-action: Deterministic policy enforcement (The “Fast Gate” — we’ve solved this).
Post-action: Continuous validation of what the agent actually did vs. what it asked permission to do.
Adaptive Trust: If observed behavior diverges from declared intent, the agent’s trust score decays in real time.

We already use trust scoring for agent-to-agent communication in Agent Mesh. That same mechanism must apply to standalone single agent runs. An agent that asks for permission to do A but ends up doing B should see its trust erode until the governance layer intervenes.

Can formal verification work for non-deterministic systems?

Short answer: Yes, but it has to be a hybrid.

You need deterministic checks (policy enforcement, capability constraints) combined with non-deterministic checks (behavioral anomaly detection, pattern analysis). Pre-execution and post-execution. Not one or the other.

The “Illusion Delta”:

In 2026, the industry is falling into a trap, agents perform safely in short-horizon tests but exhibit deviant emergent behavior in long-running production environments.

The missing piece? The Observability Layer. We need checks that observe how agents behave in real time, not just what they asked to do. This is the bridge between verifying policy and verifying behavior.

The Intent Problem

An agent reads your customer database (allowed). Then sends a Slack message (also allowed). But was it exfiltrating data?

You can’t govern intent by reading the agent’s “mind.” But you can govern it through Sequence Analysis : a sequence of individually allowed actions that looks like exfiltration is a signal.

The Thesis : The future of agent governance is not just pre-action policy gates. Its continuous behavioral observability combined with adaptive trust scoring.

What’s Next?

In Part 2, I’ll dive into “ Governing the Flock, Not Just the Bird ”, how to handle multi-agent swarms and delegation chains where accountability gets messy.

Originally published at https://www.linkedin.com.

Governing Google ADK Agents with Microsoft’s Open-Source Toolkit: A GCP-Native Guide

Imran Siddique — Wed, 22 Apr 2026 00:33:23 +0000

How to add deterministic policy enforcement to your Google ADK agents on GKE

I’m going to share a combination that might initially seem counterintuitive: Microsoft’s best open-source security toolkit runs natively on Google Cloud, securing Google ADK agents. No Azure subscription is required. No vendor lock-in exists. It is a simple pip install away.

The Agent Governance Toolkit (AGT) is an MIT-licensed runtime governance layer for AI agents. It is cloud-agnostic and framework-agnostic. It functions as a Python middleware layer that intercepts agent actions, tool calls, API requests, and inter-agent messages, enforcing policies before execution occurs.

If you are building agents with Google ADK and deploying on Google Kubernetes Engine (GKE), this guide provides a path to a governed production environment in under 10 minutes.

The Problem AGT Solves

Google ADK provides a high-performance framework for agent construction, but it is not a deterministic security engine. To move beyond “vibe-based” security to a system that meets the requirements of a CISO or the EU AI Act (August 2, 2026), you need more than system prompts.

Runtime Action Control: Hard-coded blocking of dangerous calls like execute_code or modify_iam.
Audit Trails: A forensic record of why an action was permitted or denied, stored outside the LLM context.
Content Filtering: Preventing agents from leaking PII (SSNs, passwords) in tool arguments or model responses.
Deterministic Latency: Governance that runs in-process to avoid adding network hops to already latent LLM calls.

Architecture: Scale by Subtraction on GCP

Deploying AGT within your GKE cluster follows the principle of Scale by Subtraction. By integrating governance at the kernel level within your existing Python process, you subtract the complexity of managing external security proxies or cross-cloud dependencies.

Step 1: The 5-Line Quick Start

Govern your tool calls locally before containerization. Note that this logic is deterministic, not probabilistic.

from agent_os.lite import govern

# Define governance policy: Deterministic, not prompt-based
check = govern(
    allow=["google_search", "read_file", "summarize"],
    deny=["execute_code", "delete_file", "modify_database"],
    blocked_content=[r'\b\d{3}-\d{2}-\d{4}\b'], # Block SSN patterns
)
# Wrap your tool calls
def governed_tool_call(tool_name: str, args: dict):
    # Intercepts and validates before the tool executes
    check(tool_name, content=str(args)) 
    return call_original_tool(tool_name, args)

Step 2: Full Google ADK & Vertex AI Integration

In this updated example, we use Gemini 2.0 Flash. Because AGT runs in-process, it adds sub-0.1ms overhead, preserving the low-latency benefits of the Flash model.

from google.adk.agents import Agent
from google.adk.tools import Tool
from agent_os.lite import govern, GovernanceViolation

# Governance Layer: Configured for Enterprise Standards
check = govern(
    allow=["google_search", "read_gcs", "summarize"],
    deny=["delete_gcs", "modify_iam"],
    blocked_content=[r'\b(?:\d[-]*?){13,16}\b'], # Credit Card patterns
    log=True,
)
def governed_read_gcs(bucket: str, path: str):
    """A tool that requires verified governance before access."""
    check("read_gcs") 
    # Logic to interface with GCS via Workload Identity
    return f"Contents of gs://{bucket}/{path}"
agent = Agent(
    model="gemini-2.0-flash",
    name="governed-researcher",
    tools=[
        Tool(func=governed_read_gcs, description="Read data from GCS"),
    ],
)

Step 3: Containerize and Deploy to GKE

Dockerfile

FROM python:3.12-slim
WORKDIR /app
# Install core dependencies and GCP logging
RUN pip install --no-cache-dir agent-os-kernel google-adk google-cloud-logging
COPY agent.py .
CMD ["python", "agent.py"]

GKE Deployment Configuration

Deploying to GKE allows governance to scale horizontally with your agent replicas.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: governed-adk-agent
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: agent
          image: gcr.io/YOUR_PROJECT/governed-adk-agent:latest
          env:
            - name: GOOGLE_CLOUD_PROJECT
              value: "your-project-id"

Step 4: Observability and Compliance

Don’t just block actions; record them for the auditors. AGT’s audit trail integrates with Google Cloud Logging , which can then be exported to BigQuery for automated compliance reporting.

import google.cloud.logging
import logging

# Initialize GCP Logging
client = google.cloud.logging.Client()
client.setup_logging()
logger = logging.getLogger("agt.governance")
# After agent execution, flush the audit trail to GCP
for decision in check.audit_trail:
    logger.info("governance_decision", extra={"json_fields": decision.to_dict()})

Manager’s Math: The Trade-off Analysis

Strategic Considerations for 2026

Workload Identity & OIDC: AGT’s AgentMesh identity layer can map directly to GCP’s Workload Identity. This allows you to verify that the “Agent” calling a GCS bucket is not just authenticated via a service account but authorized via a governance policy.
The 2026 Compliance Window: With the EU AI Act becoming enforceable, “best effort” security is no longer a legal defense. Moving policy enforcement from the prompt to the execution kernel is a prerequisite for high-risk AI deployment.
Vertex AI Extensions: While Vertex AI Extensions handle authorization, AGT handles interception and inspection. They are complementary, not competitive.

Links

The Agent Governance Toolkit is MIT-licensed and functions across all major cloud providers. Star it on GitHub if it provides value to your engineering stack.

Running AI Agent Governance on AWS, No Azure Required

Imran Siddique — Tue, 14 Apr 2026 04:41:20 +0000

How to deploy Microsoft’s Agent Governance Toolkit on ECS/Fargate and govern your Bedrock agents

I’m going to say something that might surprise you: Microsoft’s best open-source security toolkit runs perfectly on AWS. No Azure subscription. No vendor lock-in. Just pip install and go.

The Agent Governance Toolkit (AGT) is an MIT-licensed runtime governance layer for AI agents. It intercepts every tool call, API request, and inter-agent message before execution — enforcing policies at sub-millisecond latency. It covers all 10 OWASP Agentic AI risks, and it works with LangChain , CrewAI , AutoGen , Bedrock agents, and anything else you’re building on AWS.

Here’s how to get it running on your AWS infrastructure in under 30 minutes.

Why You Need This

If you’re running AI agents on Bedrock, Lambda, or ECS, you probably already know the problem:

Unpredictable Tool Calls: Your agents can call tools or parameters you didn’t anticipate.
Invisible Audit Trails: There’s no deterministic record of what actions agents took and why.
Least-Privilege Enforcement: You can’t easily prove to your CISO that agents follow security best practices.
Compliance Deadlines: The EU AI Act (August 2026) requires demonstrable human oversight and risk management for high-risk AI systems.

AGT solves this by placing a deterministic safety kernel between agent “thought” and system “action.” Everything gets logged, dangerous actions get blocked, and your compliance team gets the evidence they need.

Architecture

┌─────────────────────────────────────────────┐
│ Your AWS Account │
│ │
│ ┌──────────┐ ┌──────────────────────┐ │
│ │ Bedrock │───▶│ AGT Policy Engine │ │
│ │ Agent │ │ (ECS/Fargate) │ │
│ └──────────┘ │ │ │
│ │ ✓ Policy check │ │
│ ┌──────────┐ │ ✓ Identity verify │ │
│ │ Lambda │───▶│ ✓ Audit log │ │
│ │ Agent │ │ ✓ Rate limit │ │
│ └──────────┘ └──────────┬───────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ CloudWatch / │ │
│ │ S3 Audit Logs │ │
│ └─────────────────┘ │
└─────────────────────────────────────────────┘

Zero Azure dependencies. Pure Python containers.

Step 1: The 3-Line Quick Start

Before we containerize, let’s prove it works locally:

pip install agent-os-kernel

from agent_os.lite import govern

# One line: define what's allowed and what's blocked
check = govern(
    allow=["web_search", "read_file", "query_database"],
    deny=["execute_code", "delete_file", "ssh_connect"],
)

# One line: check any agent action
check("web_search") # ✅ Allowed
check("execute_code") # 💥 GovernanceViolation raised
check.is_allowed("delete_file") # False (non-raising)

That’s it. Three lines. Sub-millisecond. No complex YAML, no config files, no trust mesh. Just a fast allow/deny gate.

Step 2: Create the Dockerfile

FROM python:3.12-slim

WORKDIR /app

# Install AGT
RUN pip install --no-cache-dir agent-os-kernel[full]

# Copy your policies and agent code
COPY policies/ ./policies/
COPY app.py .

CMD ["python", "app.py"]

Step 3: Write Your Governed Agent

Here’s a real agent wrapper that works with any Bedrock model:

# app.py — Governed agent on AWS
import json
import boto3
from agent_os.lite import govern

# --- Governance setup ---
check = govern(
    allow=["invoke_model", "read_s3", "query_dynamodb", "send_sns"],
    deny=["delete_s3", "modify_iam", "execute_code", "create_ec2"],
    blocked_content=[
        r'\b\d{3}-\d{2}-\d{4}\b', # SSN
        r'\b(?:\d[-]*?){13,16}\b', # Credit cards
    ],
    max_calls=100,
    log=True,
)

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

def governed_invoke(action: str, payload: dict) -> dict:
    """Every action goes through governance first."""
    # Check the action
    check(action)

    # Check the content for PII
    content = json.dumps(payload)
    if not check.is_allowed(action, content=content):
        return {"error": "Blocked: content contains sensitive data"}

    # Execute the actual action
    if action == "invoke_model":
        response = bedrock.invoke_model(
            modelId=payload["model"],
            body=json.dumps(payload["body"]),
        )
        return json.loads(response["body"].read())

    return {"error": f"Unknown action: {action}"}

# --- Your agent loop ---
if __name__ == " __main__":
    # This will work
    result = governed_invoke("invoke_model", {
        "model": "anthropic.claude-sonnet-4-20250514",
        "body": {"prompt": "Summarize Q4 earnings"}
    })
    print(f"✅ Model response received")

    # This will be blocked
    try:
        governed_invoke("delete_s3", {"bucket": "production-data"})
    except Exception as e:
        print(f"🚫 Blocked: {e}")

    # Print governance stats
    print(f"\n📊 {json.dumps(check.stats, indent=2)}")

Step 4: Deploy to ECS/Fargate

Create the ECR repository and push:

aws ecr create-repository --repository-name agt-governed-agent
aws ecr get-login-password | docker login --username AWS --password-stdin $ACCOUNT.dkr.ecr.us-east-1.amazonaws.com

docker build -t agt-governed-agent .
docker tag agt-governed-agent:latest $ACCOUNT.dkr.ecr.us-east-1.amazonaws.com/agt-governed-agent:latest
docker push $ACCOUNT.dkr.ecr.us-east-1.amazonaws.com/agt-governed-agent:latest

ECS Task Definition:

{
  "family": "agt-governed-agent",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [
    {
      "name": "governed-agent",
      "image": "${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com/agt-governed-agent:latest",
      "essential": true,
      "environment": [
        {"name": "AWS_DEFAULT_REGION", "value": "us-east-1"}
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/agt-governed-agent",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "agt"
        }
      }
    }
  ],
  "executionRoleArn": "arn:aws:iam::${ACCOUNT}:role/ecsTaskExecutionRole"
}

Create the service:

aws ecs create-service \
  --cluster default \
  --service-name agt-governed-agent \
  --task-definition agt-governed-agent \
  --desired-count 1 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-xxx],securityGroups=[sg-xxx],assignPublicIp=ENABLED}"

Your governed agent is now running on AWS. Every action is policy-checked and audit-logged.

Step 5: Production Policy (Optional Upgrade)

When you outgrow the 3-line govern() call, AGT has production-ready policy files:

# Copy the enterprise policy template
cp examples/policies/production/enterprise.yaml policies/

# Or for financial services:
cp examples/policies/production/financial.yaml policies/

These include action rules, content filters (PII/PCI), escalation triggers, and retention settings — all in YAML. No OPA or Rego required unless you want it.

Step 6: Ship Audit Logs to S3

AGT’s audit trail integrates with CloudWatch. For compliance archival:

# Send governance stats to CloudWatch
import boto3

cloudwatch = boto3.client("cloudwatch")
stats = check.stats

cloudwatch.put_metric_data(
    Namespace="AGT/Governance",
    MetricData=[
        {"MetricName": "TotalDecisions", "Value": stats["total"], "Unit": "Count"},
        {"MetricName": "Denied", "Value": stats["denied"], "Unit": "Count"},
    ]
)

What You Get

FAQ

Q: Does this need Azure?

No. Zero Azure dependencies. It’s a Python package that runs anywhere you can run Python.

Q: Does it slow down my agents?

No. Policy checks take 0.003ms on average. Your Bedrock API call takes 500–2000ms. The governance overhead is invisible.

Q: Can I use this with LangChain on AWS?

Yes. AGT works with LangChain, CrewAI, AutoGen, and any other Python agent framework.

Q: What about the full AGT stack (trust mesh, SRE, etc.)?

Start with agent_os.lite for basic governance. Add the full stack when you need cryptographic identity, lifecycle management, or execution sandboxing.

Links

The Agent Governance Toolkit is MIT-licensed. Star it on GitHub if it’s useful to your team.

Observability for Non-Deterministic Systems: A Framework for AI Agent Reliability

Imran Siddique — Mon, 06 Apr 2026 15:54:22 +0000

The Observability Gap

For fifty years, the observability stack has assumed determinism. Prometheus scrapes CPU utilization. Jaeger traces request latency. PagerDuty fires when error rates exceed thresholds. The mental model is mechanical: if the database is slow, queries are slow; if the server crashes, requests fail. The “Three Pillars”: metrics, logs, traces, capture the behavior of infrastructure.

This model works because deterministic systems have a knowable correct state. A 200 OK is correct. A 500 is not. The boundaries are crisp, and deviations are bugs.

Why AI Agents Break This Model

AI agents introduce properties that deterministic observability cannot capture:

Non-determinism: The same prompt produces different outputs on successive calls. Traditional monitoring treats variance as noise; in agent systems, variance is the signal.
Semantic correctness: A 200 OK with a hallucinated answer is worse than a 500 error. HTTP status codes carry zero information about output quality. An agent that confidently produces wrong code or wrong medical advice is more dangerous than one that crashes.
Progressive degradation: As context windows fill, LLM output quality degrades gradually, responses get shorter, less accurate, and more repetitive. This is Context Rot. There is no error. There is no crash. There is only a slow rot that traditional monitoring cannot see.

The “Laziness” Problem

During my work observing coding agents at scale, I discovered a failure mode that no existing observability tool detected: agent laziness. The agent would produce syntactically valid but substantively empty responses, placeholder functions, TODO comments instead of implementations, or responses that technically answered the question while doing as little work as possible.

This is not a hallucination. It is not an error. It is a quality degradation that only becomes visible when you measure the gap between what was asked and what was delivered. This discovery led to the development of a Laziness Index that measures response length shrinkage, placeholder patterns, and delegation frequency. The metrics we were building for coding agents were actually capturing fundamental properties of human-agent collaboration.

The Framework: Behavioral Observability

Observability for non-deterministic systems requires a shift from infrastructure metrics to behavioral metrics. We must measure not what the system is doing (CPU, memory, latency) but what the system is achieving (correct outcomes, user satisfaction, progressive quality).

Core Principle: The Human as Sensor

In human-agent collaboration, the human’s behavior is the most reliable signal of agent quality. When a developer says “that’s wrong, fix it,” they are providing a ground-truth quality signal that no automated evaluation can match.

This is Correction-Based Observability : the systematic detection and scoring of human corrections to agent outputs as a proxy for output quality.

Seven Behavioral Metrics

Hallucination Index: Rate of human corrections to agent outputs.
Laziness Index: Response quality degradation and effort avoidance.
Context Rot Index: Quality degradation over session length.
Flow Score: Consecutive productive interactions without correction.
Loop Rate: Consecutive correction cycles without progress.
Session Health: Three-tier classification (Clean, Bumpy, Troubled).
Cost Per Outcome: Token spend divided by tangible deliverables.

Application Across High-Stakes Domains

The correction-based observability pattern is universally applicable to any human-agent collaboration where the human can signal dissatisfaction.

Healthcare: Clinical Decision Support

A hallucinating coding agent produces a bug. A hallucinating clinical agent produces a misdiagnosis. In this domain, the framework uses tighter thresholds. A 15% hallucination rate in coding is a productivity issue; in healthcare, the threshold for a “Troubled” session is often a single override.

Energy and Grid Management

In energy systems, the consequences of errors manifest in physical system behavior. The observability layer tracks Physical Constraint Violation Rates — recommendations that violate thermal limits or voltage bounds — which are physically impossible “hallucinations.”

Financial Services and Legal

Finance: Measuring the Fair Lending Deviation Index to track if underwriter overrides vary by borrower demographics.
Legal: Monitoring the Citation Hallucination Index to detect non-existent case law before it reaches a court filing.

Architecture: Privacy-First and Local-First

Behavioral observability data is sensitive. A correction log reveals what an expert (a doctor, an attorney, an engineer) had to fix.

The proposed architecture for this framework is local-first : all computation happens on the practitioner’s machine. No raw sessions or corrections leave the device. Team-level aggregation uses anonymized identities and transmits only aggregate metrics. This removes the primary barrier to AI observability: the fear that the tool will expose individual performance rather than system reliability.

Conclusion

Non-deterministic observability is not a product; it is a discipline. As we scale agentic architectures, we must stop measuring what agents consume (tokens, latency) and start measuring what they achieve.

While the foundational primitives for agent tracking exist in the open-source Agent Governance Toolkit (AGT), this behavioral framework represents a necessary evolution in how we ensure AI reliability at scale.

Securing AI agents with agent governance

Imran Siddique — Thu, 26 Mar 2026 07:16:00 +0000

Photo by Tekton on Unsplash.

Imagine this scenario: An AI agent is asked to “clean up old records,” and it interprets “old” as “everything older than today.” There is no policy engine to intercept the action, no approval workflow to pause and ask a human, and no kill switch to stop it mid-execution. The agent has been given unrestricted tool access — the equivalent of handing a new employee the root password on their first day and saying, “figure it out.”

This hypothetical illustrates a real and growing concern. As AI agents have evolved from simple chatbots into autonomous systems that book flights, execute trades, write code, and manage infrastructure, a gap has emerged: Many of the popular frameworks that power these agents focus on orchestration and have not yet built in runtime security governance. Frameworks like LangChain, AutoGen, and CrewAI do an excellent job of orchestrating agent behavior, but the industry as a whole is still developing answers to a fundamental question: What happens when an agent does something it shouldn’t?

Note: The Agent Governance Toolkit is currently available as a community preview release. All packages published to PyPI and npm are not official Microsoft-signed releases. Official signed packages via ESRP Release will be available in a future release. All security policy rules and detection patterns ship as configurable sample configurations that users must review and customize before production use.

That question sent me down a path that eventually became the Agent Governance Toolkit — an open-source framework, now released by Microsoft, that brings operating system-level security concepts to the world of AI agents. In this article, I walk through the problem we set out to solve, the architectural decisions that shaped our approach, and the technical details of how we built a system that enforces policy, verifies identity, isolates execution, and engineers reliability for autonomous AI agents.

The problem: AI agents operate in a security vacuum

To understand why agent governance matters, consider how a typical AI agent works today. A developer writes a prompt, connects a set of tools (database access, web browsing, file system operations), and hands control to an LLM. The agent reasons about what to do, selects tools, and executes actions — often in a loop, sometimes spawning sub-agents to handle subtasks.

The challenge is that in many current implementations, agent actions are unmediated. When an agent calls a tool, there is typically no security layer checking whether that call is within policy. There is often no identity verification when one agent communicates with another. There may be no resource limit preventing an agent from making 10,000 API calls in a minute. And there is frequently no circuit breaker to stop a failing agent from cascading failures across a system.

In February 2026, OWASP published the Agentic AI Top 10 (see owasp.org/www-project-agentic-ai-threats), the first formal taxonomy of risks specific to autonomous AI agents. The list highlights serious concerns for anyone running agents in production: goal hijacking through prompt injection, tool misuse, identity abuse, memory poisoning, cascading failures, and rogue agents. My team realized that addressing these risks required more than a guardrail library. It required a fundamentally new abstraction layer.

The insight: What if we treated AI agents like processes?

The key insight came from an analogy that now seems obvious in hindsight, because operating systems solved a similar problem decades ago.

In the 1970s, when multi-user computing emerged, engineers faced a similar challenge: multiple untrusted programs sharing resources on a single machine. The solution they developed was the OS kernel — a privileged layer that mediates every interaction between a process and the outside world. Processes can’t directly access hardware; they make syscalls. They can’t read each other’s memory; they have isolated address spaces. They can’t consume unlimited resources; the scheduler enforces quotas.

So, we asked ourselves: What would an “operating system for AI agents” look like?

The answer became the four-layer architecture of the Agent Governance Toolkit:

Agent OS: The kernel. Every agent action passes through a policy engine before execution, just as every process action passes through the OS kernel via syscalls.
AgentMesh: The identity layer. Agents have cryptographic identities (DIDs with Ed25519 key pairs) and must verify each other before communicating, similar to how mTLS works in service meshes.
Agent Runtime: The isolation layer. Agents are assigned to execution rings based on their trust scores, with resource limits enforced per ring — inspired by CPU privilege rings.
Agent SRE: The reliability layer. SLOs, error budgets, circuit breakers, and chaos testing — all the practices that keep distributed services reliable, applied to agent systems.

Under the hood: How policy enforcement actually works

Let me show you what runtime policy enforcement looks like in practice, because it’s the piece that distinguishes this toolkit from existing approaches.

Most “guardrail” systems work by filtering inputs or outputs — they check the prompt before the LLM sees it, or they scan the response after the LLM generates it. The problem is that agent actions happen between those two points. An agent might receive a perfectly safe prompt, reason correctly about it, and then call a tool in a way that violates policy. Input/output filtering misses this entirely.

Agent OS intercepts at the action layer. When an agent calls a tool, the call passes through the policy engine before reaching the tool:

from agent_os import StatelessKernel, ExecutionContext, Policy

kernel = StatelessKernel()

# Define what this agent is allowed to do
ctx = ExecutionContext(
    agent_id="analyst-001",
    policies=[
        Policy.read_only(), # Default: no writes
        Policy.rate_limit(100, "1m"), # Max 100 calls/minute
        Policy.require_approval(
            actions=["delete_*", "write_production_*"],
            min_approvals=2,
            approval_timeout_minutes=30,
        ),
    ],
)

# This call gets intercepted by the policy engine
result = await kernel.execute(
    action="delete_user_record",
    params={"user_id": 12345},
    context=ctx,
)
# result.signal == "ESCALATE" → approval workflow initiated

The key design decision here was to make the kernel stateless. Each request carries its own context — policies, history, identity — rather than storing state in the kernel. We chose this pattern because it enables horizontal scaling: You can run the kernel behind a load balancer, in a serverless function, or as a sidecar container, with no shared state to manage.

The policy engine itself has two layers. The first is configurable pattern matching with sample rule sets for detecting dangerous strings like “ignore previous instructions” or SQL injection patterns. The second is a semantic intent classifier that detects dangerous goals even when the exact phrasing does not match a pattern. When an agent’s action is classified as DESTRUCTIVE_DATA, DATA_EXFILTRATION, or PRIVILEGE_ESCALATION, the policy engine flags it for intervention regardless of how the request was worded.

Zero-trust identity: TLS for AI agents

When we started looking at multi-agent systems — scenarios where multiple agents collaborate on a task — the identity challenge became clear. In many frameworks, agents communicate as simple function calls. Agent A calls Agent B, and Agent B processes whatever it receives because identity verification has not yet been a standard feature of agent communication protocols.

AgentMesh introduces a protocol we call IATP — the Inter-Agent Trust Protocol. Think of it as TLS for AI agents: encryption, authentication, and authorization in one handshake.

Every agent gets a cryptographic DID (Decentralized Identifier) backed by an Ed25519 key pair:

from agentmesh import AgentIdentity, TrustBridge

# Create identity with a human sponsor for accountability
identity = AgentIdentity.create(
    name="data-analyst",
    sponsor="alice@company.com",
    capabilities=["read:data", "write:reports"],
)
# identity.did → "did:mesh:data-analyst:a7f3b2..."

# Before communicating, verify the peer
bridge = TrustBridge()
verification = await bridge.verify_peer(
    peer_id="did:mesh:other-agent",
    required_trust_score=700, # Must score ≥700/1000
)

if verification.verified:
    await bridge.send_message(peer_id, encrypted_message)

One design choice that proved critical was trust decay. An agent’s trust score isn’t static — it decays over time without positive signals. An agent that was trusted yesterday but has been silent for a week gradually becomes untrusted. This models reality: In the physical world, trust requires ongoing demonstration of good behavior, and our system reflects that.

Delegation chains solve another real-world problem: When an orchestrator agent delegates a task to a worker agent, the worker should have only the permissions needed for that specific task. AgentMesh enforces scope narrowing — a parent with read and write capabilities can delegate only read access to a child, and that child cannot re-delegate broader permissions than it received.

Execution rings: Hardware security concepts for software agents

The Agent Runtime borrows from CPU architecture. Intel processors have privilege rings (Ring 0 for the kernel, Ring 3 for user processes) that prevent unprivileged code from accessing protected resources. We applied the same concept to agents, but with a twist: Ring assignment is dynamic, based on behavioral trust scores.

Ring 0 (Privileged): Trust score ≥ 0.95. Can modify system policies. Reserved for human-verified orchestrators.
Ring 1 (Trusted): Trust score ≥ 0.80. Standard operations with full tool access.
Ring 2 (Standard): Trust score ≥ 0.60. Limited resource access, rate-limited.
Ring 3 (Sandbox): Trust score < 0.60. Heavily restricted. New or untrusted agents start here.

Each ring enforces resource limits: maximum execution time per step, memory caps, CPU throttling, and request rate limits. An agent in Ring 3 might be limited to 10 API calls per minute with a five-second execution timeout, while a Ring 0 agent has no such restrictions.

The runtime also provides saga orchestration for multi-step operations. When an agent executes a sequence of actions — draft an email, send it, update the CRM — and the final step fails, the saga engine automatically calls compensating actions in reverse order. The email gets recalled, the draft gets deleted. This pattern, borrowed from distributed transaction processing, prevents the partial-completion failures that plague agentic workflows.

Reliability engineering for agents

When we built the Agent SRE package, we started with a question: How do you define “reliable” for an AI agent? Traditional SRE metrics like uptime and latency matter, but agents introduce new dimensions. An agent might be fast and available but produce incorrect results. It might be accurate but cost $500 per hour in API calls. It might work perfectly in isolation but cause cascading failures when it interacts with other agents.

We defined seven Service Level Indicators (SLIs) specific to AI agents: correctness, safety, latency, cost, availability, throughput, and delegation success rate. Each SLI gets a threshold, and together they form an error budget — a quantified tolerance for failure.

Here’s where it gets interesting: The error budget drives automated remediation. When an agent’s safety SLI drops below 99 percent (meaning more than 1 percent of its actions violate policy), the system can automatically trigger a kill switch, downgrade the agent’s execution ring, or activate a circuit breaker that rejects new requests until the agent recovers.

We also built nine chaos engineering fault injection templates — network delays, LLM provider failures, tool timeouts, trust score manipulation, memory corruption, concurrent access races — because the only way to know if your agent system is resilient is to break it on purpose in controlled conditions.

Covering the OWASP Agentic AI Top 10

When OWASP published their Agentic AI Top 10, we mapped each risk to our toolkit’s capabilities and found that the architecture provides mitigations for all ten categories:

Goal hijacking is addressed by the policy engine’s semantic intent classifier.
Tool misuse is mitigated by capability sandboxing and the MCP proxy.
Identity abuse is addressed by DID-based identity and trust scoring.
Supply chain risks are tracked by AI-BOM v2.0, which records model provenance, dataset lineage, and weight versioning.
Code execution is constrained by execution rings and resource limits.
Memory poisoning is detected by the Cross-Model Verification Kernel, which runs claims through multiple LLMs and uses majority voting to identify manipulation.
Insecure communications are mitigated by the IATP protocol’s encryption layer.
Cascading failures are addressed by circuit breakers and SLO enforcement.
Human-agent trust exploitation is mitigated by approval workflows with quorum logic.
Rogue agents are addressed by ring isolation, behavioral trust decay, and the kill switch.

This alignment was by design, not by accident. The OS-inspired architecture creates defense in depth — multiple independent layers that each address different threat categories. No security system can guarantee absolute protection, but by layering complementary defenses, the toolkit significantly reduces the attack surface for autonomous AI agents.

The interoperability challenge

A governance toolkit is only useful if it works with the frameworks people actually use. We designed the toolkit to be framework-agnostic, with adapters that interoperate with LangChain, CrewAI, Google ADK, AutoGen, LlamaIndex, and others. Each adapter hooks into the framework’s native extension points — LangChain’s callback handlers, CrewAI’s task decorators, Google ADK’s plugin system — so that adding governance does not require rewriting existing agent code.

Several of these adapters are already working with production frameworks: Dify (65K+ GitHub stars) has the governance plugin in its marketplace, LlamaIndex (47K+ stars) has a TrustedAgentWorker, and proposals are active for AutoGen, CrewAI, Google ADK, and Haystack.

What we learned

Building this toolkit reinforced several lessons that apply beyond agent governance:

Borrow from solved problems. The OS kernel, service mesh, and SRE playbook all addressed security and reliability challenges in other domains. Translating those patterns to AI agents was more effective than inventing from scratch.

Make security the default, not an add-on. The reason we built governance into the execution path (intercepting actions) rather than as an optional wrapper is that optional security tends to go unadopted. If adding governance requires changing agent code, many teams will defer it. That said, no security layer is a silver bullet — defense in depth and ongoing monitoring remain essential.

Trust is dynamic, not static. A binary trusted/untrusted model doesn’t capture reality. Trust scoring with behavioral decay and ring-based privilege assignment turned out to be a much better model for systems where agents are constantly changing.

Statelessness enables everything. By making the kernel stateless, we got horizontal scaling, containerized deployment, and perfect auditability for free. Every decision we agonized over early in the architecture became easier once we committed to statelessness.

Getting started

The Agent Governance Toolkit is now open source under the MIT license at github.com/microsoft/agent-governance-toolkit. You can install it with a single command:

pip install ai-agent-compliance[full]

This installs all four packages — Agent OS, AgentMesh, Agent Runtime, and Agent SRE — with version compatibility guaranteed. Individual packages are also available for teams that want to adopt governance incrementally.

The toolkit runs at sub-millisecond governance latency (< 0.1ms p99), so it adds negligible overhead to agent execution. It exports metrics to OpenTelemetry-compatible platforms (Datadog, Prometheus, Grafana, Arize, Langfuse), and it works with Python 3.10+.

AI agents are becoming autonomous decision-makers in high-stakes domains — finance, healthcare, infrastructure, security. The question is not whether we need governance for these systems, but whether we will build it proactively, before incidents occur, or reactively, after them. We’ve chosen to be proactive. We hope you join us.

Imran Siddique is on LinkedIn.

The Agent Governance Toolkit is open source under the MIT license. Contributions welcome at github.com/microsoft/agent-governance-toolkit.

The author used AI-assisted tools during the drafting of this article. All technical content, code examples, and architectural descriptions reflect the actual capabilities of the Agent Governance Toolkit and have been reviewed for accuracy.