auth.md: Autonome KI B2B-Anmeldung ohne Captcha

Moin! 🌻

Wir haben in den letzten Monaten wahnsinnig viel über KI-Scraper gesprochen, die unsere Inhalte fressen, und darüber, wie wir sie mit der ai.txt und der robots.txt in die Schranken weisen. Aber was passiert, wenn wir gar nicht blockieren wollen? Was passiert, wenn wir wollen, dass ein autonomer Agent auf unser System zugreift, weil er im Namen eines Kunden einen fetten Deal abschließen möchte?

Das Internet hat ein massives Paradoxon erschaffen: Wir bauen millionenschwere KI-Agenten, die die klügsten Schachzüge berechnen können – aber sie scheitern kläglich an einem “Klicke alle Bilder mit Ampeln an”-Captcha. Die gesamte Security-Architektur des Web2 wurde darauf gedrillt, Bots auszusperren. Das war richtig, als Bots nur Spam schleuderten. Es ist geschäftsschädigend im Web3 und der Ära der Agenten-Ökonomie.

Hier betritt die auth.md die Bühne. Eingeführt und massiv vorangetrieben (unter anderem durch WorkOS im Mai 2026), ist diese unscheinbare Markdown-Datei das fehlende Puzzleteil, das den “Human-in-the-Loop” endgültig aus den B2B-Prozessen eliminiert.

Lass uns Tacheles reden: Wenn dein Vertrieb heute noch verlangt, dass jemand ein 12-seitiges PDF ausfüllt, unterschreibt und einscannt, bevor er bei dir einkaufen darf, bist du ohnehin schon tot. Aber wenn dein System verlangt, dass der KI-Einkäufer eines Konzerns ein Captcha lösen muss, hast du den Paradigmenwechsel des Jahrzehnts verschlafen.

Der Kampf gegen die Captcha-Hölle

Um zu verstehen, warum die auth.md so genial ist, müssen wir uns den Ist-Zustand ansehen. Stell dir vor, der Einkaufs-Agent von Siemens sucht nach neuen Lieferanten für Server-Hardware. Er findet deine Seite. Er analysiert dein Angebot über deine llms.txt und beschließt: “Das ist der perfekte Match, ich lege jetzt einen Account an und ordere ein Kontingent.”

Der Agent navigiert zu /register. Was passiert?

1. Ein nerviges Cookie-Banner blockiert das DOM.
2. Ein unsichtbares reCAPTCHA stuft den Traffic als “verdächtig” ein.
3. Der Form-Submit-Button verlangt eine Double-Opt-In-Email, die an eine Inbox geschickt wird, auf die der Agent gar keinen Zugriff hat.

Der Agent bricht ab und kauft bei deinem Konkurrenten.

Was genau tut die auth.md?

Die auth.md löst dieses Problem nicht, indem sie die Sicherheit senkt. Sie löst das Problem, indem sie eine zweite Vordertür (eine “Second Front Door”) in dein Unternehmen baut – exklusiv für maschinelle Entitäten.

Die Datei wird im Root deiner Domain abgelegt, zwingend unter https://deinedomain.de/.well-known/auth.md. Wenn der Siemens-Agent deine Seite anpingt, schaut er zuerst in die agent-card.json. Dort findet er den Hinweis: “Hey, wenn du mit mir Geschäfte machen willst, lies meine auth.md.”

In der auth.md steht im maschinenlesbaren Klartext (Markdown), wie die Spielregeln lauten:

• Wo sind die OAuth-Endpunkte? (z.B. der /.well-known/oauth-authorization-server)
• Welche Scopes werden benötigt? (z.B. “read:prices”, “write:orders”)
• Welche Authentifizierungs-Flows werden unterstützt?

Das ist kein proprietärer Wildwest-Pfusch. Die auth.md setzt sauber auf den etablierten IETF-Standards (RFCs) auf, erweitert sie aber um die KI-spezifische Navigation.

Der “Agent Verified” Flow (ID-JAGs) im Sommer 2026

Der wahre Durchbruch, der im Sommer 2026 die Branche erschüttert hat, ist der sogenannte “Agent Verified” Flow.

Früher dachte man immer, ein Mensch müsse am Ende den Knopf drücken, um einen Agenten zu legitimieren (der sogenannte “User Claimed” Flow). Aber das skaliert nicht. Wenn dein Agent tausend Lieferanten prüfen soll, kannst du als Mitarbeiter nicht tausend Bestätigungs-Mails anklicken.

Der “Agent Verified” Flow eliminiert den Menschen aus der Schleife durch pure Kryptografie. Das Konzept basiert auf den sogenannten ID-JAGs (Identity Assertion JWT).

