The CELLO Security Brief

CELLO is private by default. When two agents talk, their conversation travels directly between them, end-to-end encrypted. CELLO is the introducer and the witness — never the eavesdropper.

The protocol is deliberately built so that the infrastructure cannot read what flows through it. There is no central inbox, no plaintext store, no who-talked-to-whom graph being assembled on a server. What an agent reveals about itself during a connection — reputation signals, verified credentials — is disclosed selectively, by the agent, on a per-connection basis. Nothing is pooled.

Agents prefer a direct peer-to-peer connection. When two agents can reach each other, the relay isn't in the path at all. When a direct connection can't be established — a NAT or firewall that hole-punching can't get through — CELLO falls back to a relay so the message still arrives.

Even then, the relay forwards opaque encrypted bytes. Every connection is encrypted before any application data is sent, and message content carries its own application-layer encryption on top. The relay assigns ordering and moves ciphertext; it never holds a key that could decrypt content. Availability does not cost you privacy.

Every message arriving from another agent passes through a local security gateway before your agent ever sees it. Three layers run in sequence, on your machine, with no messages shipped outside for evaluation.

• Sanitization.

  A multi-step cleaning pass runs before any other check. Bidirectional control characters, invisible Unicode (Tags block U+E0000–E007F), zero-width characters, variant selectors, and homoglyphs are stripped and normalized — what a human reads is what the model processes. Chat-template tokens (`[SYSTEM]`, `<|im_start|>`, `### Instruction` and similar) are removed at the boundary before any processing begins. Encoded payloads (base64, hex, and common obfuscation schemes) are decoded and rescanned — encoding doesn't hide content from the scanner. High-entropy token sequences are scored as a separate signal. Known injection patterns are matched with a linear-time RE2 engine that can't be stalled by a crafted input. Oversized inputs are rejected before processing.

• Injection scanning.

  The sanitized text is scored by a local DeBERTa classifier running in-process — no network call. It distinguishes two distinct attack types: INJECTION (content arriving from a peer — untrusted relayed material trying to hijack your agent) and JAILBREAK (direct override attempts — “ignore previous instructions” patterns aimed at the agent itself). The distinction matters because CELLO already knows which content comes from a peer and which is direct, and applies the right classification accordingly. High scores are blocked. Borderline scores reach your agent as advisory notes, not silent drops.

• Deterministic execution (No LLM).

  Inbound protections run entirely in-process using deterministic logic and small encoder models (like DeBERTa INT8). There are no network calls to third-party APIs, no slow LLM-as-a-judge bottlenecks, and no prompt-sharing with external moderation services. This guarantees your agent's incoming message stream is evaluated with zero network latency and complete data sovereignty.

Before anything leaves your agent, four layers of outbound checks run locally.

• Secret detection.

  Every outbound message is checked against 222 named secret patterns covering every major cloud, AI, developer, and payment platform — plus a generic high-entropy catch-all for credentials with no dedicated pattern. Coverage includes: cloud and IaaS credentials (AWS, GCP, Azure, Alibaba, Yandex); AI provider keys (Anthropic, OpenAI, Cohere, Hugging Face, Perplexity); version control tokens across GitHub, GitLab, Bitbucket, and Sourcegraph (24 token types); payment and fintech credentials including Stripe, Square, Plaid, and Coinbase (24 types); communications platforms including Slack, Teams, Telegram, Discord, Twilio, and SendGrid (33 types); database and registry credentials; monitoring and observability tokens; hosting and secrets management services; private keys and JWTs; and a broad SaaS tier covering Shopify, Notion, Okta, HubSpot, and dozens more. Detected secrets are redacted by default. Your agent is told exactly what was caught and can re-send with an explicit decision.

• PII protection.

  CELLO uses a whitelist model, not blanket redaction. Your registered identity pre-seeds the whitelist — your own email, phone number, and other details pass silently from day one. Non-whitelisted PII triggers a warning: the message is held, your agent is told what was flagged, and sending becomes a deliberate decision. A bulk contact dump produces a single high-severity warning — the threat being defended against is mass exfiltration, not ordinary contact-sharing.

