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

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:

1. Evaluates the action against priority-ordered policies. First match wins. Outcomes: allow, deny, flag (hold for approval), or log (allow but trace).
2. If flagged, creates an approval request with the agent's identity, action name, input payload, reasoning, risk classification, and which policy triggered the hold.
3. 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

Comments

[Max Quimby]

The governance gap you've identified resonates with what I see when helping teams productionize agent workflows. Most organizations treat agent policy as a prompt-engineering problem ("just tell the agent what it can't do") when it's actually an infrastructure problem.

What's interesting is that enforcement needs to work at multiple levels simultaneously: (1) at the tool-use level, preventing specific tool calls before they execute, (2) at the orchestration level, validating that the overall plan hasn't drifted from intended scope, and (3) at the data layer, ensuring outputs don't inadvertently expose sensitive information. Most teams only think about layer 1 and miss 2 and 3 entirely.

We've found that treating agent boundaries as first-class infrastructure — similar to how you'd think about network policies or IAM roles — produces far more reliable results than policy-as-prompt. The mental model shift is from "constrain the model" to "constrain the environment the model operates in."

Curious: does the Kiteworks data break down which types of agents (RAG, tool-use, autonomous planners) have the worst policy adherence gaps? I'd expect autonomous planners to be the hardest to constrain.

[SidClaw]

Spot on with the infrastructure framing. The "just tell the agent what it can't do" approach breaks the moment you have two agents with different trust levels calling the same tool. Prompt-level policy doesn't compose.

Your multi-level breakdown maps to what we've been building. SidClaw currently operates at level 1 — intercepting tool calls before execution, evaluating them against YAML policies. It's where the most immediate damage happens, so that's where we started. But orchestration-level governance is where this gets genuinely hard. A policy that says "don't send emails" is straightforward. A policy that says "don't execute step 4 if step 2 returned PII" requires state across the whole workflow. Different failure modes entirely.

We don't have a good answer for level 2 yet. If you've seen patterns that work in your client engagements, genuinely curious what the enforcement mechanism looks like at the orchestrator layer.