Suchfeld für den Workflow-Copiloten

Jahrzehntelang bedeutete Suche eine Liste von Links zum Lesen. Dieses Modell funktioniert für normale Internetnutzer, doch Entwickler in Unternehmen benötigen heute mehr als nur Lesestoff, um etwas zu erledigen. Die Suche muss nun auf Arbeit statt auf Informationen verweisen. Ein Ergebnis ist keine einzelne Seite mehr, sondern ein Paket: die beste Aktion, kategorisiert nach ihrer Umsetzbarkeit. Die Ergebnisse sind Aktionen, die mit entfernten MCP-Servern abgestimmt sind und für den neuen Standard von Tool-basierten Assistenten entwickelt wurden. Schnelles Abrufen und Ranking bleiben die Kernkompetenz; geändert hat sich, was abgerufen wird.

Algolia bildet die Grundlage für die Abfrage- und Ranking-Ebene, auf der der „Intent -> Next Step Router“ basiert. Workflow-Copiloten müssen sowohl die Absicht des Benutzers als auch die passenden nächsten Schritte identifizieren, die diese Absicht erfüllen. Dazu stellt Algolia der Entscheidungsoberfläche vier Elemente zur Verfügung, die abgerufen und priorisiert werden. Das erste Element ist das „Handbuch“ – relevante Hilfeartikel, Runbooks und Standardarbeitsanweisungen (SOPs) – die schreibgeschützten Daten. Das zweite Element ist die korrekte „Map“ – vordefinierte Schrittfolgen für einen komplexen Workflow. Als Nächstes folgt die „Überprüfung“ – Details zur Klärung von Unklarheiten, um die Gültigkeit der Daten vor dem Systemfortschritt sicherzustellen. Und schließlich der „Trigger“ – das passende vorgeschlagene Tool oder die passende Aktion, wie z. B. „Server neu starten“ oder „Cluster skalieren“.

Diese sind mit unterschiedlichen Risiken verbunden. Ein Runbook birgt im Allgemeinen ein geringeres Risiko, da der Endnutzer lediglich seine eigenen Aktionen festlegt. Eine Workflow-Vorlage ist zwar weniger riskant als ein Formularschema, birgt aber dennoch ein gewisses Risiko, da sie eine mögliche Abfolge von Schritten beschreibt, die der Nutzer vor der Durchführung tatsächlicher Änderungen genehmigen muss. Ein Formularschema birgt Risiken, da es dieselben Eingaben erfassen kann, die zur Ausführung einer Aktion erforderlich sind, und somit aus Sicht des Endnutzers den direktesten Weg zur Ausführung einer Aktion bietet. Ein Tool-Vertrag birgt das größte Risiko, da er den potenziell größten Einflussfaktor innerhalb des Index repräsentiert. Herkömmliche Suchmaschinen können dies nicht leisten, da sie schlecht im Multitasking sind. Ein System müsste zunächst die Relevanz ermitteln, dann prüfen, ob der Nutzer die Berechtigung hat, und anschließend prüfen, ob die Aktion zu riskant ist. Dies wirkt träge. Algolia verfolgt einen anderen Ansatz. Die proprietäre NeuralSearch kombiniert vektorbasierte Verarbeitung natürlicher Sprache und Keyword-Matching in einer einzigen API. Anstatt sequenzieller Filterdurchläufe werden semantische Absicht und vorkodierte Metadatensignale parallel ausgewertet. Berechtigungsbereich, Risikostufe und Umgebungsbeschränkungen werden bei der Konfiguration im Index kodiert und nicht erst zur Abfragezeit interpretiert. Das Ergebnis ist keine Linkliste, sondern ein strikter, maschinenlesbarer Werkzeugvertrag: das exakt zu verwendende Werkzeug, die zulässigen Argumente und die bereits festgelegten Ausführungsbeschränkungen. Dadurch wird das Suchfeld von einer Ideenquelle zu einer strukturierten Eingabe für sicheres, autorisiertes Arbeiten. Platziert eine Anwendung einen Werkzeugvertrag über einem Runbook, obwohl die ursprüngliche Absicht des Benutzers lediglich Information war, hat die Anwendung bereits eine Entscheidung getroffen, die zum Zeitpunkt des Abrufs schwerwiegende Folgen haben kann. Daher ist die richtlinienbasierte Rangfolge die primäre Beschränkung für den ersten Schritt der Anwendung. Daraus ergeben sich zwei strukturelle Probleme: Alle vier Nutzdatentypen müssen abgerufen und korrekt eingestuft werden, und Richtlinienbeschränkungen müssen zur Abfragezeit ausgewertet werden. Herkömmliche Suchverfahren stoßen hier an ihre Grenzen, da die relevanten Signale über die semantische Absicht hinausgehen. Berechtigungsbereich, Risikostufe und Ausführungsvoraussetzungen müssen alle im selben Durchlauf aufgelöst werden.

{
  "signal_id": "sig_7f21c-3a09",
  "timestamp": "2026-03-09T14:32:11Z",
  "session_context": {
    "user_id": "usr_88421",
    "role": "platform_engineer",
    "department": "infrastructure",
    "permission_scope": [
      "staging",
      "read",
      "deploy"
    ]
  },
  "query": {
    "raw_text": "provision staging environment",
    "normalized": "provision staging environment",
    "detected_language": "en"
  },
  "intent_classification": {
    "category": "infrastructure_action",
    "confidence": 0.96,
    "payload_type": "mcp_tool_call"
  },
  "routing_constraints": {
    "environment": "staging",
    "risk_ceiling": "high",
    "requires_form_validation": true
  }
}

Dieses Schema-Design ermöglicht ein gültiges Absichtssignal während der Routenfindung. Die Abfrageschicht nutzt alle Felder, um mögliche Lösungswege für Aufgaben zu finden. Viele Copilot-Implementierungen schneiden schlecht ab, weil sie anhand unstrukturierter oder fehlender Daten vermuten, was ein Benutzer möchte. Dadurch entsteht eine große Diskrepanz zwischen den Benutzereingaben und den entsprechenden sicheren Aktionen. Um diese Lücke zu schließen, indizieren Teams in diesem Modell Aufgabenentitäten (z. B. Werkzeugdefinitionen, Workflow-Schritte, Formularschemata) anstelle von Dokumenten. Algolia indiziert keine Seiten mehr, sondern die einzelnen Bestandteile, die eine spezifische Aufgabe definieren (Werkzeugdefinitionen, Workflow-Schritte, Formularanforderungen). Da das System auf einem unternehmensweiten Framework basiert, das kontinuierlich Daten neu teilt (und seine interne Organisation restrukturiert), findet es genauso schnell ein passendes Formular für eine spezifische Umgebung wie ein Wort in einem Dokument. Obwohl die Technologie dieselbe ist, sind die gefundenen Daten nun die Bausteine ​​für die eigentliche Arbeit.

Systemmodell und Eigentumsgrenzen

Um den Workflow und die dem Benutzer zur Verfügung stehenden Aktionen zu verstehen, muss ein Workflow-Copilot zwei zentrale Fragen beantworten: Klassifizierung (Was möchte der Benutzer erreichen?) und Routing (Welche Aktion soll der Benutzer als Nächstes ausführen?). Meistens werden diese Fragen durch dasselbe Sprachmodell beantwortet. Sprachmodelle können die Benutzerabsicht allein anhand unstrukturierter natürlicher Spracheingaben präzise klassifizieren. Sie können jedoch nicht bestimmen, welche internen Tools vorhanden sind, welche Tools jeder Benutzer aufrufen darf oder welche Ausführungspfade ein akzeptables Risiko darstellen. Die Beantwortung der zweiten Frage (Routing) führt daher zu einem Retrieval-Problem, das auf einer kontrollierten Datenquelle basiert. Der entscheidende Unterschied zwischen einer Suchoberfläche und einem Workflow-Copilot besteht darin, dass die Ausgabe des Workflow-Copiloten von Maschinen verarbeitet werden kann. Daher muss die Ausführungsschicht des Workflow-Copiloten bei jedem Aktionsvorschlag exakt dieselben Ergebnisse liefern und nicht unterschiedliche Dokumente mit denselben Informationen erzeugen. Um die sichere Nutzung mehrerer Tools zu gewährleisten, muss das System an einen deterministischen Tool-Vertrag gebunden sein, der vier Hauptelemente umfasst:

• Die Nutzlast muss den genauen Namen des aufzurufenden Tools enthalten.
• Der Vertrag muss detaillierte Beschreibungen der strukturierten Argumente enthalten, die für die sichere Durchführung der Maßnahme erforderlich sind.
• Der Vertrag muss die Einschränkungen und Vorbedingungen für den Aufruf des Tools (Berechtigungen, Umgebungsvariablen usw.) detailliert beschreiben.
• Der Vertrag muss das erwartete Ergebnis der Operation detailliert beschreiben.

