CaberActive Data Use Control for Agentic AI

These four problems share one cause. Whatever hands an agent its data, a retriever, a tool result, a cached record, or a pasted paragraph, hands it bytes. The bytes do not carry what the agent needs to know about them: whether they are current, where they came from, who may see them, what must travel with them to be read correctly, and what they may be used for. That context exists, but it lives in file systems, identity providers, audit logs, and version histories that the agent never sees.

Why has nobody fixed this? Three facts about enterprise data explain why controlling how AI uses data is hard, and why file level permissions and prompt only scanners fall short. For the underlying studies, definitions, and a worked example, see Data Quality Problems Affecting AI Agents.

How Caber Works ​

Caber finds relationships between identical chunks of content across documents, tool calls, and API payloads. Then it connects the context attached to every instance of the same content, so it knows what that content means and how it may be used.

Every copy of a sentence carries a piece of its context. The file it sits in has an owner and an ACL. The email it was pasted into has a recipient list and a timestamp. The API response it came back in has a caller and a tenant. Any single copy, on its own, can be a bare string with none of that. Joining the copies by their content joins their contexts, so when an agent retrieves one copy, Caber answers from all of them: which version is current, where it originated, who may see it, and what it may be used for.

This turns the three facts above from obstacles into the mechanism. Duplication supplies the copies, the copies supply the context, and the context supplies the answer that the text alone cannot. Because the match is on content rather than on file identity, it works the same way whether the chunk arrives in a document, a tool result, or an API payload, and it needs no labels in the data itself.

In practice this is six steps. The Architecture Overview covers each in detail.

1. Fingerprint content. Split each file, message, or API payload into fragments of about one sentence, and give each fragment a deterministic fingerprint. The same text gets the same fingerprint wherever it appears.
2. Link the copies. Group fragments with the same fingerprint across sources, formats, and systems so partial copies inside different documents share one identity.
3. Collect context from every copy. Attach each copy's source, owner, permissions, and timestamps, along with extracted entities and ontology labels, to the fragment in a context graph.
4. Resolve versions (beta). Arrange related documents into a version history built from their shared fragments so policies can identify superseded content.
5. Decide at inference time. When an agent or application retrieves data, run compiled Rego policies in process against the fragment's context, the end user the agent acts for, and the purpose of the request to release, mask, replace, or withhold the fragment.
6. Record the decision. Emit an audit receipt that records the fragment, the policy, the identity, and the declared purpose.

What Sets Caber Apart ​

Most products that govern AI data use sit at a chokepoint. A proxy inspects prompts and completions. A permission filter trims search results by document ACL. A classifier labels objects at rest. Each one sees a single surface and reasons about whole documents or whole requests. Caber's unit is the content fragment, and its question is what every copy of that fragment, across every surface, says about how it may be used. The architecture below follows from that choice.

Figure 1: Caber architecture. Three sources of context (instrumented callers, storage and event connectors, and identity connectors) feed one core, which decides in the caller's process and records relationships in a context graph.

• [1] Agents, services and tools with the pycaber SDK. The SDK loads into the caller's process at import time and needs no code changes. Because it sits inside the process rather than in front of it, it sees what a proxy cannot: tool results, retriever output, memory reads, and API payloads in both directions, not just the prompt and the completion. It decodes the credential on each hop (JWT, AWS SigV4, SPIFFE, mTLS) and carries the human the agent acts for across agent, MCP tool, and API boundaries in W3C trace context, so a request that has become a service account by hop two still evaluates as the person behind it. The decision comes back before the data reaches the model, and the SDK applies it in place.
• [2] Caber Core. The engine works on fragments rather than documents. The WRL chunker splits content into content defined fragments with a 40 byte floor and 100% byte coverage, so a sentence pasted from one object into another produces the same fragment in both and the two are linked without labels, embeddings, or file identity. Fragment lookups run against a Roaring bitmap index (.rbix) in sub millisecond time. The version resolver (beta) orders overlapping copies to find which is current and withholds the superseded ones. Policy is Rego compiled to WebAssembly and hosted in process, so a decision makes no network or database call. Decisions act at fragment granularity: release, mask, replace, or withhold the specific span, and every decision emits an audit receipt.
• [3] Storage and document connectors. These read objects in S3, GCS, Azure, SQL, and file systems and keep what the bytes alone lose: the ACL, the owner, the timestamps, the parsed structure, and the byte span of each fragment within its source. A storage classifier stops at a label per object. A connector supplies the context that makes a fragment answerable when it turns up somewhere else.
• [4] Log and event connectors. CloudTrail, SaaS audit logs, Kafka topics, and polled APIs are parsed into access events: which principal touched which copy of which object, and when. These events give the core the history behind every fragment, which is what makes provenance and freshness answerable after the fact rather than only at ingest.
• [5] Identity systems. Connectors resolve principals against OIDC and JWT issuers, Entra, Okta, SCIM, SigV4 and SPIFFE identities, and pull user and group attributes. The same resolution serves both sides of a decision: the owners and readers recorded on the data, and the human behind the request that arrives through the SDK.
• [6] Context graph. The context graph (supporting multiple graph databases, including Neo4j) stores the relationships the core discovers: fragments to copies, copies to objects, objects to principals, versions, and permissions. A RAG index holds an embedding per chunk and forgets where the chunk came from. The context graph holds how every chunk relates to every other, and the console's lineage explorer queries it directly to answer where a fragment has been, who has held it, and which version is current.

Zero-Code Integration ​

Taking inspiration from OpenTelemetry for zero-code integration, Caber instruments existing Python applications without code changes. Set the connection to your Caber deployment, then run your application under caber-run:

export CSI_API_KEY="your-api-key"
export CSI_CABER_HOST="https://your-caber-instance.example.com"

caber-run python app.py
caber-run uvicorn myapp:app --host 0.0.0.0

Or enable it in code, before any HTTP or agent framework library is imported:

import pycaber.auto  # must come before HTTP and agent framework imports

import requests
from langgraph.prebuilt import create_react_agent
# Tool calls, retrievals, and API responses are now captured and checked against policy

pycaber patches 15 transports, including requests, httpx, aiohttp, and urllib3; WSGI and ASGI servers; WebSocket clients; and gRPC clients and servers. It captures tool, retriever, and memory calls in LangChain, LangGraph, CrewAI, LlamaIndex, and AutoGen without changes to agent logic. For custom functions exposed to agents, the @pycaber.tool decorator attaches policy metadata. Policies are authored centrally in the Caber admin console and deployed into caber-core, not into application code.

Performance & Sizing ​

Measured SDK figures cover SDK overhead only, with on behalf of identity disabled. Stale call figures come from the version resolution accuracy model and await measurement on a production corpus. Design budgets are engineering goals, not measured results.

Ecosystem Integrations ​

Caber connects across your existing AI and infrastructure stacks:

* On near term roadmap.

Caber is self-hosted with Docker Compose, including a single-host trial mode. Internally, caber-core uses RocksDB with Roaring bitmaps for the fingerprint index, OpenSearch for events and content, and a graph database such as Neo4j for the context graph.

Quick Navigation ​

• Understand the Architecture: Read the System Architecture Guide.
• Connect Your Stack: Explore the Integrations Catalog.
• Build with Python: Dive into the PyCaber SDK Guide.
• Deploy the Backend: Run the caber-core Compose Guide.
• Inspect Traces: Launch the CaberUserConsole Guide.
• Run Hands-On Demos: Test agentgov-mimic and agentic-tools.
• Compare & Troubleshoot: Read the FAQ & Architectural Comparisons.