
Tragbare Sicherheitsregeln für die Aktionsgrenze von KI-Agenten
Portable, offene Spezifikation für Sicherheitsregeln von KI-Agenten
Spezifikation · Dokumentation · Regelsätze · JSON-Schema
HushSpec ist ein offenes Policy-Format für Sicherheitsregeln von KI-Agenten. Es definiert was ein Agent zur Laufzeit tun darf – einschließlich Dateisystemzugriff, Netzwerk-Egress, Tool-Nutzung, Erkennung von Geheimnissen und mehr – ohne vorzuschreiben, wie diese Kontrollen durchgesetzt werden müssen. Diese Trennung macht Policies über Laufzeitumgebungen, Frameworks und Sprachen hinweg portabel.
v0.1.1-alpha — Die Kern-Spezifikation, alle vier SDKs (Rust, TypeScript, Python, Go) und die h2h-CLI sind veröffentlicht und funktionsfähig. Arbeite dich per Parsen, Validieren, Bewerten, Zusammenführen, Auflösen, Erkennen, Signieren und Prüfen durch 10 Regeltypen und 3 Erweiterungsmodule. Die API-Oberfläche stabilisiert sich, ist aber noch nicht eingefroren — vor v1.0 sind weitere Verfeinerungen zu erwarten.
hushspec: "0.1.0"
name: production-agent
rules:
forbidden_paths:
patterns:
- "**/.ssh/**"
- "**/.aws/**"
- "/etc/shadow"
egress:
allow:
- "api.openai.com"
- "*.anthropic.com"
- "api.github.com"
default: block
tool_access:
block: [shell_exec, run_command]
require_confirmation: [file_write, git_push]
default: allow
secret_patterns:
patterns:
- name: aws_key
pattern: "AKIA[0-9A-Z]{16}"
severity: critical
skip_paths: ["**/test/**"]
shell_commands:
forbidden_patterns:
- "rm\\s+-rf\\s+/"
- "curl.*\\|.*bash"
Alle vier SDKs implementieren die vollständige HushSpec-Pipeline, vom Parsen und Validieren über die Auflösung bis zur Auswertung.
Homebrew, npm und vorgefertigte Binärdateien werden ab dem ersten von der Release-Pipeline erstellten
v0.x-Tag verfügbar, sobald die Release-Pipeline Artefakte, die Tap-Formel und die npm-Pakete veröffentlicht. Bis dahin über Cargo installieren.
Alle Methoden installieren den Befehl h2h. Siehe CLI-Tool unten.
[dependencies]
hushspec = "0.1"
npm install @hushspec/core
pip install hushspec
go get github.com/backbay-labs/hush/packages/go@main
use hushspec::HushSpec;
let yaml_str = "hushspec: \"0.1.0\"\nname: example\n";
let spec = HushSpec::parse(yaml_str)?;
let result = hushspec::validate(&spec);
assert!(result.is_valid());
import { parseOrThrow, validate } from '@hushspec/core';
const yamlString = 'hushspec: "0.1.0"\nname: example\n';
const spec = parseOrThrow(yamlString);
const result = validate(spec);
console.log(result.valid); // true
from hushspec import parse_or_raise, validate
yaml_string = 'hushspec: "0.1.0"\nname: example\n'
spec = parse_or_raise(yaml_string)
result = validate(spec)
assert result.is_valid
import (
"fmt"
"github.com/backbay-labs/hush/packages/go/hushspec"
)
yamlString := "hushspec: \"0.1.0\"\nname: example\n"
spec, err := hushspec.Parse(yamlString)
if err != nil {
panic(err)
}
result := hushspec.Validate(spec)
fmt.Println(result.IsValid())
Jedes SDK stellt eine evaluate()-Funktion bereit, die eine geparste Spezifikation und eine Aktion entgegennimmt und dann eine Entscheidung (allow, warn oder deny) sowie Details zur zutreffenden Regel zurückgibt.
import { parseOrThrow, evaluate } from '@hushspec/core';
const spec = parseOrThrow(policyYaml);
const result = evaluate(spec, { type: 'egress', target: 'api.openai.com' });
// result.decision === 'allow' | 'warn' | 'deny'
// result.matched_rule === 'egress'
from hushspec import parse_or_raise, evaluate
spec = parse_or_raise(policy_yaml)
result = evaluate(spec, {"type": "egress", "target": "api.openai.com"})
assert result.decision in ("allow", "warn", "deny")
HushGuard kapselt das Laden und Auswerten von Policies hinter einer einfachen evaluate-, check- und enforce-Schnittstelle für Anwendungscode.
import { HushGuard } from '@hushspec/core';
const guard = HushGuard.fromFile('./policy.yaml');
guard.enforce({ type: 'tool_call', target: 'bash' }); // throws HushSpecDenied if denied
from hushspec import HushGuard
guard = HushGuard.from_file("./policy.yaml")
guard.enforce({"type": "tool_call", "target": "bash"}) # raises HushSpecDenied if denied
Die h2h-CLI deckt den üblichen Policy-Workflow ab: Validieren, Testen, Auswerten und Erklären einzelner Aktionen, Linten, Diffen, Formatieren, Initialisieren, Signieren, Verifizieren und Auslösen des Panikmodus.
# Validate a policy against the HushSpec schema
h2h validate policy.yaml
# Run evaluation test suites
h2h test --fixtures ./tests/
# Evaluate one action and explain the decision
h2h eval policy.yaml --type egress --target api.example.com
h2h explain policy.yaml --type egress --target api.example.com
# Static analysis and linting
h2h lint policy.yaml
# Lint and auto-fix decision-neutral issues
h2h lint policy.yaml --fix
# Compare two policies and show effective decision changes
h2h diff old.yaml new.yaml
# Format policy files canonically
h2h fmt policy.yaml
# Scaffold a new policy project
h2h init --preset default
# Sign a policy with Ed25519
h2h sign policy.yaml --key h2h.key
# Verify a policy signature
h2h verify policy.yaml --key h2h.pub
# Generate a new Ed25519 keypair
h2h keygen
# Emergency override (deny-all kill switch)
h2h panic activate --sentinel /tmp/hushspec.panic
h2h panic deactivate --sentinel /tmp/hushspec.panic
Siehe Installation oben für Installationsoptionen — Homebrew, npm, Cargo oder vorgefertigte Binärdateien.
evaluate_audited() erzeugt strukturierte Entscheidungsbelege mit Regel-Traces, Policy-Zusammenfassungen und optionaler Schwärzung von Inhalten. Belege entsprechen hushspec-receipt.v0.schema.json und sind für prüfungsintensive Umgebungen wie SOC 2, HIPAA, PCI-DSS und FedRAMP konzipiert.
import { parseOrThrow, evaluateAudited } from '@hushspec/core';
const spec = parseOrThrow(policyYaml);
const receipt = evaluateAudited(spec, action, {
enabled: true,
include_rule_trace: true,
redact_content: false,
});
// receipt.decision, receipt.rule_evaluations, receipt.policy_summary
Beleg-Sinks (FileReceiptSink, ConsoleReceiptSink, FilteredSink, MultiSink, CallbackSink) sind in allen vier SDKs verfügbar, um Belege an Speicher, Logging oder OTLP-Endpunkte weiterzuleiten.
Die Erkennungspipeline integriert Prüfungen auf Prompt-Injection, Jailbreak und Exfiltration in den Auswertungsablauf. Referenz-Detektoren auf Regex-Basis sind in allen SDKs enthalten, und benutzerdefinierte Detektoren können über DetectorRegistry registriert werden.
import { parseOrThrow, evaluateWithDetection, DetectorRegistry } from '@hushspec/core';
const registry = DetectorRegistry.withDefaults();
const result = evaluateWithDetection(spec, action, registry, {
enabled: true,
prompt_injection_threshold: 0.5,
});
// result.detection_results contains matched patterns and confidence scores
Vorgefertigte Adapter übersetzen frameworkspezifische Tool-Aufrufe in HushSpec-Auswertungsaktionen.
Die Schnittstelle EvaluationObserver und der Wrapper ObservableEvaluator senden strukturierte Ereignisse für jede Auswertung, jedes Laden und Neuladen von Policies. Integrierte Observer umfassen JsonLineObserver, ConsoleObserver und MetricsCollector.
import { ObservableEvaluator, JsonLineObserver, MetricsCollector } from '@hushspec/core';
const evaluator = new ObservableEvaluator();
evaluator.addObserver(new JsonLineObserver(process.stderr));
evaluator.addObserver(new MetricsCollector());
const result = evaluator.evaluate(spec, action);
Policies können mit Ed25519-Schlüsseln signiert und beim Laden verifiziert werden. Die CLI stellt die Befehle sign, verify und keygen bereit. Das Signaturformat entspricht hushspec-signature.v0.schema.json.
# Generate a keypair
h2h keygen --output-dir mykeys
# Sign a policy (creates policy.yaml.sig)
h2h sign policy.yaml --key mykeys/h2h.key
# Verify the signature
h2h verify policy.yaml --key mykeys/h2h.pub
Der Panikmodus ist ein Deny-All-Notausschalter, der sofort aktiviert werden kann, ohne Policies neu bereitzustellen. Sie können ihn über eine Sentineldatei, die CLI oder einen API-Aufruf auslösen. Solange der Panikmodus aktiv ist, gibt jede Auswertung deny zurück.
# Activate panic mode
h2h panic activate --sentinel /tmp/hushspec.panic
# Deactivate
h2h panic deactivate --sentinel /tmp/hushspec.panic
import { activatePanic, deactivatePanic, isPanicActive } from '@hushspec/core';
activatePanic();
// All evaluate() calls now return deny
deactivatePanic();
Policies können aus lokalen Dateien, HTTPS-URLs (mit ETag-Caching und SSRF-Schutz) oder integrierten Regelsätzen geladen werden. PolicyWatcher und PolicyPoller unterstützen Hot Reload ohne Neustart des Prozesses.
import { PolicyWatcher, HushGuard } from '@hushspec/core';
const guard = HushGuard.fromFile('./policy.yaml');
const watcher = new PolicyWatcher('./policy.yaml', {
onChange: (newSpec) => guard.swapPolicy(newSpec),
});
watcher.start();
HushSpec unterstützt optionale Erweiterungsmodule für erweitertes Policy-Verhalten:
| Erweiterung | Zweck |
|---|---|
| Posture | Deklarative Zustandsmaschine für Fähigkeiten und Budgets |
| Origins | Herkunftsbewusste Policy-Projektion (Slack, GitHub, E-Mail usw.) |
| Detection | Schwellenwertkonfiguration für Prompt-Injection, Jailbreak, Threat Intelligence |
extensions:
posture:
initial: standard
states:
standard: { capabilities: [file_access, egress] }
restricted: { capabilities: [file_access] }
transitions:
- { from: "*", to: restricted, on: critical_violation }
detection:
prompt_injection:
block_at_or_above: high
Einsatzbereite Policies befinden sich in rulesets/:
HushSpec-Dokumente werden nativ in Clawdstrike geladen:
// Auto-detects HushSpec vs Clawdstrike-native format
let policy = clawdstrike::Policy::from_yaml_auto(yaml)?;
# Convert between formats
hush policy migrate policy.yaml --to hushspec
spec/ Normative specification, including core and extension docs
schemas/ JSON Schema definitions
crates/ Rust crates
hushspec/ Core library: parse, validate, merge, resolve, evaluate, detect, sign
hushspec-cli/ CLI tool
hushspec-testkit/ Conformance test runner
packages/ Language SDKs for TypeScript, Python, and Go
rulesets/ Built-in security rulesets
fixtures/ Conformance and evaluation fixtures
docs/ mdBook documentation site
generated/ Generated shared SDK contract artifacts
scripts/ Code generation and CI tooling
Die normative Spezifikation befindet sich in spec/. JSON-Schema-Definitionen für die programmatische Validierung finden sich in schemas/. Die vollständige Dokumentation liegt in docs/.
Apache-2.0. Siehe LICENSE.
| Fähigkeit | Rust | TypeScript | Python | Go |
|---|
| Parsen + Validieren (Level 1) | Ja | Ja | Ja | Ja |
| Zusammenführen (Level 2) | Ja | Ja | Ja | Ja |
| Auflösen (Level 2+) | Ja | Ja | Ja | Ja |
| Auswerten (Level 3) | Ja | Ja | Ja | Ja |
| Prüfpfad (Level 4) | Ja | Ja | Ja | Ja |
| Erkennung | Ja | Ja | Ja | Ja |
| Beobachtbarkeit | Ja | Ja | Ja | Ja |
| Beleg-Sinks | Ja | Ja | Ja | Ja |
| Methode | Befehl |
|---|
| Homebrew (macOS/Linux) | brew install backbay-labs/tap/h2h |
| npm | npm install -g @hushspec/cli (oder npx @hushspec/cli validate policy.yaml) |
| Cargo (aus dem Quellcode) | cargo install hushspec-cli |
| Vorgefertigte Binärdateien | GitHub-Releases — h2h-<tag>-<target>.tar.gz + SHA256SUMS, mit Provenance-Attestierung |
| Framework | Adapter | SDK |
|---|
| Claude / Anthropic | mapClaudeToolToAction, createSecureToolHandler | TypeScript |
| OpenAI | mapOpenAIToolCall, createOpenAIGuard | TypeScript |
| MCP (Model Context Protocol) | mapMCPToolCall, createMCPGuard | TypeScript |
import { HushGuard, mapClaudeToolToAction } from '@hushspec/core';
const guard = HushGuard.fromFile('./policy.yaml');
const action = mapClaudeToolToAction(toolUseBlock);
guard.enforce(action);
| Regel | Zweck |
|---|
forbidden_paths | Blockiert Zugriff auf sensible Dateisystempfade |
path_allowlist | Allowlist-basierter Lese-/Schreib-/Patch-Zugriff |
egress | Netzwerk-Egress-Kontrolle nach Domain |
secret_patterns | Erkennt Geheimnisse im Dateiinhalt |
patch_integrity | Validiert die Diff-Sicherheit (Größenlimits, verbotene Muster) |
shell_commands | Blockiert gefährliche Shell-Befehle |
tool_access | Steuert Tool-/MCP-Aufrufe |
computer_use | Steuert CUA-Aktionen |
remote_desktop_channels | Steuert Seitenkanäle von Remote-Desktops |
input_injection | Steuert Fähigkeiten zur Eingabe-Injection |
| Regelsatz | Beschreibung |
|---|
default | Ausgewogene Sicherheit für die Ausführung von KI-Agenten |
strict | Maximale Sicherheit, minimale Berechtigungen |
permissive | Entwicklungsfreundlich, großzügige Limits |
ai-agent | Optimiert für KI-Codierungsassistenten |
cicd | Sicherheit für CI/CD-Pipelines |
remote-desktop | Computer-Use-Agenten-Sitzungen |
panic | Deny-All-Notfall-Override |