Governance layer for agentic AI — signed, verifiable receipts for every agent action.
Runs on your machine from its package; the steps are below.
At most: moves money, runs code or commands, deletes data, or sends messages for you.
Odel charges nothing per call. The publisher may charge for its own service.
Runs locally over stdio
This server isn't hosted — your MCP client launches it from a package registry. Use one of the commands below, or drop the config into your client (e.g. Claude Desktop).
Run
npx -y @yobekasbah/mcp-server
MCP client config
{
"mcpServers": {
"kasbah": {
"command": "npx",
"args": [
"-y",
"@yobekasbah/mcp-server"
]
}
}
}Deterministic policy control for autonomous systems.
Kasbah Core is a minimal control plane that sits between AI agents and execution: it evaluates intent, enforces tool gates, and writes an append-only audit log.
This repo ships a runnable prototype for security engineers and CTOs.
docker compose up --build
---
## 🔐 Minimal real API example (no demo, no UI)
This is a real Kasbah-Core runtime flow.
No simulation. No frontend. No policy-only logic.
STEP 1 — Ask Kasbah if an action is allowed
curl -s http://localhost:8002/api/rtp/decide \
-H "Content-Type: application/json" \
-H "Authorization: Bearer DEV_KEY" \
-d '{
"agent_id": "support-bot",
"tool_name": "db.query",
"signals": {
"consistency": 0.95,
"context": 0.90
}
}'
Example response:
{
"decision": "ALLOW",
"ticket": {
"jti": "5a3bde1e887e000116e8943663b5088d",
"expires_at": 1770307384
}
}
STEP 2 — Execute the action using the issued ticket
curl -s http://localhost:8002/api/rtp/consume \
-H "Content-Type: application/json" \
-d '{
"ticket": "5a3bde1e887e000116e8943663b5088d",
"tool_name": "db.query",
"usage": { "tokens": 120 }
}'
Response:
{ "status": "ALLOWED" }
STEP 3 — Replay the same ticket (blocked by Kasbah)
curl -s http://localhost:8002/api/rtp/consume \
-H "Content-Type: application/json" \
-d '{
"ticket": "5a3bde1e887e000116e8943663b5088d",
"tool_name": "db.query"
}'
Response:
{
"status": "DENIED",
"reason": "replay_detected"
}
This denial is stateful and irreversible.
Tickets are single-use, tool-bound, time-bound, and verified at runtime.
---
## 🔐 Minimal real API example (no demo, no UI)
This is a real Kasbah-Core runtime flow.
No simulation. No frontend. No policy-only logic.
STEP 1 — Ask Kasbah if an action is allowed
curl -s http://localhost:8002/api/rtp/decide \
-H "Content-Type: application/json" \
-H "Authorization: Bearer DEV_KEY" \
-d '{
"agent_id": "support-bot",
"tool_name": "db.query",
"signals": {
"consistency": 0.95,
"context": 0.90
}
}'
Example response:
{
"decision": "ALLOW",
"ticket": {
"jti": "5a3bde1e887e000116e8943663b5088d",
"expires_at": 1770307384
}
}
STEP 2 — Execute the action using the issued ticket
curl -s http://localhost:8002/api/rtp/consume \
-H "Content-Type: application/json" \
-d '{
"ticket": "5a3bde1e887e000116e8943663b5088d",
"tool_name": "db.query",
"usage": { "tokens": 120 }
}'
Response:
{ "status": "ALLOWED" }
STEP 3 — Replay the same ticket (blocked by Kasbah)
curl -s http://localhost:8002/api/rtp/consume \
-H "Content-Type: application/json" \
-d '{
"ticket": "5a3bde1e887e000116e8943663b5088d",
"tool_name": "db.query"
}'
Response:
{
"status": "DENIED",
"reason": "replay_detected"
}
This denial is stateful and irreversible.
Tickets are single-use, tool-bound, time-bound, and verified at runtime.
## Moats / Security posture
See `docs/MOATS_REGISTRY.md` for the authoritative list of implemented moats, evidence, and explicit non-goals.