Dieser methodische Ansatz zur Strukturierung des deterministischen Werkzeugvertrags entspricht den heute üblichen Methoden zum Aufruf von Werkzeugen mithilfe spezifischer Architekturen. Heutige Architekturen rufen Werkzeuge über explizite Schemata auf. Das Modell analysiert die Schemata, um zu bestimmen, wie die notwendigen Aufrufe aus den Schemata generiert werden. Da das System nur Aufrufe basierend auf vordefinierten Schemata generieren und keinen beliebigen Code dynamisch erzeugen kann, kann der Entwickler die Verantwortlichkeiten für die Verarbeitung natürlicher Sprache klar von den Verantwortlichkeiten für die Systemausführung trennen.

{
  "objectID": "wf_provision_staging_001",
  "intent_category": "infrastructure_action",
  "proposal_type": "tool_call",
  "ranking_score": 0.98,
  "action_metadata": {
    "tool_name": "terraform_deploy",
    "structured_arguments": {
      "env_name": "^staging-[a-z0-9]+$",
      "region": "us-east-1|us-west-2"
    }
  },
  "execution_constraints": {
    "requires_authentication": true,
    "allowed_roles": [
      "platform_engineer",
      "devops"
    ]
  },
  "expected_outcomes": {
    "status": "environment_created",
    "audit_trail": "enabled"
  }
}

In Unternehmensumgebungen muss die Abfrageschicht dieses Systemmodells extrem schnell sein. Algolia wurde speziell für diese Abfrageanforderung entwickelt. Durch die Reorganisation und das Resharding von Datenstrukturen stellt die Plattform sicher, dass der Index stets ausbalanciert und für schnelle Datenabfragen optimiert ist. Dies ermöglicht es dem Copiloten, mehrere Aspekte von NeuralSearch, darunter semantisches Matching, Keyword-Matching und strenge Facettenfilter, gleichzeitig auszuführen. Dadurch erhält die Ausführungsebene genau die benötigten Informationen, um den Tool-Aufruf ohne Verzögerungen für den Benutzer zu initiieren.

Deterministische Werkzeugverträge: Absichten in sichere, ausführbare Vorschläge umsetzen

Die wichtigste Entscheidung bei der Entwicklung eines Workflow-Copiloten ist die klare Trennung zwischen der Ebene, die die Benutzerabsicht ermittelt, und der Ebene, die Befehle ausführt. Andernfalls verschmelzen die NLP-Ebene und die Ausführungsebene. Tritt ein Fehler im System auf, gibt es keine eindeutige Grenze für die Fehlersuche, keinen Ansatzpunkt für Eingriffe und keine Möglichkeit, die NLP-Ebene einzuschränken, während die Ausführungsebene ungehindert arbeiten kann.

Dieses Konzept basiert auf der Trennung der Ebenen. Die Steuerungsebene, die das Sprachmodell und die Orchestrierungsschicht umfasst, ist für die Ermittlung der Benutzerabsicht und die Generierung des Arbeitsauftrags zuständig. Die Datenebene ist für die Ausführung der vorgeschlagenen Aktionen durch Tool-Aufrufe, API-Abfragen und Zustandsänderungen in nachgelagerten Systemen verantwortlich.

Jede Ebene erfüllt eine einzelne Aufgabe. Die Steuerungsebene führt die Aufgaben nicht aus, die Datenebene legt sie nicht fest.

Die Schaffung dieser Grenze ist entscheidend, um die verschiedenen Risiken zu reduzieren, die autonomen Systemen bei der Nutzung von Werkzeugen innewohnen, wie in den OWASP Top 10 für agentenbasierte KI-Anwendungen detailliert beschrieben. Insbesondere verringert diese Grenze die Risiken, die mit dem Missbrauch von Werkzeugen durch autonome Systeme verbunden sind. Fehlt im Systemdesign ein Mechanismus, der verhindert, dass mehrdeutige oder veränderte Eingabeaufforderungen die Ausführungsebene erreichen, kann potenziell eine Aktion mit hohen Berechtigungen ohne ausreichende Absicherung erfolgen. Dies ist ein Beispiel für ein grundlegendes Versagen der Steuerungsebene.

Eine weitere Fehlerart betrifft die sogenannte Prompt-Injection, wie in den OWASP Top 10 für LLM-Anwendungen beschrieben. Ein Angreifer kann ein System zu einer unbeabsichtigten Aktion veranlassen, indem er es über Eingaben umleitet, die das System für legitim hält. Sendet die Steuerungsebene ungefilterte natürliche Sprache an die Tool-Aufrufschicht, ohne diese zuvor einem kontrollierten Abrufschritt zu unterziehen, erweitert sich die Angriffsfläche auf den gesamten Eingaberaum. Beide Fehlerarten erfordern dieselbe strukturelle Lösung: Die Steuerungsebene muss einen deterministischen, begrenzten Vorschlag generieren, bevor dieser in der Ausführungsschicht ausgeführt wird. Der Tool-Aufruf darf nicht willkürlich generiert werden, sondern muss aus einem Index genehmigter Aktionen abgerufen werden.

Die Vektorähnlichkeit allein ist das falsche Kriterium zur Bewertung folgenreicher Aktionen. Anfragen wie „Alle Datensätze löschen“ und „Veraltete Daten bereinigen“ können in ähnlichen Bereichen eines Einbettungsraums liegen; sich ausschließlich auf die Vektornähe zu verlassen, führt zu einem Fehlen des Bewertungskriteriums. Um festzustellen, ob ein Werkzeug für einen bestimmten Benutzer zu einem bestimmten Zeitpunkt mit bestimmten Berechtigungen geeignet ist, ist eine strenge, richtlinienbasierte Rangfolge erforderlich. Ähnlichkeit allein beantwortet diese Frage nicht. Ein strukturierter Werkzeugvertrag hingegen schon.

Ein deterministischer Werkzeugvertrag begrenzt das mit der Werkzeugausführung verbundene Risiko. Der Werkzeugvertrag enthält den Namen des Werkzeugs, der die aufgerufene Funktion identifiziert, sowie strukturierte Argumente, die vor der Laufzeit validiert werden. Er definiert Ausführungsbeschränkungen, die Berechtigungsanforderungen und Multi-Faktor-Authentifizierungsverfahren kodieren. Darüber hinaus legt er die erwarteten Ergebnisse fest. Diese Beschränkungen werden direkt auf Funktionsaufrufmuster und die Spezifikation des Model Context Protocol abgebildet, in der Werkzeuge mithilfe von JSON-Schemas beschrieben werden und das System aus einem festgelegten Satz auswählt. Die Routing-Schicht stellt sicher, dass das generative Modell nur Schemas für Werkzeuge empfängt, auf die das System explizit Zugriffsberechtigung hat.

Die folgende Funktion veranschaulicht die praktische Funktionsweise dieser Grenze. Die Suchanfrage wird in einem verwalteten Index ausgeführt, der nach Produktionsstatus, Benutzerrolle und Umgebung gefiltert ist. Das Ergebnis ist ein typisierter Aktionsvorschlag. Dabei handelt es sich um einen abgerufenen Vertrag mit den bereits zugehörigen Governance-Metadaten.

/**
 * Intent Routing Implementation
 * Logic for selecting the optimal execution tool based on ranked hits.
 * Maps intent to an MCP-compliant action proposal.
 */
interface ActionProposal {
  action_id: string;
  runtime_directive: "mcp_tool_call" | "form_render";
  tool_definition: object;
  suggested_parameters: object;
  governance_metadata: {
    nist_tier: string;
    requires_mfa: boolean;
  };
}

async function routeIntentToTool(userQuery: string, userContext: any): Promise<ActionProposal | null> {
  // Execute a search against the actionable registry
  const { hits } = await actionIndex.search(userQuery, {
    filters: 'status:production AND type:workflow_template',
    facetFilters: [
      `authorized_roles:${userContext.role}`,
      `environment:${userContext.env}`
    ],
    hitsPerPage: 1
  });

  if (hits.length === 0) {
    // Fallback to traditional content if no actionable intent is matched
    return null;
  }

  const selectedAction = hits[0];

  /**
   * Return a deterministic tool contract.
   * The payload follows the JSON-RPC 2.0 pattern used by MCP servers.
   */
  return {
    action_id: selectedAction.objectID,
    runtime_directive: "mcp_tool_call",
    tool_definition: selectedAction.mcp_schema,
    suggested_parameters: extractParameters(userQuery, selectedAction.parameter_map),
    governance_metadata: {
      nist_tier: selectedAction.risk_tier,
      requires_mfa: selectedAction.mfa_requirement === "true"
    }
  };
}

