Sectum AI vs Rebuff
TL;DR. Rebuff is an open-source runtime prompt-injection detector with a multi-layered defense — heuristics + LLM-as-detector + vector-DB of known attacks + canary tokens in prompts — that continuously learns from detected attacks. Sectum AI is a multi-tenant infrastructure verifier that plants cryptographic canary markers in tenant data and runs cross-tenant probes across 13 surfaces to produce a tamper-evident evidence pack. Both use the word “canary” but mean different things; the products solve completely different problems and are perfect complements on the same AI stack.
The two products
Rebuff (protectai/rebuff)
Category: runtime prompt-injection detector / defense. Now owned by Protect AI (which itself is being acquired by Palo Alto Networks).
License: open-source.
Method (LangChain blog on Rebuff, AI Safety Directory overview):
- Multi-layered detection:
- Heuristics — filter potentially malicious input before it reaches the LLM.
- LLM-based detection — a dedicated LLM analyzes incoming prompts and identifies potential attacks.
- Vector DB — stores embeddings of previous attacks to recognize and prevent similar future attacks.
- Canary tokens — inserted into prompts to detect leakages; on detection, the embedding goes back into the vector DB.
- Continuous learning: each detected attack strengthens defenses against similar future techniques.
- Self-hosted or managed; Python + TypeScript SDKs.
Pricing: free / OSS. Requires infrastructure (vector DB + LLM calls) for self-hosting.
Buyer: developers protecting LLM-app endpoints from prompt injection; teams that want OSS over commercial guardrails.
Sectum AI (sectum.ai)
Category: multi-tenant AI verification.
License: Apache 2.0 for the OSS core. Sectum Cloud commercial. The evidence layer in the OSS produces the same artifacts the hosted product does — by design.
Method: marker substrate. Provisions synthetic tenants on the customer’s AI stack, plants cryptographic canary markers (HARD_CANARY / ENTITY_CANARY / SECRET_CANARY) in tenant data, records a hashed ground-truth manifest, runs 11 cross-tenant probe classes across 13 surfaces, produces a tamper-evident evidence pack (RFC 3161 TSA + Sigstore Rekor + in-toto envelope).
For: CISOs, DPOs, and audit firms working on multi-tenant AI products. The flagship engagement is a GDPR Article 17 erasure attestation. See pricing.
”Canary” — same word, different things
The superficial overlap is the canary-token mechanism. The actual mechanics are different:
| Rebuff | Sectum AI | |
|---|---|---|
| What’s a canary | A token embedded in a prompt | A token embedded in tenant data (documents, metadata, eval sets, agent memory, etc.) |
| Where it’s planted | In the LLM prompt at runtime | In the tenant’s corpus during sectum-ai seed |
| What its detection proves | The prompt was leaked / exfiltrated (prompt-injection signal) | The tenant’s data crossed a tenant boundary (multi-tenant isolation failure) |
| When it’s checked | At runtime, per-request | During probe runs, periodically |
| Source of truth | An attack pattern DB that grows over time | A hashed ground-truth manifest, fixed per run |
| False-positive control | Heuristics + LLM detector + vector DB confidence | Manifest-grounded — a confirmed finding is provably traceable to a planted marker |
Both mechanisms are clever; they aim at different threats. Rebuff catches prompts that try to exfiltrate themselves. Sectum AI catches tenant data flowing across the boundary.
The categorical difference
| Rebuff | Sectum AI | |
|---|---|---|
| Mode | Runtime (per-request) | Periodic verification (per-run) |
| Threat | Prompt injection | Multi-tenant data leakage |
| Position in stack | In the request path (intercepts and decides) | Outside the request path (provisions, probes, attests) |
| Output | Block / allow per request | Tamper-evident audit pack |
| Detection unit | A prompt | A tenant boundary across 13 surfaces |
| For | Application engineering | CISOs, DPOs, audit firms |
| Cadence | Every request | On schedule / on-demand / at every audit or Article 17 cycle |
These are non-substitutable. A team building a prod multi-tenant AI app likely runs both — Rebuff (or Lakera Guard, or another runtime guardrail) on every request, and Sectum AI periodically for multi-tenant verification + auditor evidence.
When to use Rebuff
- You operate an LLM endpoint that takes user prompts and need runtime defense against prompt-injection attempts.
- You want a self-hardening detector that learns from previous attacks via the vector-DB layer.
- You prefer OSS over commercial guardrails (the Protect AI ownership and Palo Alto acquisition matter less here since Rebuff itself is open).
- You’re comfortable running the vector-DB and LLM-detector infrastructure yourself (or have a managed-service partner).
- You want layered defense — heuristics + LLM + vector-DB + canary tokens — rather than a single classifier.
When to use Sectum AI
- You operate a multi-tenant AI product and need to verify and prove that the tenant boundary holds across the AI stack (vector DB, RAG, caches, agents, MCP, fine-tunes, eval sets, search indexes, tracing pipelines).
- You’re facing a GDPR Article 17 erasure obligation for a churned tenant.
- You’re preparing for SOC 2 / ISO 27001 / HIPAA on a multi-tenant AI product and need auditor-acceptable, control-mapped, tamper-evident evidence.
- You need per-finding cryptographic attestation with an independent verifier (
sectum-ai verify). - You want an open-source evidence layer — the same artifacts the hosted product produces.
Using both
The mature multi-tenant AI SaaS deploys Rebuff (or another prompt-injection defense like Lakera Guard) in the request path and runs Sectum AI periodically for verification + audit evidence. They cover non-overlapping threats:
- Rebuff handles the active prompt-injection attack on every request.
- Sectum AI handles the multi-tenant isolation verification the auditor and DPO require.
Both products produce useful telemetry of different shapes. Neither replaces the other.
Note on Rebuff’s ownership
Rebuff is owned by Protect AI, which is being acquired by Palo Alto Networks (estimated $650-700M). The OSS license remains and the GitHub repository stays accessible, but the commercial backing has shifted — see Sectum AI vs Protect AI for the broader implications. For Rebuff specifically, the practical impact is minimal in the short term (the OSS continues to work); the longer-term trajectory depends on Palo Alto’s open-source posture.
This is one more example of the broader 2024-2026 AI security consolidation — three of the leading vendors (OpenAI→Promptfoo, Palo Alto→Protect AI/Rebuff, Cisco→Robust Intelligence) are now under hyperscaler or network-security incumbents. Sectum AI is a deliberately independent, evidence-first option.
Honest positioning
Rebuff is a clever, well-engineered runtime prompt-injection detector. Sectum AI is a multi-tenant verifier — not a prompt-injection defense. The two products don’t compete and shouldn’t be evaluated against each other; they solve different problems on different parts of the same stack. The “canary” terminology overlap is interesting but the techniques aim at different threats.
Pricing
- Rebuff — free, open-source. Self-hosting requires infrastructure (vector DB + LLM calls).
- Open Sectum (OSS) — free, Apache 2.0.
- Sectum Cloud — see pricing.
References
- Rebuff — protectai/rebuff on GitHub, LangChain blog on Rebuff, Rebuff overview (AI Safety Directory), Best Prompt Injection Detection Tools 2026 (safeprompt.dev).
- Sectum AI — GitHub, docs, attack catalog, evidence chain, sample evidence packs.
- Related Sectum AI comparisons: Sectum AI vs Protect AI / Palo Alto — Rebuff’s parent ownership story; Sectum AI vs Lakera — another runtime defense vs verifier framing.