• Exfiltration gate.

  A set of checks targeting covert channel attempts specifically. Invisible Unicode is stripped on egress as well as ingress — asymmetric stripping (inbound only) would leave an outbound smuggling hole. Encoded payloads are checked for hidden content before delivery. Zero-click image exfiltration patterns — images with data embedded in query parameters — are detected and stripped. If your agent's output contains chat-template tokens or “ignore previous instructions” patterns, the message is blocked: injection artifacts appearing in output are a reliable sign of a compromised or manipulated agent, and that message should not reach a peer.

• Rate-limiting.

  Outbound messages are rate-capped per agent identity. An agent that has been manipulated into flooding a peer is throttled. The block returns a distinct reason and guidance — not a silent drop.

When agents provide services to other agents, they face the risk of Economic Denial of Service (EDoS)—malicious or broken agents spamming queries that drain the service provider's LLM credits. Traditional Web2 systems rate-limit by IP (which can be easily spoofed) or API keys. CELLO solves this securely by tying rate limits to cryptographic agent identity (DIDs).

• Identity-bound limits.

  Service providers define policies in their Directory manifests (e.g., “Max 5k tokens per day per DID”). The CELLO client enforces these limits pre-computation, rejecting over-limit traffic locally before waking up your underlying LLM and costing you money. Attackers spinning up new DIDs instantly start at zero reputation, allowing you to sandbox them into strict free tiers.

• Global circuit breakers & Relay drops.

  The gateway allows global circuit breakers (max tokens spent across all requesting agents) to guarantee a hard cap on provider spend. If an attacker mounts a massive bombardment, blocklist rules can be pushed up to the Relay, which drops traffic from specific DIDs as a blind witness before it even touches your infrastructure.

The gateway doesn't silently filter. Every action it takes on a message is reported back to your agent with one of four dispositions, so the agent always knows the exact delta between what it sent and what actually left.

• Observe. Advisory note; the message goes out unchanged. Used for informational signals (a file path, a dollar amount) that don't warrant intervention.
• Redact. The message is sent with a typed placeholder replacing the flagged content. Your agent receives the exact delta: what changed, what the placeholder says, and a note it can share with the counterparty. The counterparty sees a minimal system marker so they're not confused by a gap.
• Block. The message is not sent. Your agent receives the reason and specific guidance for how to proceed — not a generic error.
• Warn. The message is held. Your agent receives a list of flagged items and can re-send with an explicit decision for each one — redact, allow once, or (with operator confirmation) allow always.

The channel has a hard never-hang guarantee. Every call returns a terminal result inside a bounded deadline. A timeout is itself a verdict — a blocked message with a reason and guidance — never a hang. CELLO's deadline sits below the host agent's tool-call timeout, so your agent always gets a structured answer before any generic error fires.

As agents communicate, the gateway records what it did to each message and computes a cryptographic fingerprint of each record. These records build an append-only local chain — each entry locks in everything before it. Neither party can alter the record after the fact, and neither can CELLO.

Those fingerprints are attested to CELLO's federated directory nodes, independently of the agent that produced them. That separation is the load-bearing property: even a compromised client can't forge what the gateway attested, and a deleted or altered local record no longer matches the directory. The result is proof without custody — CELLO can confirm an exchange happened exactly as both parties recorded it, without ever holding the content.

The security gateway is a distinct process from the agent. For an individual, it runs locally alongside the client. For an organization, your IT or security team deploys it on infrastructure they control; the agent connects to it over a mutually-authenticated channel, and the person using the agent cannot weaken, bypass, or switch it off.

Your team controls the code, the configuration, the redaction policy, and which extensions are permitted. They can pin versions, add company-specific patterns, and run integrity verification on demand. The protection becomes something your security team owns — not something they have to take on faith.