Just-in-Time-Zugang für Produktions-KI-Agenten

13 Minuten Lesezeit

Der Just-in-Time-Zugriff ermöglicht es einem KI-Agenten, zu handeln, ohne einen permanenten Anmeldenachweis zu halten. Ein Incident Agent kann eine Warnung lesen, einen Einsatz inspizieren und innerhalb von Sekunden eine Reparatur vorschlagen. Der gefährliche Teil beginnt, wenn er auch einen Cluster mit einem wiederverwendbaren Anmeldenachweis erreichen kann.

Die meisten Teams versuchen, diese Anmeldeinformationen sicherer zu machen. Sie legen sie in einen Geheimladen, drehen sie, verstecken sie vor Protokollen und sagen dem Modell, dass es sie nicht preisgeben soll. Diese Kontrollen sind wichtig, aber sie beheben nicht den grundlegenden Konstruktionsfehler. Eine allgemeine Agentensitzung hat immer noch eine wiederverwendbare Fähigkeit, die die Entscheidung, die ihre Verwendung rechtfertigte, überleben könnte.

Ein besseres Design hält den Produktionsnachweis außerhalb des Agenten. Der Agent schlägt eine Operation vor. Ein deterministischer Durchsetzungspfad überprüft Identität, delegierte Autorität, Ticketkontext, Richtlinien und Genehmigung. Nur dann erhält ein Berechtigungsvermittler eine kurzlebige Fähigkeit für das genaue Ziel. Das Gateway führt die genehmigte Anfrage aus und zeichnet auf, was passiert ist.

Dieser Artikel entwickelt dieses Muster für einen Kubernetes-Behebungsagenten. Die gleiche Architektur passt zu Cloud-Administration, geheimer Rotation, Datenbankwartung und Managed-Service-Zugriff.

Starten Sie Just-in-Time-Zugriff mit einer Transaktion, nicht einer Sitzung

Angenommen, eine Warnung sagt, dass payments-api Ein Agent untersucht und schlägt ein Rollback zum Image Digest vor sha256:4c2... Zwischenfall INC-4821.

Das System sollte keine vage Frage stellen wie "Darf dieser Agent die Produktion verwalten?" Es sollte über eine konkrete Transaktion entscheiden:

{
  "transactionId": "txn_01J8K7V3T6",
  "agentId": "agent:ops:remediator-7",
  "action": "kubernetes.deployment.rollback",
  "resource": "cluster/prod-eu/namespace/payments/deployment/payments-api",
  "parameters": {
    "imageDigest": "sha256:4c2...",
    "replicaCount": 6
  },
  "purpose": "incident-remediation",
  "ticket": "INC-4821",
  "requestedAt": "2026-08-10T09:42:11Z"
}

Dieser Umschlag gibt der Policy-Engine etwas Stabiles, das sie bewerten kann, und verhindert auch einen allgemeinen Sicherheitsfehler: die Genehmigung einer vom Menschen lesbaren Absicht, dann die Ausführung eines wesentlich anderen API-Aufrufs.

Der Umschlag kann vor dem Signieren oder Hashen des Umschlags kanonisiert werden; die Genehmigung, die vorläufige Anmeldebescheinigung und die endgültige Quittung an denselben Digest binden; wenn sich die Anzahl des Bildes, des Namensraums, der Replikate oder des Tickets ändert, ändert sich der Digest und die frühere Entscheidung kann nicht wiederverwendet werden.

Separater Vorschlag, Genehmigung und Ausführung

Der Agent gehört in den Vorschlagspfad. Er kann Warnmeldungen interpretieren, Runbooks abrufen, aktuelle Bereitstellungen vergleichen und erklären, warum ein Rollback helfen könnte. Er sollte nicht die endgültige Zugangsentscheidung treffen oder seine eigenen Anmeldeinformationen prägen.

Verwenden Sie drei verschiedene Komponenten:

1. Die Agent Runtime erstellt eine vorgeschlagene Transaktion aus genehmigten Tools und Beobachtungen.
2. Ein Gateway und ein Policy-Entscheidungspunkt validieren die Transaktion gegen deterministische Einschränkungen.
3. Ein Credential Broker erhält eine temporäre Fähigkeit und ein Executor ruft die Produktions-API auf.

