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.**