DEV Community: SidClaw

63% of orgs can't enforce what their AI agents are allowed to do

SidClaw — Wed, 15 Apr 2026 09:06:38 +0000

Kiteworks surveyed 225 security and IT leaders for their 2026 Data Security and Compliance Risk Forecast Report. Three numbers from it:

63% can't enforce purpose limitations on what their agents are authorized to do
60% can't terminate a misbehaving agent
33% lack evidence-quality audit trails entirely

And 51% of these organizations already have agents in production. So the gap isn't hypothetical. Agents are running without guardrails right now, in real environments, doing real things.

What "enforce purpose limitations" actually means

The Kiteworks phrasing is specific. It's not "we don't have a policy." It's "we have a policy and can't enforce it."

That distinction matters. Most teams have some document that says "the support bot should only access customer records relevant to the active ticket." But nothing between the LLM deciding to SELECT * FROM customers and the query executing. The policy exists on paper. The enforcement doesn't exist in code.

What enforcement looks like

Here's a LangChain agent with an email-sending tool. No governance:

import { DynamicStructuredTool } from "@langchain/core/tools";
import { z } from "zod";

const sendEmailTool = new DynamicStructuredTool({
  name: "send_email",
  description: "Send an email to a customer",
  schema: z.object({
    to: z.string().email(),
    subject: z.string(),
    body: z.string(),
  }),
  func: async ({ to, subject, body }) => {
    await emailService.send({ to, subject, body });
    return `Email sent to ${to}`;
  },
});

The agent decides to send an email. It sends. Nobody reviewed the recipient, the subject, or the body. If the LLM hallucinated the address or wrote something unhinged, it shipped.

Now with governTools():

import { governTools } from "@sidclaw/sdk/langchain";
import { SidClawClient } from "@sidclaw/sdk";

const sc = new SidClawClient({
  baseUrl: "https://app.sidclaw.com",
  apiKey: process.env.SIDCLAW_API_KEY,
  agentId: "support-bot",
});

const governedTools = governTools(sc, [sendEmailTool]);

Same tool. But now when the agent calls send_email, the action gets evaluated against a policy set before executing. If a policy says email-sending requires approval, the action holds. A reviewer sees the recipient, subject, body, and the agent's reasoning. They approve or deny. The agent resumes or stops.

That's the enforcement the Kiteworks 63% is missing. Not the policy. The runtime check that the policy is actually followed.

What the policy engine does per tool call

Three things:

Evaluates the action against priority-ordered policies. First match wins. Outcomes: allow, deny, flag (hold for approval), or log (allow but trace).
If flagged, creates an approval request with the agent's identity, action name, input payload, reasoning, risk classification, and which policy triggered the hold.
Records a trace event hash-chained to the previous event. Tampering with any record breaks the chain. That's the audit trail the other 33% from the Kiteworks report don't have.

What this doesn't solve

SidClaw governs actions. It doesn't filter LLM outputs for toxicity, check prompt injections, or validate that the agent's reasoning is sound. Those are different problems with different tools (Pangea, Lakera, etc.). This sits at the tool-call layer: the moment the agent decides to do something in the real world.

It also doesn't help if the 60% who can't kill a misbehaving agent don't have a policy that denies the misbehavior in the first place. You still need to define what's allowed and what isn't. The policy engine enforces. It doesn't write your policies for you.

Kiteworks report: kiteworks.com
Docs: docs.sidclaw.com
TypeScript SDK: npm install @sidclaw/sdk
Python SDK: pip install sidclaw

Three agent frameworks, same missing piece

SidClaw — Tue, 14 Apr 2026 21:41:49 +0000

In the last 30 days, three separate agent frameworks received nearly identical feature requests from their communities. Different repos, different maintainers, different architectures. Same ask.

The issues

LangChain #35393 — "Agent Identity Verification"

Opened mid-April 2026. The thread (15+ comments and growing) asks for a way to verify agent identity before tool execution. Not after. Not in logs. Before the tool call happens.