Alert and ticket
    |
    v
Investigation agent
    |
    | proposed transaction, no production secret
    v
Gateway -> identity + mandate + policy + approval
    |
    | authorised request digest
    v
Credential broker -> short-lived capability
    |
    v
Executor -> Kubernetes or cloud API
    |
    v
Result + signed action receipt

Diese Trust-Domains sollten getrennt bleiben, auch wenn sie bei der ersten Implementierung in einem Cluster ausgeführt werden. Der Agent-Prozess sollte keinen Netzwerkzugriff auf die administrative Schnittstelle des Secret Stores haben. Der Credential-Broker sollte nur eine autorisierte, signierte Anfrage des Gateways akzeptieren. Der Executor sollte eine Fähigkeit ablehnen, deren Ziel oder Lebensdauer nicht mit der Operation übereinstimmt.

Expressautorität als gebundenes Mandat

Identität sagt Ihnen, welcher Agent die Anfrage gestellt hat. payments-api.

Vertretung der delegierten Befugnis in einem kurzlebigen Mandat; die folgende YAML ist eher illustrativ als eine OATI-Schemadefinition:

mandateId: mandate_inc_4821
principal: org:example:platform-operations
subject: agent:ops:remediator-7
purpose: incident-remediation
validFrom: 2026-08-10T09:30:00Z
expiresAt: 2026-08-10T11:00:00Z
constraints:
  actions:
    - kubernetes.deployment.get
    - kubernetes.pod.logs.read
    - kubernetes.deployment.rollback
  resources:
    - cluster/prod-eu/namespace/payments/deployment/payments-api
  ticketIds:
    - INC-4821
  maintenanceWindow:
    start: 2026-08-10T09:30:00Z
    end: 2026-08-10T11:00:00Z
  maxReplicaCount: 8
  allowedImageDigests:
    - sha256:4c2...
  maxExecutions: 1
  delegation:
    allowed: false

Das Mandat sollte so eng sein, dass eine gestohlene Kopie wenig Wert hat; es sollte auch maschinenüberprüfbar sein; Sätze wie "vernünftige Korrekturmaßnahmen ergreifen" gehören in ein Runbook, nicht in das endgültige Autorisierungsobjekt.

Wenn ein Agent Ermittlungen an einen anderen delegiert, leiten Sie die Child Authority ab, indem Sie jede Einschränkung mit dem Elternteil überschneiden. Fehlende Einschränkungen dürfen keinen unbegrenzten Zugriff bedeuten. Ein Child Mandat kann den Ablauf verkürzen, Aktionen entfernen und Ressourcen einschränken. Es kann niemals einen Namespace, eine Aktion, ein Ziel oder ein Budget hinzufügen.

Setzen Sie deterministische Richtlinie auf den Ausführungspfad

Die Policy Engine erhält verifizierte Identität, das Mandat, die kanonische Transaktion und aktuelle Umweltfakten. allow, deny, transform oder approval_required.

Zum Beispiel:

deny if passport.status != "active"
deny if mandate.expiresAt <= now
deny if transaction.purpose != mandate.purpose
deny if transaction.ticket not in mandate.ticketIds
deny if transaction.action not in mandate.actions
deny if transaction.resource not in mandate.resources
deny if transaction.parameters.imageDigest not in mandate.allowedImageDigests
deny if transaction.parameters.replicaCount > mandate.maxReplicaCount
deny if executionState.reserve(transaction.transactionId, transaction.digest) fails

approval_required if resource.environment == "production"
approval_required if change.riskScore >= configuredThreshold

allow otherwise

Der Risiko-Score, wenn Sie einen verwenden, kann das Routing informieren. Lassen Sie sich von einem undurchsichtigen Modell-Score nicht über harte Einschränkungen hinwegsetzen. Das sicherste Policy-Ergebnis ist anhand der Eingabedaten und eines versionierten Regelpakets erklärbar.

