Cullis logo Cullis
Open Source · Apache 2.0

Cryptographic identity
and E2E messaging
for AI agents that work
across organizations.

A self-hosted trust broker and MCP proxy. Every agent gets an x509 identity, every message is end-to-end encrypted, every decision is cryptographically audited — across organizational boundaries.

RFC 9449 DPoP Token Binding
SPIFFE Workload Identity
x509 · mTLS Mutual Authentication
AES-256-GCM E2E Encryption
Apache 2.0 Open Source License
Self-Hosted Zero SaaS Lock-in

AI agents are operating
without identity

When agents from different organizations need to collaborate, they rely on mechanisms that were never designed for autonomous, cross-boundary interactions.

Static API Keys

Long-lived secrets that grant permanent, unlimited access. A single leak means full impersonation with no way to detect or revoke the compromise in real time.

No Mutual Authentication

Agents from different organizations have no way to cryptographically verify each other's identity. There's no chain of trust, no issuer validation, no proof of origin.

Zero Audit Trail

When something goes wrong across organizational boundaries, there is no tamper-evident record of who authorized what. Compliance is impossible. Non-repudiation is a myth.

Six pillars,
zero blind faith

Every security property is enforced at the protocol level — not in config files, not in application code. No secrets to share, no knobs to get wrong.

Pillar 01 · Identity

Cryptographic identity
from day one

Every agent gets a real x509 identity signed by its organization's CA. No shared secrets, no long-lived API keys, no passwords. Tokens are bound to ephemeral keys so theft is meaningless.

  • Workload x509 PKI — SPIFFE-compatible IDs, 3-tier hierarchy
  • Auto PKI — Org CA on first join, agent certs on demand
  • DPoP token binding — RFC 9449 proof-of-possession
  • Standards aligned — WIMSE, SPIFFE, RFC 7638, RFC 7517
agent · acme::rfq-bot Active
Cert status Pinned
SPIFFE ID spiffe://acme/agent/rfq-bot
Thumbprint sha256:a3f9…b21c
Issuer CN=Acme Org CA
DPoP key EC P-256 · jwk-bound
Expires 2027-04-12 14:00 UTC
Pillar 02 · Encryption

The broker is blind
by design

Payloads are sealed end-to-end between agents, with dual signatures for non-repudiation and transport integrity. The broker routes envelopes but never sees the message.

  • AES-256-GCM — payload encryption with RSA-OAEP key wrap
  • Dual RSA-PSS signatures — origin + transport integrity
  • Broker blind — cannot decrypt, cannot forge, cannot replay
  • mTLS wrapping — agents to proxies, proxies to broker
message · session 9af2 E2E
Org A Agent 1 encrypt(pub_B)
Broker blind forward only
Org B Agent 2 decrypt(priv_B)
AES-256-GCM · RSA-OAEP · RSA-PSS×2
Pillar 03 · Authorization

Both orgs must
say yes

Each organization owns its policy decisions. The broker queries both PDPs and only proceeds when both approve. No centralized power, no vendor making decisions for you.

  • Per-org PDP webhook — your policy, your infrastructure
  • OPA integration — Rego bundles as alternative backend
  • Dual-consent enforcement — both orgs must allow
  • Capability-based — fine-grained, scope-bound sessions
policy · session request 9af2 Allow
Org A · acme.com PDP allow
Org B · supplier.io PDP allow
Session granted · capability=supply.negotiate
Pillar 04 · Audit

Every decision,
cryptographically linked

Auth, session, message, policy — everything lands in a SHA-256 hash-chained ledger. Any tampering (insert, modify, delete, reorder) breaks the chain and is detectable immediately.

  • Hash-chained ledger — append-only, SHA-256 linked
  • Verify API — chain integrity check from dashboard
  • SIEM-ready export — structured JSON for ingestion
  • OpenTelemetry + Jaeger — distributed traces + metrics
audit ledger · last 4 Verified
#1248 · session.created a3f9…b21c
#1249 · message.sent 7e02…1d4a
#1250 · policy.allow c91d…8f33
#1251 · session.closed 2b5e…77a0
Chain verified · 1251/1251 entries valid
Pillar 05 · Federation

Self-service
onboarding

Each org deploys its own MCP Proxy and self-onboards via invite tokens. Agents authenticate with simple API keys — the proxy handles the cryptography. Zero manual certificate exchange.

  • MCP Proxy gateway — crypto-free agent integration
  • Invite onboarding — token-based, approval-gated
  • Dual dashboard — broker admin + org admin, CSRF-safe
  • OIDC per-org — Okta, AzureAD, Google with PKCE
onboarding · acme-corp Joined
01 Broker admin generates invite token Done
02 Org admin pastes token in proxy dashboard Done
03 Auto PKI generates Org CA + first agent cert Done
04 Broker approves · federation active Active
Pillar 06 · Developer Tools

Full lifecycle SDKs
Python & TypeScript

Auth, discovery, E2E encryption, signing, WebSocket streaming — all built-in. Private keys never touch disk: load them from Vault, AWS KMS, or your secret manager of choice.

  • Python & TypeScript SDKs — x509 + DPoP + E2E built-in
  • RFQ & transaction tokens — single-use, payload-bound
  • Secret manager support — load keys from Vault / KMS
  • WebSocket streaming — real-time session messaging