OpenAI Agents SDK #2775 — governance collaboration

imran-siddique opened this requesting a governance integration layer for the Agents SDK. The goal: define policies that run before an agent acts, not after it's already sent the email or deleted the row.

CrewAI #4596 — "Fail closed without pre-execution checks"

Three comments. The request is direct: if a policy engine can't evaluate a tool call, block it. Don't default to allowing it. Fail closed, not fail open.

What they have in common

Strip away the framework-specific language and all three issues describe the same architecture:

Agent decides to call a tool
Something checks whether that call should proceed
If the check says no (or can't decide), the call doesn't happen
Every decision gets logged

That's it. Pre-execution evaluation with a default-deny posture.

The reason this keeps coming up independently is that every team building production agents hits the same wall. The agent works. It works too well. It sends emails nobody reviewed. It runs database queries nobody approved. It calls external APIs with real money attached.

The observability layer (logging, tracing, monitoring) tells you what happened. It doesn't prevent anything.

Why this is technically hard

Each framework handles tool calls differently.

LangChain wraps tools as BaseTool instances with a _run method. Intercepting means wrapping that method or using the callback system (which fires after invocation, not before, in most configurations).

OpenAI's Agents SDK uses function definitions passed to the completions API. The tool call comes back in the API response. Intercepting means catching the response before the function executes — a different hook point than LangChain.

CrewAI has its own task/tool abstraction with @tool decorators. Intercepting means wrapping the decorated function or patching the task execution pipeline.

Three frameworks, three interception points, three sets of lifecycle hooks. A governance layer that works across all of them needs to abstract over these differences without breaking the framework-specific semantics.

What's actually different between the requests

Despite the shared pattern, each community emphasizes different aspects:

LangChain's thread focuses on identity. Who is this agent? Can we verify its identity before trusting its tool calls? The concern is authentication, not just authorization.
OpenAI's issue frames it as collaboration between governance systems and the SDK. The language is about integration points and extensibility.
CrewAI's request is the most operational. Fail closed. If you can't check, don't proceed. This is classic security engineering applied to agent behavior.

Identity. Integration. Fail-closed defaults. Three angles on the same problem.

What this tells us

When three independent communities ask for the same thing within a month of each other, that's a market signal. Production agent deployments are hitting governance requirements that the frameworks weren't designed to handle.

The frameworks were built for capability: make the agent smarter, give it more tools, let it reason better. Governance was someone else's problem.

Now it's everyone's problem. And the teams filing these issues are the ones deploying agents into environments where "the agent decided it was fine" isn't an acceptable answer for why the production database got modified.

No framework has shipped a complete answer yet. The issues are open, the discussions are active, and the architecture is still being figured out. But the convergence is real. Pre-execution governance for agent tool calls isn't a niche concern anymore. It's the feature request.

How to add human approval to MCP tool calls — no code changes

SidClaw — Fri, 10 Apr 2026 21:47:49 +0000

MCP servers do what agents tell them. There's no policy check between "the agent decided to run this query" and "the query executed." If you're running MCP servers in production, every tool call goes straight through.

We built sidclaw-mcp-guard to fix that. It's a CLI that wraps any MCP server with policy-based guardrails. YAML rules, local approval dashboard, audit trail. No signup, no SaaS dependency. Apache 2.0.

Here's what it looks like.

30-second demo

npx sidclaw-mcp-guard@latest demo

Output:

ALLOW   SELECT * FROM users
  Allowed: read query on users. Read-only queries are safe.

HOLD    DELETE FROM users WHERE id = 42
  Held for approval: delete from users. Data changes need approval.

BLOCK   DROP TABLE users
  Blocked: drop users. Schema changes are never allowed.

Three decisions. Safe reads pass through. Writes wait for a human. Destructive DDL gets blocked outright.

It catches compound statements too. SELECT 1; DROP TABLE users doesn't sneak through as a read -- the destructive part gets flagged.

How it works

mcp-guard is a proxy. It sits between your MCP client (Claude Desktop, Cursor, VS Code, whatever) and the upstream MCP server. Every tools/call request passes through the guard first.

MCP Client  -->  sidclaw-mcp-guard  -->  MCP Server (postgres, filesystem, etc.)
                      |
                 policy.yaml
                      |
                 localhost:9091 (approval dashboard)

The guard reads your policies, classifies the tool call using semantic patterns, and decides: allow, hold for approval, or deny.

Setting it up

npx sidclaw-mcp-guard@latest quickstart

This creates a policy.yaml, writes .mcp.json for your client, and starts the approval dashboard at localhost:9091.

To run it manually against any MCP server:

npx sidclaw-mcp-guard --upstream "npx -y @modelcontextprotocol/server-postgres postgresql://localhost/mydb" --ui

Policy rules

Policies are YAML. Each rule matches a semantic pattern and decides what happens.

rules:
  - name: allow-reads
    description: Read-only queries are safe
    match:
      pattern: sql-read
    action: allow

  - name: approve-writes
    description: Data changes need human review
    match:
      pattern: sql-write
    action: approve

  - name: deny-destructive
    description: Schema changes are never allowed
    match:
      pattern: sql-destructive
    action: deny

default: deny

The patterns aren't regex. sql-read matches SELECT, EXPLAIN, SHOW. sql-write matches INSERT, UPDATE, DELETE. sql-destructive catches DROP, TRUNCATE, ALTER, CREATE. The guard parses the intent, not just the string.

Shell commands too

Works for filesystem and shell MCP servers, not just databases.

shell-safe -- ls, cat, echo
shell-risky -- curl, wget, ssh
shell-destructive -- rm -rf, chmod 777, dd

Same pattern. Same YAML. You can mix SQL and shell rules in one policy file if your agent connects to multiple MCP servers.

The audit trail

Every decision gets logged to .sidclaw/audit.jsonl:

{"timestamp":"...","tool":"query","args":{"sql":"SELECT * FROM users"},"decision":"allow","rule":"allow-reads"}
{"timestamp":"...","tool":"query","args":{"sql":"DELETE FROM users WHERE id=42"},"decision":"approve","rule":"approve-writes","status":"approved"}
{"timestamp":"...","tool":"query","args":{"sql":"DROP TABLE users"},"decision":"deny","rule":"deny-destructive"}

Every tool call, every decision, every approval. JSONL so you can grep it, pipe it, or ship it to whatever log aggregator you already use.

What this doesn't solve

mcp-guard governs tool calls. It doesn't filter LLM outputs, detect prompt injection, or validate agent reasoning. Those are different problems -- Pangea and Lakera handle the input/output layer. This sits at the action layer: the moment the agent decides to do something through an MCP server.

It also doesn't replace proper database permissions. If your postgres user has DROP access and you don't want agents dropping tables, fix the permissions too. mcp-guard is a second layer, not a replacement for the first.

Repo: github.com/sidclawhq/mcp-guard
npm: sidclaw-mcp-guard v0.1.2
License: Apache 2.0
Demo: npx sidclaw-mcp-guard@latest demo

What is an MCP proxy and why does it need an approval layer?

SidClaw — Sat, 04 Apr 2026 21:21:05 +0000

MCP (Model Context Protocol) lets AI agents call external tools. A database query, a file write, an API call -- the agent decides what to do and the MCP server executes it. But there's nothing in the spec that evaluates whether that action should happen.

An MCP proxy sits between the agent and the MCP server. It intercepts every tools/call request, does something with it, and forwards it (or doesn't). The proxy pattern isn't new -- it's how HTTP proxies, API gateways, and service meshes work. Apply it to MCP and you get an enforcement point for agent actions.

Why a plain proxy isn't enough

Most MCP proxies today do routing, load balancing, or observability. They watch traffic. Some log it. A few do rate limiting.

None of that stops an agent from running DROP TABLE customers if the tool call is well-formed and the agent has access.

30 CVEs have been filed against MCP servers in the last 60 days. 38% of those servers had no authentication at all. The attack surface is real. But even with auth in place, the question remains: should this specific tool call, with this specific payload, execute right now? Or should a human look at it first?

That's what an approval layer adds.

What an approval layer actually does

An MCP proxy with an approval layer intercepts tools/call before it reaches the upstream server and does three things:

Evaluates the action against a policy. Not a binary allow/deny on the tool name -- a policy that considers the action type, the payload content, the agent's identity, and the risk classification. A SELECT is different from a DELETE. Reading a public file is different from reading /etc/passwd.
Routes high-risk actions to a human reviewer. The reviewer sees the full context: what the agent wants to do, what it's sending, which policy flagged it, and (if the framework provides it) the agent's reasoning. They approve or deny. The action only proceeds after the decision.
Records everything in an audit trail. Not just "tool was called." The full chain: policy was evaluated, action was flagged, reviewer was notified, reviewer saw context X, reviewer approved at timestamp Y, action executed at timestamp Z. For regulated industries (FINRA 2026, EU AI Act), this chain is what auditors ask for.

The gap in the current ecosystem

Here's what's already shipping for MCP governance:

Routing/gateway proxies (Gravitee, Cloudflare) handle traffic management and basic auth
Discovery/posture tools (Cisco DefenseClaw) scan MCP servers for vulnerabilities
Framework-native flags (OpenAI's needsApproval) work within a single SDK

What's missing: a proxy that sits in front of any MCP server, evaluates each tool call against a real policy engine, and holds high-risk actions for human review with full context. That's the approval layer.

Who's building this

A few teams are working on MCP governance proxies with approval capabilities:

SidClaw (what we built) wraps any stdio MCP server with policy evaluation, human approval workflows, and hash-chain audit trails. 18+ framework integrations. Apache 2.0 SDK.
Faramesh Labs published an Action Authorization Boundary with a custom policy language. 13 integrations. Open-core.
OpenBox AI ships runtime governance with cryptographic attestation. $5M seed.
hoop.dev routes infrastructure commands through Slack/Teams for approval. Focused on database and SSH, not general-purpose MCP.

The category is forming fast. A year ago nobody was building MCP governance. Now there are arxiv papers, seed rounds, and multiple open-source implementations.

When you need this

If your agents only read data and the stakes are low, a proxy without an approval layer is fine. Log the calls, monitor for anomalies, move on.

But if your agents can send emails, modify production databases, call payment APIs, or take any action that isn't trivially reversible -- you need something that evaluates the action before it happens. Not after. The audit trail is for proving what happened. The approval layer is for controlling what happens.

SidClaw docs: docs.sidclaw.com
MCP spec: modelcontextprotocol.io

88% of orgs had AI agent incidents. 82% of execs think they're protected. here's the gap.

SidClaw — Sat, 04 Apr 2026 04:21:48 +0000

Gravitee surveyed 900+ executives and technical practitioners for their State of AI Agent Security 2026 report. Two numbers from it that don't make sense together:

88% of organizations reported confirmed or suspected AI agent security incidents in the last year
82% of executives feel confident their existing policies protect against unauthorized agent actions

Both numbers are real. Both are from the same report. And they describe the same organizations.

So what's going on?

The governance stack has a missing layer

The report also found that 80.9% of technical teams have moved past planning into active testing or production. But only 14.4% deployed with full security/IT sign-off. That means the majority of agents running in production right now were deployed without the security team approving them.

RSAC 2026 (March 23-27, San Francisco) made this painfully visible. Every major vendor announced agentic AI governance features:

Cisco open-sourced DefenseClaw -- scans MCP servers, inventories agent skills, maps agents to owners
Microsoft's Agent Governance Toolkit hit 354 stars, covers all 10 OWASP Agentic risks
AWS shipped Bedrock AgentCore Policy to GA across 13 regions
ServiceNow announced AI Control Tower for agent monitoring
CrowdStrike, Palo Alto, BeyondTrust, Wiz all announced agent-focused features

Notice the pattern? Discovery, posture management, scanning, monitoring, identity. All important. All pre-execution or post-execution.

None of them ship the approval primitive.

What the approval primitive actually means

An approval primitive is a runtime enforcement point that intercepts an agent's tool call before it executes, evaluates it against a policy, and either allows it, denies it, or holds it for human review.

Not "log it and alert later." Not "scan it before deployment." Not "monitor for anomalies after the fact."

The action is literally paused. A human sees the exact payload -- the SQL query, the API request body, the email draft -- and makes a decision. Then the action proceeds or doesn't.

That's the layer the Gravitee numbers are screaming about. 82% of executives think their policies protect them because policies exist on paper. But 88% had incidents because nothing enforced those policies at the moment an agent decided to act.

Why this gap exists

Discovery and posture management are easier problems. You scan an environment, enumerate agents, classify risk. It's a batch job. You can ship it as a dashboard.

Runtime approval is harder because it sits in the hot path. Every tool call hits it. Latency matters. You need:

A policy engine that evaluates in milliseconds
An approval workflow that doesn't block the agent forever
Integration with the agent framework (LangChain, CrewAI, MCP, etc.) at the tool-call level
An audit trail that's tamper-evident, not just append-only logs

This is infrastructure, not a feature. And infrastructure takes longer to build than scanners.

The competitive landscape is forming fast

A few teams are working on this specific layer:

Faramesh Labs published an arxiv paper on their Action Authorization Boundary -- deterministic enforcement with a custom policy language (FPL). 13 framework integrations. Open-core. 30 GitHub stars. Early but serious.
OpenBox AI launched on Product Hunt with $5M seed from Tykhe Ventures. Runtime governance with cryptographic attestation. SDK for LangChain, LangGraph, Temporal, n8n.
HumanLayer (YC F24) had the @require_approval primitive but pivoted to CodeLayer. The original SDK hasn't been updated since June 2025.
SidClaw (us) ships the approval workflow with a policy engine, compliance mapping to FINRA 2026 and EU AI Act, and hash-chain audit trails. 18+ framework integrations. Apache 2.0 SDK.

There are others (hoop.dev for Slack-routed infra approvals, AgentBouncr for lightweight policy enforcement, Barndoor AI for MCP-specific governance). The category is real and growing.

What the numbers predict

Gravitee's report also found that 25.5% of deployed agents can create and task other agents. Agent-to-agent delegation without approval checkpoints is where the 88% incident number is going to get worse.

The EU AI Act enforcement starts August 2026. FINRA's 2026 oversight report explicitly requires "explicit human checkpoints before execution" for agents that can act or transact. Regulatory pressure is real and has deadlines.

If your agents are in production without an approval layer, the question isn't whether you'll have an incident. According to the data, you probably already have.

Gravitee report: gravitee.io/state-of-ai-agent-security
SidClaw docs: docs.sidclaw.com
Faramesh: faramesh.dev
OpenBox: openbox.ai

Governing MCP tool calls in Claude Code -- before/after in 3 minutes

SidClaw — Thu, 02 Apr 2026 06:22:47 +0000

30 CVEs filed against MCP servers in 60 days. 38% have no authentication. And every MCP server your Claude Code session connects to is ungoverned -- tool calls go straight from the LLM to the server with no policy check, no approval step, no audit trail.

We built a proxy that sits between Claude Code and any upstream MCP server. It evaluates every tool call against your policies before forwarding. Here's the before and after.

Before: ungoverned MCP server

Your .mcp.json points Claude Code directly at the MCP PostgreSQL server:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost/mydb"]
    }
  }
}

