Guardrails by Design: Sicherheit im Code, nicht im Modell

Dem Modell nicht vertrauen

Ein Agent, der live Ziele angreift, darf seine Grenzen niemals vom Sprachmodell bekommen. Das

Modell darf alles *vorschlagen* — ausgeführt wird nur, was die Engine erlaubt. Diese Grenzen sind

bei agentschmitz fest im Code verankert:

• Autorisierung: Jedes Ziel muss als autorisiert bestätigt sein, bevor ein Engagement startet.
• Scope-Lock: Nur die eingetragenen Hosts werden berührt — alles andere wird verworfen.
• Deny-List: Große Fremd-Domains sind grundsätzlich gesperrt.
• SSRF-Schutz: Interne Infrastruktur und private/reservierte IP-Bereiche (inkl. Cloud-Metadata)

werden blockiert — sowohl beim Scope-Aufbau als auch pro ausgehendem Request, DNS-aufgelöst.

• Nicht-destruktiv: Gefährliche Payloads und destruktive HTTP-Methoden werden gefiltert,

Anfragen rate-limitiert und pro Engagement budgetiert.

Warum im Code, nicht im Prompt?

Prompt-Anweisungen ("bitte nichts Schädliches tun") sind kein Sicherheitsmechanismus — sie sind

beeinflussbar und nicht garantiert. Ein im Code erzwungener Filter dagegen prüft *jede* Aktion,

bevor sie das System verlässt, unabhängig davon, was das Modell ausgegeben hat.

Sichtbarkeit statt Verschleierung

Wir verschleiern nichts. Jede Probe trägt einen klaren User-Agent, und der Test läuft über eine

nachvollziehbare Quelle. Genau so soll autorisiertes Pentesting funktionieren: **erkennbar,

abgrenzbar von echten Angriffen — und jederzeit unter Kontrolle.**

Was Sie vor dem ersten Test tun sollten

Auch die besten Schutzmechanismen ersetzen keine gute Vorbereitung. Diese Schritte haben sich

bewährt:

1. Berechtigung klären: Testen Sie nur Systeme, die Ihnen gehören oder für die Sie eine

schriftliche Erlaubnis haben — etwa vom Hoster oder vom Auftraggeber.

2. Beteiligte informieren: Sagen Sie Ihrem Hosting-Anbieter und internen Teams Bescheid,

damit ein Test nicht als echter Angriff missverstanden wird.

3. Scanner-IP freigeben: Setzen Sie die angegebene Scanner-IP auf die Allowlist Ihrer

Firewall oder WAF, damit der Test nicht ausgebremst wird.

4. Staging zuerst: Wer ganz sicher gehen will, testet zuerst eine Staging-Umgebung.

5. Backups prüfen: Ein aktuelles Backup gehört zu jedem Test — auch wenn dieser

nicht-destruktiv angelegt ist.

Warum Guardrails auch Ihnen nützen

Guardrails schützen nicht nur Dritte, sondern auch Sie selbst: Ein klar begrenzter Test kann

nicht versehentlich Systeme Ihrer Partner treffen, verursacht keine unerwartete Last und bleibt

im Protokoll nachvollziehbar. Das erleichtert die Abstimmung mit Hostern, Kunden und Auditoren.

Häufige Fragen

Warum kann ich keine Domains großer Anbieter testen?

Weil Sie für deren Systeme in aller Regel keine Berechtigung haben. Die Sperre verhindert

versehentliche oder unberechtigte Tests.

Erkennt meine Firewall den Test?

Wahrscheinlich ja — der Test ist bewusst erkennbar. Mit einer Freigabe der Scanner-IP verhindern

Sie, dass er blockiert wird und Ergebnisse unvollständig bleiben.

Was passiert, wenn mein Ziel während des Tests nicht erreichbar ist?

Der Test bricht nach mehreren fehlgeschlagenen Verbindungen kontrolliert ab, statt die Anwendung

weiter zu belasten.