Skip to content

Latest commit

 

History

History
36 lines (24 loc) · 4.3 KB

File metadata and controls

36 lines (24 loc) · 4.3 KB
title Why Sponsio
description How Sponsio differs from prompt-injection filters, output validators, LLM-as-judge guardrails, sandboxing, and other deterministic enforcers.

Why Sponsio

Sponsio operates at the action boundary. It checks which tool a model is about to call, with what arguments, given everything that has already happened in the trace, before any side effect fires. That is a different position from every other guardrail category.

Compared to other guardrail categories

Approach When it works Where it fails How Sponsio solves
Prompt-injection Filters Pre-generation, on input text Drifts on novel phrasings; sees text, not tool calls; no notion of action history Enforces which tools may run, in what order, with what arguments, before function call executes, with full trace context
Output Validators Post-generation, on response strings The mistakes (refund, DB write, API call) may already have fired Blocks the call before execution; reasons over the full action history, not just the latest string
LLM-as-Judge Flexible, handles fuzzy properties; useful for offline eval Non-deterministic verdicts, hundreds-of-ms latency, itself prompt-injectable, unsuitable as a synchronous gate Sub-0.01ms deterministic checks, zero LLM in the hot path
Sandboxing & Access Control Lists Strong perimeter for identity- and resource-level isolation Narrows agent capability. Gates by who and what resource, not by behavior sequence Enforces temporal contracts over the action sequence, including ordering, history, and multi-step invariants, preserving agent capability

Compared to other deterministic enforcers

1. Temporal contracts over sequential actions, not stateless rule matching. Existing enforcers evaluate each action in isolation. Sponsio reasons over the full trajectory: "verify_recipient before send_email", "no external calls after PII access", "refund_payment ≤ 3 calls per session".

2. Machine-checkable, not heuristic. Contracts compile to LTL (linear temporal logic) formulas, then to deterministic finite automata (DFAs). Every verdict is a deterministic DFA transition, not a probabilistic confidence score. The same proof technique is used in hardware verification (for example, Intel FPU correctness proofs). How it works →

3. Zero to protected in minutes, no DSL learning curve. Existing tools require hand-written YAML / Rego / Cedar policies from scratch. Sponsio offers four paths in:

  • Auto-inferred: sponsio init (interactive wizard) reads your tool signatures and writes starter contracts.
  • Contract library: include pre-built bundles by capability (sponsio:capability/shell, …/filesystem) or by incident (sponsio:incident/openclaw); each bundle composes 46 deterministic patterns underneath.
  • Natural language: sponsio validate "..." compiles plain English to LTL.
  • Policy doc: sponsio scan --policy security.md parses an existing compliance document.

4. Framework-agnostic and low-dependency. Some other tools ship as opinionated stacks bundling identity, SRE, dashboards, and orchestration. Sponsio is a single enforcement library that plugs in alongside whatever observability, IAM, and orchestration you already use.


Back to README · Architecture deep dive · Formal methods primer