Claude Code asks to run DROP TABLE customers. The MCP server executes it. Done. No one reviewed it, no one approved it, no record beyond whatever postgres logs you happen to have.

After: governed with sidclaw-mcp-proxy

{
  "mcpServers": {
    "postgres-governed": {
      "command": "npx",
      "args": ["-y", "@sidclaw/sdk", "sidclaw-mcp-proxy",
               "--transport", "stdio"],
      "env": {
        "SIDCLAW_API_KEY": "ai_your_key_here",
        "SIDCLAW_AGENT_ID": "claude-code-db-agent",
        "SIDCLAW_UPSTREAM_CMD": "npx",
        "SIDCLAW_UPSTREAM_ARGS": "-y,@modelcontextprotocol/server-postgres,postgresql://localhost/mydb"
      }
    }
  }
}

Same MCP server underneath. But now every tools/call request passes through SidClaw's policy engine first.

Three scenarios

SELECT (allowed): Claude Code runs SELECT * FROM customers. Policy matches "allow read queries." Passes through, ~50ms overhead. You don't notice.

DELETE (flagged): Claude Code runs DELETE FROM customers WHERE name = 'Eve Davis'. Policy matches "require approval for writes." The proxy returns an MCP error (-32001) with "Approval required" and a link. A reviewer gets a Slack notification (or Teams, email, dashboard -- 16 channels). They see the exact query, the agent ID, which policy triggered it. Approve or deny. Tell Claude Code to retry.