Transformationen vor der Ausführung anwenden und sie in den endgültigen Digest aufnehmen. Ein Gateway kann ein Timeout klemmen, ein nicht genehmigtes Feld entfernen oder einen vom Menschen lesbaren Ressourcenalias durch einen aufgelösten Bezeichner ersetzen.

Binden Sie die menschliche Zustimmung zur genauen Operation

"Genehmigung der Mängelbeseitigung" ist keine ausreichende Genehmigungsaufzeichnung. Der Genehmiger sollte das Ziel, die Maßnahmen, die Parameter, die Beweise, die Richtlinienversion, den Ablauf und die Anforderung von Digest sehen.

{
  "approvalId": "apr_01J8K8A7H2",
  "transactionDigest": "sha256:ab91...",
  "decision": "approved",
  "approver": "user:platform:oncall-12",
  "role": "production-change-approver",
  "expiresAt": "2026-08-10T10:05:00Z",
  "reason": "Rollback matches incident runbook and last known good digest"
}

Der Vollstrecker muss die Genehmigung ablehnen, wenn der Transaktionsverdau unterschiedlich ist, wenn die Genehmigung abgelaufen ist oder wenn der Genehmiger auch der Auftraggeber war, der die Befugnis bei der Aufgabentrennung erteilt hat. Dies blockiert einen subtilen Kontext-Swap-Angriff, bei dem ein Agent die Genehmigung für eine harmlose Lektüre erhält und sie einem Schreiben anhängt.

Mint eine Fähigkeit, die der Agent nicht wiederverwenden kann

Der Broker kann einen Cloud-Sicherheits-Token-Service, ein Vault-ähnliches Geheimsystem oder einen internen Anmeldedienst aufrufen. Die Implementierung variiert, aber der Vertrag sollte klein bleiben:

type CredentialRequest = {
  transactionDigest: string;
  subject: string;
  audience: string;
  action: string;
  resource: string;
  expiresInSeconds: number;
  proofKeyThumbprint?: string;
};

type TemporaryCapability = {
  handle: string;
  expiresAt: string;
  audience: string;
  resource: string;
  proofBinding?: string;
};

Der Executor kann den Handle einmal innerhalb einer eingeschränkten Netzwerkgrenze einlösen. Wenn der Upstream den Besitznachweis unterstützt, binden Sie den Credential über DPoP oder mTLS an einen von dem Executor gehaltenen Schlüssel. Ein kopiertes Token ist dann allein nicht ausreichend.

Die Laufzeit der Fähigkeit sollte die Ausführungszeit und nicht die Dauer des Vorfalls widerspiegeln. Fünf Minuten können für einen API-Aufruf angemessen sein, während das Mandat 90 Minuten gültig bleibt.

Speichern Sie eine Berechtigungsklasse, einen Emittenten, eine Zielgruppe, einen Ablauf und eine nicht geheime Referenz, wenn die Ermittler rekonstruieren müssen, wie die Ausführung stattgefunden hat.

Beschränken Sie auch den Executor

Der Executor ist eine Sicherheitsgrenze, kein allgemeiner HTTP-Client. Geben Sie ihm explizite Adapter für genehmigte Operationen. Ein Rollback-Adapter akzeptiert möglicherweise nur eine Bereitstellungskennung und einen Image-Digest. Er sollte keine willkürlichen Kubernetes-Manifeste oder Shell-Befehle akzeptieren.

Das Reservat bewegt sich durch explizite Zustände wie reserved, executing und completedEine Genehmigungswarte verbraucht sie nicht. Ein fehlgeschlagener Broker-Aufruf kann sie gemäß den Richtlinien freigeben, während ein mehrdeutiges Upstream-Ergebnis bis zum Abgleich reserviert bleibt.

async function executeRollback(tx: AuthorizedTransaction) {
  assert(tx.action === "kubernetes.deployment.rollback");
  assert(tx.approval.transactionDigest === tx.digest);
  assert(await executionState.begin(tx.id, tx.digest));

  const credential = await broker.redeemOnce(tx.credentialHandle, tx.digest);
  // `kubernetes` is an internal typed adapter, not a Kubernetes client API.
  const result = await kubernetes.rollback({
    deployment: tx.resource,
    imageDigest: tx.parameters.imageDigest,
    replicaCount: tx.parameters.replicaCount,
    credential,
  });

  const normalised = normaliseResult(result);
  await executionState.complete(tx.id, normalised.operationReference);
  return normalised;
}