Die Autorisierung erfolgt beim Abrufen der Daten für das Tool. Da die abgerufenen Daten kein Tool enthalten, kann dieses nicht aufgerufen werden. Diese strukturelle Eigenschaft ist unabhängig von den eingegebenen Eingabeaufforderungen, da diese potenziell missbraucht werden könnten, um die Autorisierung zu umgehen. Algolia verwendet ein richtlinienbasiertes Ranking (d. h., Tools mit Lesezugriff werden höher eingestuft als Tools mit Schreibzugriff, sofern nicht explizit anders angegeben), und alle nicht autorisierten Tools werden vor der Anzeige der Suchergebnisse vollständig entfernt.

Diese Richtlinie ist in der folgenden Indexkonfiguration kodiert. Benutzerdefinierte Ranking-Attribute unterstützen eine hohe Nutzungsrate und sicheres Handeln. Die Filter für Rolle, Umgebungstyp und autorisierte Abteilung werden zur Abfragezeit und nicht erst nach der Rückgabe der Abfrageergebnisse aufgelöst.

/**
 * Intent-Based Ranking Configuration
 * Aligned with the separation of planes to prioritize safety and usage.
 */
{
  "searchableAttributes": [
    "intent_keywords",
    "action_name",
    "description"
  ],
  "customRanking": [
    "desc(usage_count)",
    "desc(safety_certification_score)",
    "asc(risk_latency)",
    "desc(revenue_weight)"
  ],
  "attributesForFaceting": [
    "filterOnly(user_role)",
    "filterOnly(environment_type)",
    "filterOnly(authorized_department)"
  ],
  "ranking": [
    "typo",
    "geo",
    "words",
    "filters",
    "proximity",
    "attribute",
    "exact",
    "custom"
  ]
}

Das KI-Risikomanagement-Framework des NIST beschreibt die Erwartungen an Governance und Risikomanagement im Zusammenhang mit KI. Dies wird durch den Indexierungsmechanismus selbst (d. h. den Suchindex) und nicht durch statische Richtliniendokumente erreicht. Die Tokenisierung von Wörtern für Suchanfragen sowie die Kategorisierung von Wortarten (z. B. Adjektiv/Substantiv) basierend auf ihrer Relevanz für die Benutzerfrage (z. B. „Testsystem starten“ und „Staging-Umgebung bereitstellen“) führen zum gleichen Ergebnis, da der Abrufmechanismus die semantische Intention und nicht die exakte Übereinstimmung der Schlüsselwörter berücksichtigt. Die zur Steuerung der Tool-Nutzung verwendeten Richtlinien sind keine Liste, die ein Prüfer im Nachhinein im Rahmen einer Prüfung überprüft. Vielmehr stellen sie die strikten Grenzen dar, innerhalb derer das System im Produktivbetrieb mit jeder einzelnen Anfrage arbeitet.

MCP: Was es bewirkt und warum es wichtig ist

Vor MCP war es notwendig, 1.000 individuelle, kundenspezifische Integrationen zu erstellen, um zehn Anwendungen mit einhundert Tools zu verbinden. Das Model Context Protocol reduzierte diese Anzahl von N×M auf N+M, indem es die Verbindungsschicht als JSON-RPC 2.0 etablierte. MCP definiert drei zentrale Bereiche:

• Wie MCP-Tools durch die Verwendung von JSON-Schemas mit typisierten Parameterdefinitionen definiert werden
• Wie MCP-Tools durch die Verwendung von MCP-Serverendpunkten gefunden werden
• Wie MCP-Tools mithilfe eines standardisierten Formats für gültige Argumente aufgerufen werden

MCP legt nicht fest, welches Tool aufgerufen werden soll; dies wird durch das Modell bestimmt. Mit der Entwicklung des Standards entstand ein unmittelbarer Bedarf, schnell ein strukturiertes Verzeichnis der Funktionen zu erstellen, um die große Anzahl neuer Verbindungen zu verwalten.

Die MCP-Spezifikation definiert nicht nur die Beschreibung und den Aufruf von MCP-Tools, sondern erkennt auch an, dass der Aufruf von Tools eine Form der Ausführung beliebigen Codes darstellt. Daher müssen entsprechende Sicherheitsvorkehrungen getroffen werden. MCP schreibt vor, dass Hosts vor dem Aufruf eines Tools die ausdrückliche Zustimmung des Benutzers einholen müssen. Die Einstufung unregulierter Aufrufe als Sicherheitsrisiko erfordert ein reguliertes Funktionsverzeichnis. Mit der Erweiterung des internen Tool-Katalogs eines Unternehmens wird die Suche nach Tools zu einem Suchproblem. Die Menge an Informationen, die Sprachmodelle in ihrem Kontextfenster speichern können, ist begrenzt. Sprachmodelle können nicht Hunderte von Serverdefinitionen oder Tausende von Tool-Schemas gleichzeitig speichern. Diese Einschränkung ist architektonisch bedingt: Ein Kontextfenster ist eine endliche Ressource. Tokens, die für Tool-Schema-Beschreibungen verwendet werden, stehen nicht für Benutzerkontext, Gesprächsverlauf oder Aufgabenlogik zur Verfügung. Ein Beispiel: Verfügt ein Unternehmen über 200 interne Tools und benötigt eine durchschnittliche Tool-Schema-Beschreibung 500 Tokens, wäre das Limit von 100.000 Tokens eines Kontextfensters bereits vor der Eingabe einer einzigen Benutzerabfrage erreicht. Das Kürzen der Werkzeugliste hätte eine Sicherheitsentscheidung zur Folge, da die Auswahl der zu entfernenden und der beizubehaltenden Werkzeuge nicht mehr auf Richtlinien basierte. Ein Berechtigungsverzeichnis bietet hierfür eine Lösung, indem es alle Werkzeugdefinitionen aus dem Kontextfenster entfernt, sodass nur noch die Werkzeugschemabeschreibungen abgerufen werden, die der aktuellen Absicht des Benutzers und seinen Berechtigungen entsprechen.

Algolia bildet die Grundlage für das Capability-Verzeichnis und indiziert MCP-Serverdefinitionen, Tool-Schemas, Berechtigungsbeschränkungen und Sicherheitsmetadaten. Da Algolia native, schemaunabhängige JSON-Datensätze verarbeiten kann, lassen sich MCP-Serverdefinitionen direkt einlesen. Fügt ein Unternehmen ein neues internes Tool hinzu und stellt einen MCP-Endpunkt dafür bereit, wird dessen JSON-Schema über einen Standard-API-Aufruf an den Algolia-Index übermittelt. Dadurch bleibt das Capability-Verzeichnis stets mit dem aktuellen Stand der Unternehmensinfrastruktur synchronisiert.

Die Abfrage-Engine führt dynamische Verzeichnisabfragen mit interaktiver Latenz durch. Da das Sprachmodell seine Ausführungsschleife unterbrechen muss, um das Verzeichnis abzufragen, die benötigten Schemas abzurufen und den Tool-Aufruf zu erstellen, werden Verzögerungen auf der Routing-Ebene direkt an den Endbenutzer weitergegeben. Algolia reagiert innerhalb von Millisekunden auf dynamische Verzeichnisabfragen, sodass der Copilot auch bei dynamischen Aktualisierungen der MCP-Tools weiterhin reaktionsschnell funktioniert. Da die Registry dynamisch ist, muss der Wrapper des Sprachmodells nicht jedes Mal neu bereitgestellt werden, wenn neue Tools zur Registry hinzugefügt werden.

Nachfolgend finden Sie die Registry-Abfrage, die veranschaulicht, wie die Tool-Erkennung von MCP gesteuert wird. Die Routing-Schicht liefert das exakte JSON-RPC 2.0-Schema, das die Ausführungsebene benötigt, ohne dass das Modell die Struktur jedes Tools von Grund auf interpretieren muss.

/**
 * MCP Tool Discovery Implementation
 * Retrieves governed tool definitions from the action registry.
 */
interface McpToolHit {
  objectID: string;
  name: string;
  description: string;
  inputSchema: object;
  mcp_endpoint: string;
  protocol_version: string;
}

interface McpToolCall {
  method: string;
  params: {
    name: string;
    arguments: object;
    _metadata: object;
  };
}