DROP (denied): Claude Code runs DROP TABLE customers. Policy matches "block destructive DDL." Denied outright. Claude Code gets an error saying the operation was blocked by policy. No retry.

How the approval flow actually works

The proxy uses error mode by default. When a tool call needs approval, it returns immediately with an MCP error. Claude Code shows you the error. You go approve (or deny) in the dashboard or Slack. Then you tell Claude Code "try again" and the second call succeeds.

We don't use block mode (which polls for 30 seconds waiting for a decision) because it'll freeze Claude Code. Error-then-retry is the right pattern here.

Claude Code
    |
    v
sidclaw-mcp-proxy  (evaluates policy, ~50ms)
    |
    v
MCP PostgreSQL Server
    |
    v
PostgreSQL

What this wraps

Any MCP server that uses stdio transport. We've tested with:

@modelcontextprotocol/server-postgres (the example above)
@modelcontextprotocol/server-filesystem (flag writes, allow reads)
@modelcontextprotocol/server-github (flag PR merges, allow reads)

The tool mappings are configurable per-tool via SIDCLAW_TOOL_MAPPINGS. You can set data classification, skip governance on safe operations, and map tool names to policy operations using glob patterns (db_*, *_read).

What this doesn't do

It doesn't filter LLM outputs. It doesn't detect prompt injection. It doesn't validate that Claude Code's reasoning is correct. Those are different problems -- Pangea, Lakera, and others handle the input/output layer. SidClaw sits at the action layer: the moment the agent decides to do something in the real world.