Entlarven Sie keinen allgemeinen run_shell(command) Tool and Hope Policy fängt jede gefährliche Zeichenfolge ein. Typisierte Adapter reduzieren die Anzahl der Bedeutungen, die eine Anforderung zwischen Genehmigung und Ausführung erhalten kann.

Die Netzwerkrichtlinie sollte die Anwendungskontrollen verstärken. Die Agent-Laufzeit kann das Gateway erreichen, nicht jedoch die Kubernetes-API. Der Executor kann den relevanten Cluster-Endpunkt erreichen, aber keine nicht verwandte Infrastruktur. Der Broker kann den Anmelder erreichen, benötigt aber keinen allgemeinen Outbound-Zugriff.

Notieren Sie das Ergebnis, ohne es zu überschätzen

Erstellen Sie nach der Ausführung einen signierten Aktionsbeleg, der den Agenten, die Organisation, das Mandat, den Transaktionsverdau, die politische Entscheidung, die Genehmigung, den ausgeführten Betrieb, den Antwortverdau, die externe Anbieterreferenz, die Zeit und die Idempotenzdaten bindet.

Bei einem Einsatz eines Unternehmens handelt es sich um einseitige Beweise. Es beweist, was das Durchsetzungssystem der Einsatzorganisation aufgezeichnet und unterzeichnet hat. Es beweist nicht, dass Kubernetes die Wahrheit gemeldet hat, dass der Dienst wiederhergestellt wurde oder dass ein anderes Unternehmen dem Datensatz zugestimmt hat. Wenn der Vertragspartner oder das Zielsystem das Ergebnis später unterschreibt, kann das Sicherheitsniveau steigen, aber die Unterscheidung muss explizit bleiben.

Die Ergebnisverifizierung gehört nach der Aktion. Ein Rollback, das HTTP 200 zurückgibt, ist nicht dasselbe wie der wiederhergestellte Dienst. Führen Sie separate Überprüfungen auf Gesundheit, Fehlerrate und Datenverkehr durch. Verknüpfen Sie diese Beobachtungen mit der Transaktion, ohne den ursprünglichen Beleg neu zu schreiben.

Entwerfen Sie den Fehlerpfad vor dem glücklichen Pfad

Produktionsagenten werden interessant, wenn Abhängigkeiten auf halbem Weg durch eine Transaktion scheitern.

Das Kontrollflugzeug ist nicht verfügbar

Bewahren Sie signierte Richtlinienpakete und kurzlebigen Vertrauenszustand in der Nähe des Gateways auf. Wesentliche Aktionen sollten nicht geschlossen werden, wenn das Gateway den Widerrufs-, Richtlinien- oder Wiedergabezustand nicht gemäß den konfigurierten Frischegrenzen validieren kann.

Der Replay Store ist nicht verfügbar

Ein einmaliges Mandat oder eine einmalige Transaktion kann nicht durchgesetzt werden, wenn das System seinen Identifikator nicht beanspruchen und verwenden kann.

Die Genehmigung erfolgt nach Ablauf des Mandats

Verweigern Sie es. Die Genehmigung verlängert nicht die Befugnis, erteilen Sie ein neues Mandat und bewerten Sie eine neue Transaktion.

Der Berechtigungsnachweis ist geprägt, aber die Ausführung fällt aus

Behandeln Sie das Ergebnis als unbekannt, nicht fehlgeschlagen, Abfrage des Zielsystems unter Verwendung des idempotency-Schlüssels oder der Operationsreferenz, bevor Sie es erneut versuchen.

Das Ziel mutiert zwischen Entscheidung und Ausführung

Verwenden Sie Ressourcenversionen oder Voraussetzungen, wenn der Upstream sie unterstützt. Wenn sich die Deployment-Revision nach der Genehmigung geändert hat, stoppen und erstellen Sie eine neue Transaktion.

Das Modell schlägt eine Aktion außerhalb des Runbooks vor

