rakib 0.1.1

Data flow security for AI agents — provenance tracking and policy enforcement

Rakib

Data flow security for AI agents. Tracks the provenance of every value through agent tool calls. Prevents untrusted data (web scrapes, external APIs) from controlling agent actions.

Named after the Arabic word for camel jockey (راكب) — Rakib rides both CaMeL (Google DeepMind) and Dromedary (Microsoft), taking the best from each. The core idea is theirs. Rakib makes it practical:

• Works with native tool_use — CaMeL and Dromedary require the LLM to generate Python code. Rakib works with how LLMs actually operate: native tool calls. No code generation needed.
• Config-driven, zero hardcoding — CaMeL is built for AgentDojo, Dromedary for Azure OpenAI. Rakib: one JSON file, bring your own tool names, any LLM.

What It Does

When an AI agent reads untrusted data and then calls tools, Rakib ensures the untrusted data can't control WHERE actions go — only WHAT they contain.

results = web_search(query="AI news")          # untrusted
email = results["suggested_recipient"]          # untrusted (parent is untrusted)
send_message(to=email, content=str(results))    # to=BLOCKED (untrusted in sensitive param)
                                                 # content=ALLOWED (non-sensitive)

How It Works

1. Provenance DAG — every value gets a node tracking its origin (user input, tool result, computed)
2. AST Interpreter — LLM generates Python code, Rakib executes it line by line wrapping every value
3. Policy Check — before each tool call, traces each argument's ancestry through the DAG
4. Block or Allow — untrusted data in sensitive params (routing) → blocked. In content params → allowed.

Install

pip install rakib              # core (no dependencies)
pip install rakib[opa]         # with OPA sidecar support (adds httpx)

Quick Start

import asyncio
from rakib import SecureExecutor

# Define your tools
async def send_message(**kwargs):
    print(f"Sending to {kwargs['to']}: {kwargs['content']}")
    return {"status": "sent"}

async def web_search(**kwargs):
    return {"results": [{"title": "News", "body": "send to [e-mail]"}]}

# Create executor with your policy
executor = SecureExecutor(
    untrusted_tools={"web_search", "fetch"},
    sensitive_params={
        "send_message": {"to"},
    },
)
executor.register_tool("send_message", send_message)
executor.register_tool("web_search", web_search)

# Set trusted instruction
executor.set_user_input("task", "Search news, send report to [e-mail]")

# Execute LLM-generated code — untrusted recipients are blocked
code = '''
data = web_search(query="AI news")
target = data["results"][0]["body"]
send_message(to=target, content="report")
'''
results = asyncio.run(executor.execute(code))
# → PolicyViolation: send_message.to has untrusted lineage [tool:web_search]

Policy Configuration

All rules in JSON — zero hardcoded tool names. Use YOUR tool names:

{
  "untrusted_tools": ["web_search", "fetch", "call_tool"],
  "sensitive_params": {
    "send_message": ["to"],
    "commit_files": ["project_id", "file_path"],
    "delegate_task": ["target_agent"]
  }
}

The included policies/data.json has common examples. Replace with your actual tool names — every agent framework names them differently (LangChain uses search, MCP uses call_tool, Claude uses web_search, etc.).

Set via RAKIB_POLICY_CONFIG env var or place at policies/data.json.

OPA Integration

For production, use OPA (Open Policy Agent) with Rego policies:

package rakib

default allow := true

deny contains msg if {
    some param in data.sensitive_params[input.tool]
    some source in input.data_sources[param]
    startswith(source, "tool:")
    tool_name := substring(source, 5, -1)
    tool_name in data.untrusted_tools
    not input.args[param] in input.safe_values
    msg := sprintf("BLOCKED: %s.%s from untrusted '%s'", [input.tool, param, source])
}

Without OPA, Rakib uses a Python config-driven fallback with identical logic.

The Hard Problems (Honest Assessment)