It also doesn't help if you're using Streamable HTTP transport with Claude Code. Right now this is stdio only, which is what Claude Code uses for local MCP servers.

Try it

The examples/claude-code-governed/ directory in the repo has a working docker-compose setup. PostgreSQL with sample data, three pre-configured policies, and the .mcp.json ready to copy. docker compose up and you're testing in 2 minutes.

Docs: docs.sidclaw.com/docs/integrations/claude-code
Repo: github.com/sidclawhq/platform
SDK: npm install @sidclaw/sdk (v0.1.5, Apache 2.0)

Adding human approval to LangChain tool calls in 12 lines of TypeScript

SidClaw — Wed, 01 Apr 2026 05:59:57 +0000

Last week we needed to add approval gates to a LangChain agent that sends customer emails. The agent worked fine. The problem was it worked too fine, and nobody reviewed what it was sending.

Here’s the before-and-after.

Before: ungoverned tool call

import { DynamicStructuredTool } from "@langchain/core/tools";
import { z } from "zod";

const sendEmailTool = new DynamicStructuredTool({
  name: "send_email",
  description: "Send an email to a customer",
  schema: z.object({
    to: z.string().email(),
    subject: z.string(),
    body: z.string(),
  }),
  func: async ({ to, subject, body }) => {
    await emailService.send({ to, subject, body });
    return `Email sent to ${to}`;
  },
});