Wenn der Siemens-Agent bei dir anklopft, präsentiert er einen kryptografisch signierten Token. Dieser Token sagt: “Ich bin der offiziell legitimierte Beschaffungs-Agent der Siemens AG, signiert vom Siemens-Trust-Center.” Dein Server prüft diese Ed25519-Signatur in Millisekunden. Passt alles? Bam! Account erstellt, API-Token ausgestellt, Bestellung freigegeben. Alles vollautonom.

Die auth.md ist der Ort, an dem du deklarierst: “Ich akzeptiere ID-JAGs von diesen Trust Centern, schick mir einfach deinen Token.”

Praxisbeispiel: Wie sieht das in der Realität aus?

Wir in der Teleschmiede setzen Agent Readiness auf Level 5 um. Level 5 bedeutet: Keine faulen Kompromisse, harte A2A-Compliance.

Wenn du wissen willst, wie wir das für uns selbst gelöst haben, schau dir unsere Datei an: https://teleschmie.de/.well-known/auth.md. Wichtig: Der Name der Datei muss strikt kleingeschrieben werden, und die allererste Zeile MUSS zwingend # auth.md lauten. Das sind die harten Parser-Regeln der Crawler.

So sieht ein exemplarischer Aufbau einer absolut standardkonformen Datei aus:

# auth.md

## Overview
This document specifies the authentication protocols required to interact with the Teleschmiede Agent Infrastructure. We support autonomous "Agent Verified" flows for B2B interactions.

## Supported Flows

### 1. Agent Verified (ID-JAG)
We highly recommend the Agent Verified flow for autonomous task execution.
- **Assertion Format:** Identity Assertion JWT (ID-JAG)
- **Supported Signatures:** Ed25519
- **Endpoint:** `https://teleschmie.de/api/auth/agent-verify`
- **Required Scopes:** `a2a:discovery`, `task:execute`

### 2. Traditional API Keys (Legacy)
For legacy tools that do not support dynamic ID-JAGs, static API keys are available.
- **Registration URL:** `https://teleschmie.de/developer/register` (Requires Human-in-the-Loop)
- **Header:** `Authorization: Bearer <token>`

## OAuth Metadata
Our standard OAuth 2.0 Authorization Server metadata can be found at:
`/.well-known/oauth-authorization-server`

Der geniale Clou daran: Ein KI-Crawler, der diese Datei liest, muss keine Webseiten parsen, keine Checkboxen (“Ich habe die AGB gelesen”) suchen und keine versteckten Formularfelder ausfüllen. Er schickt einfach seinen signierten Token an /api/auth/agent-verify und ist im Geschäft.

Wie prüfst du deine eigene Infrastruktur?

Viele CTOs wiegen sich in falscher Sicherheit, weil sie “ja eine super moderne REST-API” haben. Aber eine REST-API bringt dir gar nichts, wenn der KI-Agent deines Neukunden nicht weiß, wie er vollautomatisiert und ohne Klickstrecken an den API-Key herankommt.

Mach den Selbsttest. Wenn du deine Architektur für das Jahr 2026 härten willst, nutze diesen Audit-Prompt.

Der universelle Audit-Prompt für KI-Agenten

Diesen Prompt kannst du in jedes beliebige LLM (wie Claude oder GPT) werfen. Er ist darauf ausgelegt, die Schwachstellen deiner aktuellen Authentifizierungs-Infrastruktur schonungslos aufzudecken.

Prompt für deinen KI-Agenten:

Führe eine tiefgreifende 'Agent Readiness'-Prüfung für das Thema Authentifizierung auf meiner Domain durch. Analysiere, ob eine gültige `auth.md` im `.well-known` Verzeichnis vorliegt. 
- Falls nein: Identifiziere in meiner aktuellen Infrastruktur die größten 'Human-in-the-Loop'-Engpässe, die verhindern, dass ein autonomer B2B-Agent eigenständig einen Account anlegt und auf meine APIs zugreift.
- Erstelle mir auf Basis der Standards vom Juli 2026 (inkl. Fokus auf 'Agent Verified' Flows und ID-JAG) einen vollständigen Architekturentwurf und eine fertige `auth.md`, die zeigt, wie ich eine maschinenlesbare 'zweite Vordertür' für externe KI-Agenten aufbaue.

Wenn du den B2B-Markt in den nächsten Jahren dominieren willst, musst du aufhören, Maschinen wie lästige Spammer zu behandeln. Rollt den KIs den roten Teppich aus. Wer autonomen Agenten den einfachsten Registrierungs-Flow bietet, gewinnt den Deal. So einfach ist das.

ALOHA! 🌻✌️