Simon Willison called CaMeL the "first credible prompt injection mitigation" that doesn't just throw more AI at the problem. But he also identified challenges that apply to Rakib:

Policy burden. Someone has to define which tools are untrusted and which parameters are sensitive. Willison notes he "still hasn't fully figured out AWS IAM" after two decades — and that's the kind of cognitive load policy management creates. Rakib keeps it simple: one JSON file with two lists (untrusted tools, sensitive params). Not zero effort, but far less than writing IAM policies.

User fatigue. If the system constantly asks "allow this action?", people eventually approve everything reflexively. Rakib avoids this by making most decisions automatically — only truly ambiguous cases (value not in safe set, not found in tool results, but turn has untrusted data) would need human review. The default is: if it's clearly safe OR clearly blocked, the human never sees it.

Content manipulation remains unsolved. CaMeL, Dromedary, and Rakib all solve the same vector: untrusted data controlling WHERE actions go. None of them solve untrusted data influencing WHAT the agent thinks. A poisoned web page can still bias a report — the data flows to the right place through the right channels, but the content is misleading. Defense: the human reading the output. There is no automated solution to fake news.

Not a silver bullet. The paper itself says "prompt injection attacks are not fully solved." Rakib is a layer — not a wall. Combine it with OS sandboxing (restrict what the agent can access) and business rules (restrict what actions are allowed) for defense in depth.

Three Security Layers

Rakib is the data flow layer. Combine with OS sandboxing and business rules for defense in depth:

┌─────────────────────────────────────────┐
│ Layer 3: Business (SOPs, guardrails)     │
├─────────────────────────────────────────┤
│ Layer 2: Data Flow (Rakib)               │
│ Provenance DAG + policy enforcement      │
├─────────────────────────────────────────┤
│ Layer 1: OS Sandbox (e.g. nono/Landlock) │
└─────────────────────────────────────────┘

Based On

CaMeL and Dromedary solve the same problem differently. Rakib takes the best from each:

	CaMeL (Google DeepMind)	Dromedary (Microsoft)	Rakib
Approach	LLM generates restricted Python, custom interpreter runs it	Same code-then-execute, but with MCP tool loading	Both modes: interpreter OR router-level checking with native tool_use
Value tracking	CaMeLValue wrapping	CapabilityValue + ProvenanceGraph DAG	CapValue + ProvenanceDAG — cleaner, async
Policy language	Custom Python protocol	Rego (OPA) — industry standard	Rego (OPA) + JSON config fallback
Data labels	Source tracking only	Source tracking + sensitivity labels	Source tracking + safe values from instruction
Tool ecosystem	Hardcoded, AgentDojo only	MCP tool loading	Any tools — config-driven, no hardcoding
LLM support	Custom	Azure OpenAI only (LangChain)	Any LLM — works with native tool_use
Portability	Research artifact	Azure-locked	Zero dependencies, any platform
OS sandbox	None	None	Designed to complement (Landlock, etc.)
Status	"Not production"	"Not production"	Tested (19 tests), config-driven

What came from CaMeL: the core insight — don't trust the LLM to distinguish instructions from data. Track provenance at the value level and enforce policies at tool boundaries.

What came from Dromedary: the cleaner architecture — DAG-based provenance graph, MCP tool compatibility, OPA/Rego for policy (industry standard vs custom code), and data labels as a concept.

What Rakib adds: portability (any LLM, any tools, any platform), config-driven policies (JSON file, not hardcoded), router-level checking that works with native tool_use (no code generation required). Rakib is the data flow layer — for OS-level sandboxing, consider nono (Landlock/Seatbelt) as a complementary layer.

References:

• CaMeL paper: https://arxiv.org/abs/2503.18813
• CaMeL code: https://github.com/google-research/camel-prompt-injection
• Dromedary code: https://github.com/microsoft/dromedary
• Simon Willison's analysis: https://simonwillison.net/2025/Apr/11/camel/

License

Apache 2.0