supplier_bot.py Python SDK
from cullis import BrokerClient
from cullis.vault import load_pem

# Keys live in Vault — never on disk
cert, key = load_pem("secret/acme/rfq-bot")

client = BrokerClient("https://broker.acme.com")
client.login_from_pem(
    agent_id="acme::rfq-bot",
    cert_pem=cert, key_pem=key,
)
#  mTLS + DPoP + E2E ready

sid = client.open_session(
    target="supplier::chips-bot",
    caps=["supply.negotiate"],
)

Federated by design

Agents talk to their local MCP Proxy with simple API keys. Proxies handle all cryptography and communicate with the broker over mTLS. Each organization retains full control.

Cullis federated trust architecture Agents in two organizations authenticate with API keys against local MCP Proxies. Proxies handle x509, DPoP and E2E encryption, then communicate with the Cullis Broker over mTLS. The broker verifies certificate chains, validates DPoP, queries both organizations' PDPs for authorization, and forwards end-to-end encrypted messages without being able to read plaintext. A session only proceeds when both organizations' Policy Decision Points allow it. Agent 1 API Key auth Agent 2 API Key auth API Key API Key MCP Proxy A Auto PKI · Vault API Key auth MCP Proxy B Auto PKI · Vault API Key auth mTLS + DPoP x509 + E2E E2E encrypted x509 + E2E CULLIS BROKER Verify cert chain Validate DPoP Query policies Forward E2E ⛔ Cannot read plaintext — zero-knowledge forwarding query / response query / response Org A PDP webhook / OPA allow ✓ / deny ✗ Org B PDP webhook / OPA allow ✓ / deny ✗ Both orgs must allow → session proceeds Agents use API keys → Proxies handle x509 + DPoP + E2E → Broker verifies + routes

What you can build

Cullis is the substrate for agent interactions that currently don't happen because the trust primitives don't exist. These are the shapes we see working today.

01 · Supply Chain

Cross-org RFQ negotiation

A buyer agent broadcasts a request to suppliers across the federation. Matching agents respond with signed quotes. The buyer picks one and authorizes a single-use transaction token bound to the payload hash. Every step cryptographically audited.

Discover suppliers by capability (supply.negotiate)
Broadcast RFQ, collect signed quotes with timeout
Approve winning quote, issue transaction token
Audit entire chain, tamper-evident, non-repudiable
02 · Multi-Tenant SaaS

Customer agents meet vendor agents

Your SaaS platform exposes AI agents to customers. Each customer org runs its own MCP Proxy, customer agents talk to your platform agents via the broker. You never see their plaintext, they never share secrets with you, and policy stays on both sides.

Customer deploys their MCP Proxy with BYOCA
Broker federates identity across trust domains
E2E encryption keeps you out of the payload
Per-tenant policy enforced by customer PDP
03 · Regulated B2B

Compliance-grade data exchange

Healthcare, finance, and critical infrastructure need AI agents that cross organizational boundaries without breaking compliance. Bring your own CA, enforce OPA policies, export the tamper-evident ledger straight to your regulator.

BYOCA — each org keeps its own key material
OPA policies encode regulatory constraints
E2E encryption satisfies data residency + GDPR
Hash-chained audit export for regulators / SIEM

Running in 60 seconds

Deploy the broker and proxy on your own infrastructure. Generate an invite token, register your org, create agents.

terminal
Prompt:$ git clone https://github.com/DaenAIHax/cullis Prompt:$ cd cullis Prompt:$ ./deploy.sh --dev Output: ✓ Broker ready at http://localhost:8000 Comment:# Deploy the MCP Proxy Prompt:$ docker compose -f docker-compose.proxy.yml up -d Output: ✓ Proxy ready at http://localhost:9100 Comment:# Open proxy dashboard, enter broker URL + invite token Comment:# Register org → create agents → done

Where Cullis sits

Cullis is not a service mesh, not an API gateway, not a workload identity provider. It's the missing layer between them — the one that turns the MCP protocol into a federated, cryptographically audited trust network.

Capability MCP (raw) SPIFFE / SPIRE Vault + Consul Cullis
Agent-to-agent identity across orgs Single trust domain Single datacenter Federated, BYOCA
DPoP token binding (RFC 9449) Built-in
E2E payload encryption (beyond mTLS) mTLS only AES-256-GCM + RSA-OAEP
Federated policy (per-org PDP) Intentions (local) Webhook + OPA, dual-consent
Tamper-evident audit chain Syslog only SHA-256 hash chain
Invite-based org onboarding Manual Manual Token + dashboard
MCP-native agent gateway Protocol spec Drop-in proxy
Cross-org session tokens (scope-bound) Capability-scoped
Self-hosted, open source, Apache 2.0 BSL / MPL Yes

Cullis composes with these tools rather than replacing them — you can back Cullis identities with a SPIRE-issued CA, keep your keys in Vault, and layer a service mesh underneath. What Cullis adds is the federated trust between organizations.

Engineered for zero-trust,
built for the agent era

Cullis is open source, standards-aligned, and ready to deploy on your infrastructure today. Star the repo, open an issue, or run it in your own network.