Der Agent kann ein breiteres, von Menschen verfasstes Mandat verlangen, aber er kann die Richtlinie nicht durch prompten Text umschreiben.

Angriffe testen, nicht nur Workflows

Eine nützliche Test-Suite sollte versuchen:

• den Namensraum nach der Genehmigung ändern;
• den genehmigten Bildverdau ersetzen;
• Wiedergabe der gleichen Transaktionskennung;
• Einlösen eines Berechtigungsnachweises von einem anderen Vollstrecker;
• eine Fähigkeit nach Ablauf zu nutzen;
• Umgehen des Gateways und erreichen Sie das Ziel direkt;
• ein anderes Ticket mit einer ähnlichen Beschreibung ersetzen;
• Ausführung während eines Trust- oder Replay-Store-Ausfalls;
• Injizieren von Anweisungen durch Warntext oder Pod-Protokolle;
• Genehmigung und Ausführung mit demselben Hauptverpflichteten, wenn eine Aufgabentrennung erforderlich ist.

Bei einer blockierten Anforderung sollte dennoch ein Entscheidungsprotokoll mit einem Grundcode, einer Richtlinienversion und einer Korrelationskennung erstellt werden, wobei Geheimnisse und unnötige Nutzdaten ausgeschlossen werden sollten.

Checkliste der Durchführung

• Modellieren Sie jede Folgeanforderung als kanonische Transaktion.
• Bewahren Sie Produktionsanmeldeinformationen außerhalb des Agentenprozess- und Modellkontexts auf.
• Verwenden Sie kurzlebige Mandate mit expliziten Aktionen, Ressourcen, Zweck und Ablauf.
• Bewerten Sie harte Einschränkungen in deterministischen Code oder Richtlinie.
• Bindende Genehmigungen zum genauen Transaktionsverdau.
• Broker-aufgabenspezifische Fähigkeiten erst nach einer Genehmigungsentscheidung.
• Bevorzugen Sie einmalige undurchsichtige Handles und beweisgebundene Anmeldeinformationen.
• Verwenden Sie typisierte Executoren anstelle von allgemeinen Shell- oder HTTP-Tools.
• Erzwingen Sie den Pfad mit Netzwerksteuerungen, damit Agenten das Gateway nicht umgehen können.
• Fordern Sie Transaktionskennungen vor der Ausführung an und bewahren Sie die Idempotenz über Retries hinweg.
• Behandeln Sie Timeouts als unbekannte Ergebnisse, bis sie versöhnt sind.
• Überprüfen Sie die operativen Ergebnisse getrennt vom API-Erfolg.
• Unterschreiben Sie eine Quittung, die ihr Sicherheitsniveau angibt.
• Testen Sie Widerruf, Ausfälle, veralteten Zustand, Wiederholung und Kontextsubstitution.

Verwandte technische Anleitungen

• Degradiertes Verhalten definieren mit Fail-Open vs. Fail-Closed Regeln für Enterprise AI Agenten.
• Halten Sie den gesamten Regelpfad mit einem auditierte AI Agent Transaktionsarchitektur.

Wo OATI passt

OATI Modellierung dieses Ablaufs als Verantwortlichkeiten für Passport, Mandate, Transaction, Policy, Approval, Credentials, Connect and Receipt. Eingang Tooling und ein Referenz-Envoy-Enforcement-Pfad bleibt eine Entwicklervorschau, bis eine unabhängige Überprüfung des Protokolls und der Implementierung sowie zusätzliche Produktionsgates vorliegen.

Die gehärtete Gateway-Flotte, vollständige Berechtigungsvermittler-Operationen, dauerhafter Beweisdienst und Kundenausfall-Übungen sind zielgerichtete kommerzielle Fähigkeiten, nicht abgeschlossene Produktionsansprüche. Diese Grenze ist absichtlich. Die nützliche architektonische Idee hängt nicht von einem Produktversprechen ab: Ein Beauftragter für Unternehmenssanierung sollte die Autorität für eine Transaktion erhalten, während die Berechtigung und die endgültige Entscheidung außerhalb des Modells bleiben.