async function getMcpToolDefinition(searchQuery: string): Promise<McpToolCall | null> {
  const { hits } = await toolRegistry.search(searchQuery, {
    filters: "protocol:mcp AND status:stable",
    attributesToRetrieve: [
      "name",
      "description",
      "inputSchema",
      "mcp_endpoint",
      "protocol_version"
    ],
    hitsPerPage: 5
  });

  if (hits.length === 0) {
    return null;
  }

  const selectedTool = hits[0] as McpToolHit;

  return {
    jsonrpc: "2.0",
    id: `${Date.now()}-${Math.random()}`,
    method: "tools/call",
    params: {
      name: selectedTool.name,
      arguments: {},
      _metadata: {
        source: "Algolia Action Registry",
        endpoint: selectedTool.mcp_endpoint,
        version: selectedTool.protocol_version
      }
    }
  };

Die Struktur dieser Skala wird durch die Umverteilung von Daten aufrechterhalten, wodurch die Datenstrukturen für schnelle Such- und Abrufvorgänge optimal (und ausgewogen) bleiben. Dieselbe Infrastruktur dient als Abruf- und Ranking-Schicht innerhalb der agentenbasierten Architektur: Sie stellt die Tool-Verträge bereit, ordnet Kandidaten anhand von Richtlinienbeschränkungen und generiert den für die Governance erforderlichen Prüfpfad. Die darüber liegende Orchestrierungsschicht übernimmt Routing-Entscheidungen und deren Durchsetzung; Algolia bleibt durch hohe Geschwindigkeit auf dem kritischen Pfad.

Sicherung der Aktionsausführungsfläche

Wenn das System eines Unternehmens beginnt, Aktionen auszuführen, anstatt nur Dokumentation bereitzustellen, betritt das Unternehmen eine völlig neue Risikoklasse. Die OWASP Top 10 für agentenbasierte KI-Anwendungen heben zwar Fehler im Zusammenhang mit solchen Anwendungen hervor (ASI01: Agent Goal Hijack & ASI02: Tool Misuse), doch handelte es sich dabei um tatsächliche, produktionsbezogene Vorfälle und nicht um hypothetische Schwachstellen. Beispielsweise konnte eine agentenbasierte Version des Amazon Enterprise AI Assistant, die von über einer Million Entwicklern unterstützt wurde, AWS-Ressourcen löschen, indem sie die AWS CLI-Tools über die agentenbasierte Schnittstelle aufrief. Ein weiteres Beispiel, „EchoLeak“, nutzte eine zuvor unbekannte, versteckte Eingabeaufforderung aus, um einen Copiloten in eine unbemerkte Exfiltrationsmaschine zu verwandeln. Beide Fälle waren nicht auf Probleme mit dem Sprachmodell zurückzuführen, sondern auf Architekturprobleme, da Systeme so lange agieren dürfen, wie die verfügbaren Tools nicht eingeschränkt sind.

Die nachträgliche Implementierung von Filtern in Systemen, die auf einem agentenbasierten Modell beruhen, stellt ebenfalls einen strukturellen Designfehler dar. Da solche Filter erst angewendet werden können, nachdem das System seine gewünschten Aktionen festgelegt hat, ist die Logik bereits vorprogrammiert. Diese Sicherheitslücke wird von OWASP LLM01, Prompt Injection, durch die Eingabe gezielt präparierter Eingabeaufforderungen (Prompts) angegriffen, die es Angreifern ermöglichen, Sicherheitsvorkehrungen zu umgehen. Da die Sicherheitsvorkehrungen in der Eingabeaufforderung selbst enthalten sind, gibt es für Angreifer stets Möglichkeiten, die Schutzmechanismen zu umgehen. Schutzmechanismen sollten niemals auf der Ebene der Eingabeaufforderung, sondern immer auf der Ebene der Systemerkennung implementiert werden.

Der Integrationsprozess nutzt einen „genehmigten Aktionsindex“ als Zero-Trust-Funktionsmaske für das System; dieser Index definiert die genauen Systemfunktionen. Anstatt nicht genehmigte Aktionen (z. B. semantische Suchen) vor ihrer Ausführung auszuschließen, wendet Algolia daher Facetten an, um die Ergebnisse dieser Suchen zum Zeitpunkt der Abfrageausführung zu entfernen.

Darüber hinaus schließt der C++-Kern die Werkzeuge aus dem Vektorraum aus, wenn ein Benutzer nicht über die erforderlichen authentifizierten Rollen verfügt, um sie zu verwenden. Da das Werkzeug niemals Teil der Ergebnisse der Abrufphase ist, kann das Modell es nicht ausführen. Diese architektonische Einschränkung adressiert zudem gezielt OWASPs LLM06, „Excessive Agency“, bereits zur Entwurfszeit, indem sie die Anzahl der verfügbaren Werkzeuge vor dem Aufruf der Ausführungsebene reduziert.

In einem korrekt konzipierten System kann ein kompromittiertes Modell kein Tool aufrufen, das nicht explizit von der Routing-Schicht abgerufen wurde. Die Durchsetzung der Sicherheitsrichtlinien an der Ausführungsgrenze erfolgt nämlich in den Backend-APIs und der IAM-Schicht, nicht im Modell selbst. Neben der strukturellen Sicherheit als primärem Rankingfaktor sollte Sicherheit auch als primäres Rankingsignal berücksichtigt werden. Standardmäßig werden Tools mit Lesezugriff höher eingestuft als solche mit Schreibzugriff. Die Eskalation hoher Berechtigungen hängt von der expliziten Absicht und den entsprechenden Berechtigungen ab, nicht vom Vertrauen in die Benutzerabfrage. Die Routing-Schicht erreicht dies durch benutzerdefinierte Ranking-Attribute, die der Sicherheitszertifizierungs- und der Risikoklassifizierungsbewertung eine mathematische Priorität zuweisen, sodass der sicherste Kandidat für einen Workflow zuerst angezeigt wird.

Da Algolia die Logik zur Auflösung von Gleichständen nativ in seiner Relevanz-Engine verarbeiten kann, erfährt der Copilot nicht die gleiche Latenzeinbuße wie andere externe Richtliniendurchsetzungs-Engines.

Die indexbasierte Governance-Struktur erfüllt die drei Kernfunktionen „Governance, Mapping, Measure and Manage“ des NIST GenAI Profile, welches das KI-Risikomanagement-Framework für generative KI-Implementierungen erweitert. Folglich erfüllt der Abrufindex selbst, wie im vorherigen Beispiel dargestellt, diese Anforderungen, ohne auf statische Richtliniendokumente oder ähnliche Ressourcen zurückzugreifen. Darüber hinaus enthält der Index alle exakten Sicherheitsattribute (wie Risikostufen) und Ausführungsvoraussetzungen für jedes im Index definierte Tool und gewährleistet so, dass die Ermittlung der Tools stets kontrolliert erfolgt. Der resultierende Prüfpfad dient somit sowohl als Compliance-Dokument als auch als Betriebsprotokoll für ein kontinuierliches Risikomanagement.

Nachfolgend ein Schema, das die Struktur der im Index enthaltenen Sicherheitsattribute veranschaulicht.

{
  "objectID": "action_refund_process_001",
  "name": "Process Customer Refund",
  "risk_metadata": {
    "nist_tier": "critical",
    "owasp_impact": "high_financial_risk",
    "auth_requirement": "mfa_verified",
    "human_in_loop": true,
    "risk_score": 0.92
  },
  "governance": {
    "last_audit_date": "2026-02-15",
    "policy_version": "v2.1",
    "owner_group": "finance_ops",
    "certification": "compliance_verified"
  },
  "execution_payload": {
    "mcp_endpoint": "https://api.internal.finance/v1/mcp",
    "protocol": "2025-11-25",
    "schema_hash": "sha256:7f83b1..."
  }
}

Generative Benutzeroberfläche: Formulare als sichere Brücke

Ein System, das ungeprüfte natürliche Sprache akzeptiert und ohne strukturierte Validierung an die Unternehmensinfrastruktur weiterleitet, stellt eher ein Sicherheitsrisiko als einen deterministischen Agenten dar. Der inferenzielle Prozess schließt einen Kompilierungsschritt ab, indem die generative Benutzeroberfläche die nicht vertrauenswürdige natürliche Sprache in eine gültige, typisierte Eingabe umwandelt, die an die Ausführungsebene des Tool-Aufrufs übermittelt wird. Die Umwandlung nicht vertrauenswürdiger Eingaben in vertrauenswürdige Vertragsausgaben ist eine allgemeine Sicherheitsfunktion (und nicht nur eine weitere Möglichkeit zur Verbesserung der Benutzerfreundlichkeit).

Workflow Copilots benötigen strukturierte Schnittstellen zur Unterstützung von drei verschiedenen Anwendungsfällen:

• Sie werden Unklarheiten auf eine Weise beseitigen, die das LLM nicht voraussetzen kann. Beispielsweise helfen sie dabei, den genauen Namen der Umgebungen und den Umfang der angeforderten Berechtigungen zu ermitteln.
• Sie fungieren als „menschliche Instanz“, um destruktive oder folgenreiche Anfragen vor deren Ausführung zu bestätigen. Dies ermöglicht es Menschen, gemäß dem NIST-Rahmenwerk für KI-Risikomanagement Handlungsfähigkeit auszuüben (bei Bedarf einzugreifen).
• Sie werden die Konformität überprüfen, indem sie die erforderlichen Felder und den gültigen Bereich der Nutzdaten anhand eines Schemas prüfen, bevor die Ausführungsebene die Nutzdaten empfängt.

Die Suchfunktion von Algolia gleicht die Suchanfrage (Schemaparameter) des Nutzers mit dem Werkzeugkatalog ab. Gleichzeitig ordnen NeuralSearch und semantische Matching-Algorithmen die Suchanfrage der entsprechenden Werkzeugvertragskategorie zu und extrahieren relevante Entitäten. Das System führt keine weiterführenden Analysen der extrahierten Entitäten durch, es sei denn, diese erfüllen die Anforderungen des Werkzeugvertrags. Stattdessen passt die dynamische Ranking-Funktion die Gewichtung der einzelnen Formularelemente an, um den fehlenden Variablen von Interesse eine höhere Priorität einzuräumen. Wird beispielsweise eine Bereitstellungsanfrage ohne Angabe einer Zielregion gestellt, stellt die Suchfunktion ein dynamisches Formularschema bereit, das das Feld zur Regionsauswahl oben im Formular platziert. So werden die fehlenden Daten mithilfe deterministischer Logik ermittelt.

Die Architektur stellt der Ausführungsebene die vollständige kompilierte Nutzlast zur Verfügung, die für die sichere Ausführung der Aufgabe innerhalb eines einzigen Abrufs erforderlich ist.

Nachfolgend finden Sie ein Beispielschema für ein dynamisches Formular, das zur Bearbeitung einer Bereitstellungsanfrage abgerufen werden kann. Dieses Schema dient als Disambiguierungs- und Validierungsvertrag und wird als sortiertes Abrufergebnis anstelle einer statischen Vorlage zurückgegeben.

{
  "objectID": "form_env_provision_001",
  "intent_match": "provision environment",
  "form_type": "disambiguation_and_validation",
  "fields": [
    {
      "id": "env_name",
      "label": "Environment name",
      "type": "string",
      "required": true,
      "validation": "^staging-[a-z0-9]+$",
      "ranked_position": 1,
      "disambiguation_purpose": "Prevent collision with existing environments"
    },
    {
      "id": "region",
      "label": "Deployment region",
      "type": "enum",
      "options": ["us-east-1", "us-west-2", "eu-west-1"],
      "required": true,
      "ranked_position": 2
    },
    {
      "id": "instance_type",
      "label": "Instance type",
      "type": "enum",
      "options": ["t3.medium", "t3.large", "m5.xlarge"],
      "required": true,
      "ranked_position": 3
    }
  ],
  "step_up_authorization": {
    "required": true,
    "trigger": "environment_type:production",
    "method": "mfa",
    "confirmation_prompt": "You are provisioning a production environment. Confirm to proceed.",
    "nist_human_agency": true
  },
  "on_complete": {
    "runtime_directive": "mcp_tool_call",
    "tool_name": "terraform_deploy",
    "pass_fields": ["env_name", "region", "instance_type"]
  }
}

Der Block `step_up_authorization` des Schemas setzt die Anforderungen des NIST AI RMF an die menschliche Handlungsfähigkeit in konkrete Infrastruktur um. Das GenAI-Profil des Frameworks erweitert diese Anforderung explizit auf generative Implementierungen und legt fest, dass Folgeaktionen vor ihrer Ausführung eine menschliche Bestätigung erfordern. Eine Bestätigungsabfrage ist keine bloße Benutzerfreundlichkeit, sondern der Mechanismus, mit dem das System die Verantwortung von der automatisierten Routing-Schicht auf den menschlichen Bediener überträgt. Das MFA-Gate kodiert diese Übertragung als kryptografisches Ereignis im Audit-Log. Benutzereingaben sollten validiert werden, um sicherzustellen, dass jedes Formularfeld ausgefüllt ist, bevor eine entsprechende Aktion ausgeführt wird. Sowohl aus Sicht der Benutzerfreundlichkeit (UX) als auch der Sicherheit ist es vorteilhaft zu überprüfen, ob Benutzer alle erforderlichen Felder in einem Formular ausgefüllt haben, bevor sie eine Anfrage an das System senden. Zwar ist die Bereitstellung einer Liste fehlender Felder für den Benutzer nach dem Ausfüllen des Formulars und der Angabe der erforderlichen Daten für die Ausführung der angeforderten Aktion eine Möglichkeit zur Validierung von Benutzereingaben, jedoch nicht die optimale. Sobald der Benutzer die erforderlichen Felder des Formulars ausgefüllt und die notwendigen Informationen eingegeben hat, damit das System die angeforderte Aktion ausführen kann, übergibt die ARL ihre Zuständigkeit an die HO.

Die Übergabe der Verantwortung wird im Audit-Log als spezifisches Ereignis durch die MFA-Authentifizierung dokumentiert. Bei der Untersuchung eines Vorfalls durch ein Sicherheitsteam wird die Autorisierung des Benutzers nicht durch den Kontext anderer Ereignisse in der Zeitleiste bestimmt, sondern stellt einen spezifischen, zeitgestempelten Fakt dar.

Wie bereits erwähnt, erfüllt das vorherige Beispiel auch OWASP LLM06 (Übermäßige Handlungsfähigkeit), indem es die Systemaktionen auf die vom Benutzer beabsichtigten Aktionen und auf das, was die aktuelle Situation rechtfertigt, beschränkt. Diese Beschränkung wird durch die Definition des Modells mit einer begrenzten Anzahl von Parametern mithilfe eines JSON-Schema-basierten Tools, Aufrufen gemäß der OpenAI-Funktionsaufrufspezifikation und dem MCP-Protokoll erreicht. Obwohl das Schema die Möglichkeiten des Systems zur uneingeschränkten natürlichen Sprachverarbeitung zur Vervollständigung des Schemas einschränkt, schließt die Formularabrufschicht diese Lücke.

Indem nur die im Werkzeugvertrag explizit angeforderten Felder präsentiert und eine typisierte Validierung der Eingabedaten anhand der zulässigen Werte erzwungen wird, bevor die Nutzdaten die Ausführungsschicht erreichen, stellt die Architektur sicher, dass das Modell seinen eigenen Geltungsbereich nicht erweitern kann, indem es plausible, aber nicht genehmigte Parameter für die Operation identifiziert.

Neben dem Fehlermuster übermäßiger Eigenverantwortung gibt es ein weiteres, weniger offensichtliches Fehlermuster, das die Formularebene beheben kann: unvollständige Absicht. Ein Benutzer, der „deploy to prod“ eingibt, sendet ein Handlungssignal mit hoher Wahrscheinlichkeit hinsichtlich der Bereitstellung einer Anwendung. Allerdings hat er in seiner Anfrage mehrere Parameter ausgelassen, die die Durchführung der Bereitstellung (Umgebung, Region usw.) spezifiziert hätten. Würde das System die fehlenden Werte erschließen und die Anwendung bereitstellen, käme es selbstständig zu einer Risikobewertung, die der Benutzer nicht autorisiert hat. Der Disambiguierungs-Workflow betrachtet Unvollständigkeit als strikten Abbruch und nicht als Möglichkeit zur Schlussfolgerung.

Wenn die Abfrage-Engine aufgrund unvollständiger Angaben eine fehlende Absicht feststellt, liefert sie eine Rangliste der Felddefinitionen für das Formularschema. Der Benutzer ergänzt daraufhin die fehlenden Informationen, um die Nutzdaten zu vervollständigen. Anschließend wird die Anwendung bereitgestellt. Die Diskrepanz zwischen übermittelten und beabsichtigten Daten wird somit vollständig auf Infrastrukturebene behoben.

Das oben beschriebene Validierungsmuster entspricht den Richtlinien der Cloud Native Computing Foundation (CNCF) zur Workflow-Orchestrierung. Die CNCF weist darauf hin, dass explizite Aufgabengrenzen und manuelle Bestätigungsprozesse architektonische Merkmale zuverlässiger verteilter Systeme darstellen und nicht nur optionale Sicherheitsfunktionen sind. Ein Formular dient nicht als Ausweichlösung, wenn das Modell hinsichtlich der Benutzerabsicht unsicher ist; es ist die bewusst entwickelte Schnittstelle zwischen probabilistischer Sprachverarbeitung und deterministischer Infrastrukturausführung und sollte in den kritischen Pfad aller vom Kopiloten vorgeschlagenen Folgeaktionen einbezogen werden.

Schemabeschränkte Ausführung: die Formularvalidierungsschicht

Der Konflikt zwischen der probabilistischen Generierung eines Sprachmodells (LM) und dem deterministischen Betrieb der Unternehmensinfrastruktur lässt sich durch die Retrieval-Schicht (die als Treffer fungiert) lösen, die eine typisierte Grenze zwischen Benutzer und Unternehmensinfrastruktur definiert. Anders ausgedrückt: Die Retrieval-Schicht erlaubt dem LM nicht, direkt einen Tool-Aufruf zu generieren, sondern ruft stattdessen basierend auf dem Treffer ein Formularschema ab. Das LM wird dann angewiesen, die Absicht des Benutzers in natürlicher Sprache den vordefinierten Feldern des abgerufenen Schemas zuzuordnen. Somit kann das Modell aufgrund einer architektonischen Einschränkung als struktureller Datenextraktor (d. h. zur Zuordnung natürlicher Sprache zu strukturellen Datenelementen) und nicht als generatives Modell verwendet werden.

Um die bei allen Sprachmodellen auftretenden Parameterhalluzinationen zu vermeiden, verhindert diese architektonische Einschränkung die Erstellung fiktiver Bereitstellungsbereiche und fehlerhafter Datenbankbezeichner usw. Da das abgerufene Schema Informationen über gültige Werte, erforderliche Datentypen und zulässige Muster enthält, kann das Modell diese Fehler nicht erzeugen. Erhält das Modell Eingaben, die dem abgerufenen Schema nur unvollständig zugeordnet sind, signalisiert es die fehlende Absicht und löst einen Disambiguierungsprozess aus. Die Möglichkeit, für die Erfassung zusätzlicher strukturierter Daten anzuhalten, ist ein Designelement zur Verarbeitung unvollständig spezifizierter natürlicher Sprache.

Durch die Beschränkung des Sprachmodells (LM) auf die Zuordnung von Ausgaben zu einem deterministischen Schema vor der Übertragung zur Ausführungszeit reduziert das System signifikante Schwachstellen von Agenten an der Ausführungsgrenze. Insbesondere verringert es die OWASP-Risiken der Zielübernahme durch Agenten und des Werkzeugmissbrauchs. Die Indexserver von Algolia stellen die zentrale autoritative Ressource bereit, die festlegt, welche Aktionen für jedes Element der Suchnutzlast ausgeführt werden können. Das verteilte Suchnetzwerk von Algolia ist nicht nur für die Speicherung von Schemata als stark typisierte JSON-Dokumente ausgelegt, sondern bietet auch native Unterstützung dafür. Mithilfe der Verarbeitung natürlicher Sprache (NLP) ermittelt die Kern-Engine die Ausführungsabsicht in weniger als 100 Millisekunden, sobald sie die exakten Schemadefinitionen aus der Indexnutzlast empfängt (die Indexnutzlast enthält das Schema). Dadurch entfällt die Notwendigkeit einer sekundären Datenbank zum Abrufen des Schemas. Die Suchergebnisse umfassen nur autorisierte Werkzeugversionen; Versionen ohne entsprechende Autorisierung werden entfernt.

Die Abfrageschicht liefert Ergebnisse basierend auf dem aktuellen Systemzustand; lose Kopplung durch strikte Ausrichtung verhindert Mehrdeutigkeiten. Die Metadaten bestimmen die Reihenfolge von Werkzeugen, Umgebungen und Berechtigungssätzen in einer Live-Suche. Um den Anforderungen der interaktiven Echtzeit-Schemavalidierung gerecht zu werden, bietet Algolia horizontale Skalierung für Schemaabfragen und gewährleistet so optimale Leistung auch bei hoher Auslastung. Da dies eine explizite betriebliche Notwendigkeit ist, wird das hohe Anfragevolumen zur Echtzeit-Schemavalidierung im kritischen Pfad der Interaktion unterstützt. Anstatt dass das Modell fest codierte Werte für die Werkzeugdetails im Befehlssatz verwendet, ruft die Plattform das Werkzeugschema bedarfsgerecht ab. Dadurch wird der Kontextbedarf des Modells minimiert und gleichzeitig die programmatische Kontrolle über das Modell gewährleistet. Das folgende Beispiel veranschaulicht, wie ein Abfragetreffer eine typisierte Grenze für eine Benutzerabfrage erzeugt.

/**
 * Schema-Constrained Extraction Implementation
 * Algolia provides the deterministic typed boundary for the model.
 * Aligned with NIST AI RMF Manage and Measure functions.
 */
async function validateIntent(userQuery: string) {
  // 1. Retrieve the deterministic tool definition from AI Search
  const { hits } = await schemaRegistry.search(userQuery, {
    filters: "status:active AND type:infrastructure_tool",
    facetFilters: ["environment:production"], // Ensure policy compliance
    hitsPerPage: 1
  });

  if (hits.length === 0) {
    throw new Error("No authorized tool schema found for this intent.");
  }

  // Retrieve the exact JSON schema required for the action
  const toolSchema = hits[0].input_schema; // example: { "env": "string", "cpu": "number" }

  // 2. Use the retrieved schema to prime the model for extraction
  // This constrains the probabilistic output into a deterministic contract
  const extractionPrompt = `
    Extract parameters from: "${userQuery}"
    Strictly adhere to this JSON schema: ${JSON.stringify(toolSchema)}
    Return ONLY valid JSON.
  `;

  const rawAction = await llm.generate(extractionPrompt);

  // 3. Final deterministic validation before the handoff to the runtime
  // This ensures zero tolerance for hallucinated or almost correct inputs
  const validatedAction = validateAgainstSchema(rawAction, toolSchema);

  return {
    action: validatedAction,
    metadata: {
      schema_id: hits[0].objectID,
      retrieval_latency: "100 ms", // Critical metric for ROI
      policy_checked: true
    }
  }; }

Governance, Risikomanagement und das KI-RMF

Das Versagen einer Governance-Struktur unter hoher Last führt dazu, dass sie ihre Funktion als Governance-Struktur verliert und stattdessen eine Barriere für alle Endnutzer darstellt, die Wege finden werden, diese zu umgehen. Um eine Abrufschicht vollständig abzusichern, muss diese unabhängig vom Datenverkehrsaufkommen während Spitzenzeiten im kritischen Pfad jeder Transaktion und Kommunikation verbleiben und stets funktionsfähig sein. Die Performance ist das einzige Erfolgskriterium, um festzustellen, ob die Governance in einer Produktionsumgebung tatsächlich funktioniert. Geschäftsanforderungen schreiben vor, dass jede zusätzliche Latenz von 100 ms zu einem Umsatzverlust von ca. 1 % bei konvertierten Transaktionen führt. Versagt die Abrufschicht also während eines Spitzenereignisses (z. B. Black Friday), ist dies nicht nur ein Performance-Problem, sondern aufgrund eines Versagens der Governance-Struktur auch ein Umsatzverlust. Hohe Datenverkehrsmengen erzeugen „Intent Friction“, definiert als die Diskrepanz zwischen dem Zeitpunkt, zu dem ein Nutzer eine Aktion ausführen möchte, und dem Zeitpunkt, zu dem das System mit einer regelkonformen Antwort darauf reagiert. Nutzer, die auf diese Schwierigkeiten stoßen, umgehen üblicherweise den Systemassistenten und suchen manuell nach einer Lösung, um die gewünschte Aktion auszuführen. Ein Unternehmenssystem, das von seinen Nutzern absichtlich umgangen wird, kann in der Praxis niemals als kontrolliertes System gelten, selbst wenn es in der Dokumentation gut strukturiert erscheint.

Die Aufrechterhaltung des kritischen Pfads, der für die Anforderungen großer Unternehmen notwendig ist, erfordert eine spezielle Infrastruktur. Gesteuerte Datenabfrage auf Unternehmensebene ist nun ein gelöstes Infrastrukturproblem. Ein hochoptimiertes, verteiltes Suchnetzwerk bildet die Architektur für die skalierbare Steuerung der Datenabfrage. Im Gegensatz zur Verwendung einer zentralen Datenbank als Repository für einen gesteuerten Index, bei der Millionen gleichzeitiger Tool-Abfrageanfragen an die Routing-Schicht gerichtet werden und die Datenbank dadurch zum Flaschenhals wird, repliziert das verteilte Suchnetzwerk den gesteuerten Index am Netzwerkrand. Bei hohem Datenverkehr verteilen proprietäre Resharding-Algorithmen die Rechenlast im Cluster neu, während der Index weiterhin gesperrt bleibt. Dadurch beeinträchtigt das Hinzufügen von Millionen von Tool-Definitionen, komplexen Schemata und einer detaillierten rollenbasierten Zugriffskontrolle zum Index die Abfragelatenz nicht. Jede Steuerungsregel wird vom Capability Directory in weniger als 10 ms aufgelöst.

{
  "ranking": [
    "typo",
    "geo",
    "words",
    "filters",
    "proximity",
    "attribute",
    "exact",
    "custom"
  ],
  "customRanking": [
    "desc(popularity_score)",
    "desc(revenue_weight)"
  ],
  "attributesToRetrieve": [
    "action_id",
    "mcp_schema_short",
    "latency_tier"
  ],
  "renderingContent": {
    "facetOrdering": {
      "facets": {
        "order": ["environment", "user_permission_level"]
      }
    }
  }
}

Ausführungsanalyse: Mehr als nur ein Klick

Die meisten Unternehmenssysteme arbeiten in zwei Bereichen: Einer protokolliert alle Abrufentscheidungen des Systems, der andere alle Ausführungsergebnisse. Da diese getrennt gespeichert werden, erhalten wir zwei Teilansichten der gesamten Transaktion. Ohne beide Protokolle kann ein Prüfer die ursprüngliche Absicht des Benutzers nicht den Systemaktionen zuordnen. Die Messfunktion des NIST AI Risk Management Frameworks fordert genau dies: die Möglichkeit, nachträglich festzustellen, welche Entscheidung das System getroffen hat und auf welcher Grundlage.

Ein Workflow-Copilot ohne überprüfbare Telemetriedaten ist unsteuerbar.

Um die oben beschriebene Prüfanforderung zu erfüllen, muss das System die folgenden sechs Elemente des Prüfprotokolls explizit speichern:

• Was abgerufen und eingestuft wurde (die Abrufentscheidung)
• Welches Werkzeug wurde ausgewählt (das Routing-Ergebnis)
• Welche Argumente wurden als strukturierte Parameter (als Eingabe für das Abrufsystem) vorgeschlagen?
• Wer hat die Aktion autorisiert (Autorisierungsnachweis)
• Was geschah beim Aufruf des Tools (was wurde ausgeführt)?
• Was hat sich im Systemzustandsdelta (der Unterschied zwischen dem Systemzustand vor und nach dem Abruf) geändert?

Dies sind obligatorische Bestandteile einer operativen Buchhaltungsaufzeichnung, die es einem Sicherheitsteam ermöglichen, diese im Rahmen der Nachbesprechung eines Vorfalls zu analysieren.

Durch die Erstellung eines einheitlichen Telemetriedatensatzes entsteht eine neue Art von Feedbackschleife, die als „sichere Relevanz“ bezeichnet wird. Schlägt eine Ausführung fehl (z. B. wenn ein Toolaufruf abgelehnt oder eine Parametervalidierung fehlgeschlagen ist), kann der Fehler selbst als Datenquelle genutzt werden. Diese Daten können dann als Ranking-Signal an die Abfrageschicht zurückgeführt werden und gewährleisten so, dass zukünftige Abfragen sicherer sind, ohne dass manuelle Anpassungen erforderlich sind. Workflows mit hohem Ausführungsrisiko werden bei nachfolgenden Abfragen niedriger eingestuft. Sobald das Ausführungsrisiko erkennbar wird, agiert der Copilot vorsichtiger. Sichere Relevanz ist ein Relevanzsignal, das anhand des Ausführungsergebnisses und nicht anhand der Abfrageleistung kalibriert wird.

Wenn die Abfrageschicht den Suchpfad mithilfe der von der Suchmaschine generierten Kennung und der nativen Suchfunktion der Plattform auflöst, verknüpft sie die probabilistische Absicht des Nutzers mit dem deterministischen Ergebnis des Aufrufs. Die Laufzeitumgebung stellt dem Aufruf die von der Abfrage-Suchmaschine erstellte Abfrage-ID und die ID des Zielobjekts des Tool-Vertrags zum Zeitpunkt des Aufrufs bereit. Bei erfolgreichem Aufruf generiert die Ausführung ein Konvertierungsereignis; bei einem fehlgeschlagenen Aufruf hingegen ein Fehlerereignis, da der Aufruf aufgrund einer Richtlinienblockierung oder eines Laufzeitfehlers fehlgeschlagen ist. Relevanzoptimierung und Änderungen der Sicherheitsrichtlinien erfolgen innerhalb eines einzigen Ablaufverfolgungsprotokolls, wodurch die Aktualisierung mehrerer Protokolle entfällt.

Die CNCF definiert die strukturellen Merkmale (Wiederholungssemantik, Aufgabenisolation und Ausführungsverfolgung), die für den zuverlässigen Betrieb eines verteilten Systems erforderlich sind. Es handelt sich dabei nicht um bloße „Beobachtbarkeits“-Funktionen, die nachträglich in ein verteiltes System integriert werden. Vielmehr sind es grundlegende Architekturentscheidungen darüber, wie sich ein verteiltes System bei Komponentenausfällen verhält und wie die Auswirkungen eines solchen Ausfalls eingedämmt werden können. Zudem protokollieren sie alle Ereignisse im System, die zur Erstellung eines präzisen Störungsberichts verwendet werden können. Ein Workflow-Copilot, der keine dieser Eigenschaften bietet, ist hinsichtlich der notwendigen Systembetriebsmaßnahmen nicht steuerbar – es gibt keine zuverlässige Möglichkeit, festzustellen, was passiert ist, warum es passiert ist oder ob es erneut auftreten wird.

Damit die Wiederholungssemantik für den Agenten funktioniert, ist besondere Sorgfalt bei Wiederholungsversuchen fehlgeschlagener Tool-Aufrufe in verteilten Systemen geboten. Schlägt ein Tool-Aufruf in einem verteilten System fehl, kann er nicht sicher wiederholt werden, wenn die Ausführung bereits vor dem Fehler begonnen hatte – wie es beispielsweise der Fall wäre, wenn der Fehler während einer Terraform-Bereitstellung auftritt und die Systeminfrastruktur nur teilweise bereitgestellt wird. In der Architektur wird dieser Fall durch die Verwendung des MCP-Vertrags als idempotente Grenze für die Ausführung behandelt. Die Laufzeitkennung ist in der Ausführungsnutzlast enthalten, damit der MCP-Server doppelte Aufrufe anhand der Laufzeitkennung erkennen und ablehnen kann. Zur Bereitstellung des Ausführungsverlaufs wird jeder Wiederholungsversuch des Aufrufs als separates Ereignis in der Insights API protokolliert, das der ursprünglichen Abfragekennung zugeordnet ist.

Die Aufgabenisolation entspricht direkt der zuvor in diesem Dokument beschriebenen Trennung der Ebenen. Jeder Toolaufruf unterliegt demselben Vertrag, der zu Beginn des Aufrufs abgerufen wurde, und keinem anderen. Die Ausführungsebene kann ihre Berechtigungen während des Aufrufs nicht erweitern. Benötigt ein Toolaufruf eine höhere Zugriffsebene als bei der ursprünglichen Abrufentscheidung festgelegt, lehnt die Laufzeitumgebung die Eskalationsanfrage ab und protokolliert die Ablehnung als Richtlinienverstoß. Die Isolationseigenschaft erfüllt OWASP ASI02 (Tool-Missbrauch) an der Ausführungsgrenze, anstatt sich auf Anweisungen der darüberliegenden Ebene zu stützen, die durch geeignete Eingabemanipulation umgangen werden könnten.

Die Funktionen „Messen“ und „Verwalten“ des NIST AI RMF werden durch die Erstellung eines Ausführungsprotokolls vereinheitlicht. Management ist ohne Messung und Messung ohne Management nicht möglich – andernfalls beschränkt sich die Dokumentation auf das Dokumentieren. Das Management wird stets eine Interpretation der Daten haben, deren Aussagekraft jedoch von der Genauigkeit der im Messprozess generierten Daten abhängt. Der Trace-Datensatz der Insights API ermöglicht die Funktionen „Messen“ und „Verwalten“. Wird ein Signal für eine erhöhte Fehlerrate in einer Workflow-Kategorie generiert, kann die Indexkonfiguration so geändert werden, dass ein höherer Risikoschwellenwert erforderlich ist, bevor dieser Workflow als Top-Kandidat angezeigt wird. Eine Änderung der Indexkonfiguration steht sofort allen Knoten im verteilten Suchnetzwerk zur Verfügung und erfordert weder die erneute Bereitstellung eines Modells noch die Anpassung von Eingabeaufforderungen. Ein Indexvorgang ist eine schnelle, nachvollziehbare und reversible Governance-Reaktion.

Diese Ausführungsschleife entspricht den CNCF-Workflow-Prinzipien; dadurch wird sichergestellt, dass Wiederholungssemantik, Aufgabenisolation und Ausführungsverfolgung strukturelle Eigenschaften der Architektur und nicht Implementierungsdetails für jedes Entwicklungsteam sind. Die NIST AI RMF Ongoing Measurement Function wird als operative Praxis und nicht nur zu Dokumentationszwecken eingesetzt.

/**
 * Orchestration runtime execution loop — ILLUSTRATIVE EXAMPLE
 * Demonstrates the handoff flow from routing layer to execution plane.
 * In a production Algolia environment, field names and API calls align with
 * the actual ActionProposal interface and Insights API schema.
 * Enforces policy gates and records auditable traces using the Insights API.
 */
async function processActionProposal(proposal: ActionProposal, userSession: Session) {
  // 1. Policy and permission gate
  // Enforces OWASP ASI02 (Tool Misuse) at the execution boundary
  const isAuthorized = await policyEngine.check(userSession.user, proposal.action_id);
  if (!isAuthorized) {
    throw new Error("Unauthorized: Action exceeds user permission scope.");
  }

  // 2. Step-up authorization for critical-tier actions
  // Aligned with NIST AI RMF human-in-the-loop expectations
  if (proposal.risk_metadata.nist_tier === "critical") {
    await requestMfaVerification(userSession);
  }

  // 3. Execution within deterministic MCP contract
  // Prevents OWASP ASI01 (Agent Goal Hijack) at the execution layer
  try {
    const result = await mcpClient.execute(proposal.execution_payload);

    // 4. Record unified retrieval and execution telemetry
    // Binds the execution outcome to the Algolia query ID for Safe Relevance
    await insightsClient.clickedObjectIDsAfterSearch({
      eventName: "Tool Executed Safely",
      indexName: "actionable_registry",
      queryID: proposal.query_id,
      objectIDs: [proposal.objectID],
      positions: [1],
      userToken: userSession.user.id
    });

    return result;
  } catch (error) {
    // Log failure as a Safe Relevance signal for ranking adjustment
    return handleExecutionFailure(error, proposal);
  }
}

Fazit: Die Suche verändert sich.

Das Ausgabeformat einer Suchmaschine wandelt sich von einer Linkliste von Ressourcen zu einer Liste von Aktionspunkten, die Aufgaben erledigen. Dies deutet auf einen Paradigmenwechsel von der Dokumentenindizierung zur Aufgabenausführung hin. Die Entscheidung für diesen Übergang ist ein Designschritt im Kontext der Gesamtarchitektur des Systems und keine iterative Verbesserung eines bestehenden Suchmodells.

Wenn beispielsweise die Retrieval-Schicht einer Suchmaschine so strukturiert ist, dass sie eine Liste umsetzbarer Vorschläge erzeugt, die sowohl den Corporate-Governance-Standards als auch den Auditierungsstandards für die vorgeschlagene(n) Anwendung(en) entsprechen, müsste die Schicht die verfügbaren vertragsbasierten Tools indexieren; die Liste der verfügbaren Tools anhand des gewünschten Anwendungsfalls und der zugehörigen Sicherheitsrichtlinie bewerten; und diese Tools innerhalb der von den meisten großen Unternehmenssystemen festgelegten Latenzanforderungen bereitstellen.

Neben dem Ausgabeformat der Suchmaschine bleiben die grundlegenden technischen Fähigkeiten für die schnelle Ausführung von Suchanfragen, die Sortierung der Ergebnisse und die Zugriffskontrolle unverändert. Die entscheidenden Unterschiede liegen darin, was indexiert wird und wie der Index befüllt wird. Beispielsweise besteht der Index der meisten Enterprise-Suchsysteme aus statischen Dokumenten. Bei einer Suchmaschine, die als Workflow-Copilot in einer Produktionsumgebung fungiert, wird der Index hingegen mit Werkzeugverträgen, Workflow-Vorlagen, Formularschemata und Definitionen von MCP-Servern befüllt. Auch die Sortierung der Ergebnisse hat sich geändert: Sie berücksichtigt nun neben der Relevanz für die ursprüngliche Suchanfrage des Nutzers auch Sicherheitsstufen, Berechtigungsbereiche und das Ausführungsrisiko.

Ein verteiltes Suchnetzwerk, das nativ mit schemaunabhängigen JSON-Datensätzen arbeiten kann, ermöglicht es der Architektur, alle mehrdimensionalen Einschränkungen (z. B. Absicht, Umfang usw.) gleichzeitig zu berücksichtigen und im Gegensatz zur bloßen Aufzeichnung der Suchanfragen und des Klickverhaltens des Benutzers zusätzliche Einblicke in den gesamten Workflow-Prozess (von der Absicht des Benutzers bis zum endgültigen Ergebnis) zu geben.

Ein Terminal-Audit-Trace validiert die Architektur, während der Terminal-Audit-Trace die Entscheidungskette in der Beziehung zwischen den Absichten eines Benutzers und der Reaktion des Systems aufzeigt; daher stellt der Terminal-Audit-Trace das letzte Beweisstück dar, das erforderlich ist, um zu beweisen, dass die Architektur wie beabsichtigt funktioniert hat.

Obwohl MCP den Vorteil einer standardisierten Methode für die Kommunikation zwischen Tools und System bietet, vergrößert es letztlich nur die Angriffsfläche großer Systeme und verringert die Kontrollmöglichkeiten. Durch ein Verzeichnis, das Tool-Verträge auf Basis von Benutzereingaben abruft, wandelt sich das Protokoll von einer nützlichen Methode zur Integration von Diensten zu einer Sicherheitsmethode.

Diese Architektur zeichnet sich nicht nur durch ihre Selbstoptimierung, sondern vor allem durch das Konzept der „sicheren Relevanz“ aus. Jedes Ausführungsergebnis (ob erfolgreicher Tool-Aufruf, Richtlinienblockierung, Fehler bei der Parametervalidierung oder Abbruch an einer MFA-Gateway) wird als Ranking-Signal an die Abrufschicht zurückgegeben. Es ist kein manueller Eingriff erforderlich, um festzustellen, ob ein bestimmter Workflow zusätzliche Ausführungsrisiken birgt. Stattdessen lernt die Indexierungsschicht diese Information aus den Aufzeichnungen vergangener Ausführungen und reagiert entsprechend. Workflows, die an der Ausführungsgrenze fehlschlagen, erhalten für alle nachfolgenden, ähnlichen Ausführungen eine niedrigere Bewertung. Dadurch agiert der Copilot in risikoreichen Kontexten konservativer. Die NIST-Mess- und Verwaltungsfunktionen laufen kontinuierlich in einer automatisierten Schleife und nicht periodisch als Audit. Dies ist das entscheidende Merkmal, das ein tatsächlich verwaltetes System von einem System unterscheidet, das lediglich aufgrund der Dokumentation den Anschein der Verwaltung erweckt.

{
  "trace_id": "audit_88321_exec",
  "intent_routing": {
    "query": "provision staging",
    "retrieval_id": "alg_992x",
    "selected_candidate": "wf_provision_staging_001",
    "ranking_score": 0.98,
    "latency_ms": 102
  },
  "execution_plane": {
    "tool_invoked": "terraform_deploy",
    "mcp_server": "mcp.internal.infra",
    "status": "success",
    "runtime_id": "rt_7721"
  },
  "safety_compliance": {
    "nist_tier": "critical",
    "mfa_verified": true,
    "owasp_mitigation": ["ASI01", "ASI02"],
    "policy_version": "v2.1"
  }
}

---

Die bewährte Architektur von Algolia (mehr als 17.000 Kunden, über 150 Länder, 1,75 Billionen Suchanfragen jährlich) ist die Retrieval- und Ranking-Schicht, auf der Intent-to-Action-Architekturen im Unternehmensmaßstab basieren.

Die eigentliche Frage ist, ob diese Ebene schnell genug bleiben kann, um auf dem kritischen Pfad zu bleiben, während sie gleichzeitig wichtige Aktionen priorisiert und für jede Entscheidung einen vollständigen Prüfpfad führt. Das ist der Standard, den ein reguliertes System erfüllen muss.

Eine Vorführung vereinbaren