That tool does what the LLM tells it. No questions asked. If the agent hallucinates a recipient or drafts something unhinged, it ships.

After: governed tool call with SidClaw

import { governTools } from "@sidclaw/sdk/langchain";
import { SidClawClient } from "@sidclaw/sdk";

const sc = new SidClawClient({
  baseUrl: "https://app.sidclaw.com",
  apiKey: process.env.SIDCLAW_API_KEY,
  agentId: "support-bot",
});

const governedTools = governTools(sc, [sendEmailTool]);
// Use governedTools instead of [sendEmailTool] in your agent

That’s it. governTools() wraps each tool. When the agent calls send_email, SidClaw evaluates it against your policies. If a policy says “email-sending requires approval,” the action holds. A reviewer gets a card showing the recipient, subject, body, and the agent’s reasoning. They approve or deny. The agent resumes or stops.

What’s actually happening under the hood

governTools() does three things per tool call:

Evaluates the action against your policy set. Policies are priority-ordered. The first matching policy wins. Possible outcomes: allow, deny, flag (hold for approval), or log (allow but trace).
If flagged, creates an approval request with full context: agent identity, action name, input payload, the agent’s reasoning (if available from the framework), risk classification, and which policy triggered the flag.
Records a trace event with a hash-chain link to the previous event. Every action, approval, and denial is cryptographically chained. Tampering with any record breaks the chain.

Setting up policies

The CLI handles initial setup:

npx create-sidclaw-app
# Creates agent, default policies, and API key in ~60 seconds

Default policies block destructive database operations and flag high-risk actions like sending emails or modifying production infrastructure. You customize from there.

Why not just use LangChain callbacks?

Fair question. You could write a callback that intercepts tool calls and does... something. But:

Callbacks don’t have a built-in approval workflow. You’d need to build the “hold execution, notify a human, wait for response, resume” flow yourself.
Callbacks don’t produce compliance-grade audit trails. If FINRA asks for documented human checkpoints, a console.log isn’t going to cut it.
Callbacks are LangChain-specific. If you also use the Vercel AI SDK or MCP servers, you’re writing the same interception logic three times.

SidClaw’s governTools() works across 13 frameworks with the same governance protocol underneath. Switch from LangChain to CrewAI and your policies, approval workflows, and audit trail carry over.

What this doesn’t solve

SidClaw governs actions. It doesn’t filter LLM outputs for toxicity, check prompt injections, or validate that the agent’s reasoning is sound. Those are different problems with different tools (Pangea, Lakera, etc.). SidClaw sits at the tool-call layer: the moment the agent decides to do something in the real world.

Docs: https://docs.sidclaw.com
TypeScript SDK: npm install @sidclaw/sdk (v0.1.5)
Python SDK: pip install sidclaw (v0.1.2)

Introducing SidClaw: The Missing Approval Layer for AI Agents

SidClaw — Wed, 25 Mar 2026 22:13:05 +0000

Your AI agents can send emails, execute trades, scale infrastructure, and order lab tests. But who approved that? Who saw what the agent was about to do before it did it? Who has the audit trail?

Today we're launching SidClaw — an open-source governance platform that adds the missing approval step to AI agent workflows.

The problem nobody else is solving

The AI agent governance space is heating up. Okta is working on identity for agents. SailPoint has machine identity. WorkOS ships authorization primitives. They all handle the same three things: identity, policy, and audit.

But none of them ship the approval step — the part where a human sees rich context about what an agent wants to do, reviews the risk level, sees the agent's reasoning, and makes an informed decision before the action executes.

That approval step is exactly what regulators are asking for:

FINRA's 2026 Regulatory Oversight Report explicitly calls for "human in the loop" agent oversight and "explicit human checkpoints before execution" for AI agents that act or transact.
The EU AI Act (enforceable August 2, 2026) requires human oversight, automatic logging, and risk management for high-risk AI systems. Penalties reach up to €35 million or 7% of global annual turnover.

We saw that the gap is obvious and that the tooling to fill it didn't exist.

How SidClaw works

Four primitives govern every agent action:

Agent wants to act → SidClaw evaluates → Policy decides → Human approves (if needed) → Action executes → Trace recorded

Identity — Every agent is registered with an owner and scoped permissions
Policy — Every action is evaluated against explicit rules (allow / approval_required / deny)
Approval — High-risk actions surface a context-rich card to a human reviewer: what the agent wants to do, why it was flagged, the agent's reasoning, and the risk level. One-click approve or deny.
Trace — Every decision creates a tamper-proof audit trail with hash-chain integrity

The SDK wraps your existing tools. No changes to your agent logic:

import { AgentIdentityClient, withGovernance } from '@sidclaw/sdk';

const client = new AgentIdentityClient({
  apiKey: process.env.SIDCLAW_API_KEY,
  apiUrl: 'https://api.sidclaw.com',
  agentId: 'your-agent-id',
});

// Wrap any async function with governance
const sendEmail = withGovernance(client, {
  operation: 'send_email',
  data_classification: 'confidential',
}, async (to, subject, body) => {
  await emailService.send({ to, subject, body });
});

// Now this call is governed:
// - Policy says "allow"? Executes immediately.
// - Policy says "approval_required"? Waits for human approval.
// - Policy says "deny"? Throws ActionDeniedError. No email sent.
await sendEmail('customer@example.com', 'Follow-up', 'Hello...');

Or in Python:

from sidclaw import SidClaw
from sidclaw.middleware.generic import with_governance, GovernanceConfig

client = SidClaw(api_key="ai_...", agent_id="your-agent-id")

@with_governance(client, GovernanceConfig(
    operation="send_email",
    data_classification="confidential",
))
def send_email(to, subject, body):
    email_service.send(to=to, subject=subject, body=body)

13 framework integrations

SidClaw wraps whatever you're already using:

LangChain / LangGraph — governTools() wraps tool arrays
OpenAI Agents SDK — governOpenAITool() wraps function tools
Vercel AI SDK — governVercelTools() wraps tool objects
CrewAI — governCrewAITool() wraps task tools
Pydantic AI — governance_dependency() for tool functions
MCP — GovernanceMCPServer proxy wraps any MCP server
Composio, Claude Agent SDK, Google ADK, LlamaIndex — built-in support
Slack & Telegram — approve/deny directly from chat
GitHub Actions — governance checks in CI pipelines

Both TypeScript (npm) and Python (PyPI).

Try it right now

The fastest way — 60 seconds:

npx create-sidclaw-app my-agent
cd my-agent
npm start

This creates a working governed agent with 3 demo tools:

search_docs — allowed instantly
send_email — requires your approval
export_data — blocked by policy

Or try our live demos without installing anything:

Atlas Financial — AI customer support with email approval (FINRA)
Nexus DevOps — Infrastructure scaling with deployment approval
MedAssist Health — Clinical AI with physician approval (HIPAA)

Each demo uses real SidClaw governance. The policy evaluation, approval workflow, and audit traces are 100% authentic.

The backstory: built in one session

Here's the part that might interest the AI/dev community: the entire SidClaw platform — API, dashboard, documentation site, landing page, three vertical demos, TypeScript SDK, Python SDK, 13 integrations, 705 tests, production deployment — was built with tenant isolation, hash-chain audit trails, RBAC, Stripe billing, and one-click deploy. We went from market research to live production fast!

What's next

SidClaw is free during early access. The Apache 2.0 SDK is open-source forever. The platform has visible pricing (Free / Starter CHF 199/mo / Business CHF 999/mo / Enterprise) but everything is free right now.

We're looking for design partners — especially teams in financial services, healthcare, and platform engineering who are deploying AI agents and need governance before the August 2026 EU AI Act deadline.

Links:

Website: sidclaw.com
Documentation: docs.sidclaw.com
GitHub: github.com/sidclawhq/platform
SDK (npm): @sidclaw/sdk
SDK (PyPI): sidclaw
Live demo: demo.sidclaw.com

We'd love your feedback. Try a demo. Star the repo. Tell us what's missing.