Bewährte Sicherheitsmethoden für AgentCore Runtime

• Machen Sie sich mit den Grenzen der Isolation vertraut — Jede Benutzersitzung wird auf einer dedizierten MicroVM mit isolierter CPU, isoliertem Speicher und Dateisystem ausgeführt. Befehle und Agentencode können nicht auf die Workloads anderer Kunden zugreifen oder die VM-Grenze umgehen. Nach Abschluss der Sitzung wird die gesamte MicroVM beendet und der Speicher bereinigt.

• Erzwingen Sie Zuordnungen von Sitzungen zu Benutzern in Ihrem Backend — erzwingt keine Zuordnungen von Sitzungen zu Benutzern. AgentCore Ihr Client-Backend muss die Beziehung zwischen Benutzern und ihren Sitzungs-IDs aufrechterhalten und ein Lebenszyklusmanagement implementieren, z. B. die maximale Anzahl von Sitzungen pro Benutzer.

• Beachten Sie das Verhalten von Dateisystemberechtigungen — Bei der Verwendung persistenter Dateisysteme werden Berechtigungen gespeichert, aber nicht innerhalb der Sitzung durchgesetzt. chmodund stat funktionieren einwandfrei, aber Zugriffsprüfungen sind immer erfolgreich, da der Agent als einziger Benutzer in der MicroVM ausgeführt wird.

• Machen Sie sich mit der Offenlegung von Anmeldeinformationen innerhalb der VM vertraut — Jeder Code oder Akteur, der innerhalb der MicroVM ausgeführt wird, kann auf die Anmeldeinformationen der Ausführungsrolle zugreifen, indem er den Metadaten-Endpunkt (MMDS) aufruft. Geben Sie Ihre Berechtigungen für die Ausführungsrolle sorgfältig ein. Weitere Informationen finden Sie unter Verwaltung von Anmeldeinformationen.

• Verwenden Sie keine CLI-generated Richtlinien in der Produktion — Die von der AgentCore CLI erstellten IAM-Richtlinien sind für Entwicklungs- und Testzwecke konzipiert. Diese Berechtigungen gewähren einen breiten Zugriff und sind nicht für die Produktion geeignet. Erstellen Sie benutzerdefinierte IAM-Richtlinien, die Berechtigungen nur auf die spezifischen Ressourcen und Aktionen beschränken, die erforderlich sind. Die vollständige Referenz finden Sie unter IAM-Berechtigungen für AgentCore Runtime.

• Geltungsbereich von Berechtigungen auf bestimmte Runtime-ARNs — Vermeiden Sie Platzhalter-Ressourcenanweisungen. Verwenden Sie den vollständigen ARN Ihrer Laufzeitressourcen in Resource IAM-Richtlinienfeldern.

• Einschränken InvokeAgentRuntimeForUser — Nur vertrauenswürdige Principals sollten über diese Berechtigung verfügen. Verwenden Sie die IAM-Ressourcenbedingungen, um sie auf bestimmte Laufzeitressourcen auszudehnen.

• Benutzer-ID-Delegierung verweigern, wo sie nicht benötigt wird — Für Laufzeiten, in denen keine Benutzer-ID-Delegierung erforderlich ist, lehnen Sie die Aktion explizit ab:

  {
     "Statement": [
        {
           "Sid": "DenyUserIdDelegation",
           "Effect": "Deny",
           "Action": "bedrock-agentcore:InvokeAgentRuntimeForUser",
           "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT_ID:runtime/*"
        }
     ]
  }

• Rechteeskalation verhindern — Stellen Sie sicher, dass die Ihrer Laufzeit zugeordnete Ausführungsrolle dieselben oder weniger Rechte hat als die Prinzipale, die sie aufrufen können. Weitere Informationen finden Sie unter Credentials Management.

• Verwenden Sie IAM-Bedingungsschlüssel, um VPC-Bereitstellungen zu erzwingen — Verwenden Sie bedrock-agentcore:subnets und bedrock-agentcore:securityGroups Bedingungsschlüssel, um zu verlangen, dass alle Laufzeiten in zugelassenen VPCs bereitgestellt werden. Beispiele finden Sie unter Verwenden von VPC-Bedingungsschlüsseln mit AgentCore Runtime.

• Verwenden Sie IAM Access Analyzer — Überprüfen Sie Ihre IAM-Richtlinien, um sicherzustellen, dass sie den Best Practices und den Prinzipien der geringsten Rechte entsprechen.

• Grundlegendes zur hierarchischen Autorisierung — Bei API-Laufzeitoperationen wie InvokeAgentRuntime InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, und werden Richtlinien sowohl auf der Agentenlaufzeit als auch auf dem Agentenendpunkt AWS ausgewertet. Beide müssen die Aktion zulassen.

• Beide Ressourcen für kontoübergreifenden Zugriff konfigurieren — Um kontenübergreifenden Zugriff zu gewähren, erstellen Sie ressourcenbasierte Richtlinien sowohl für die Agent-Laufzeit als auch für den Agenten-Endpunkt. Wenn für eine der Ressourcen keine ausdrückliche Genehmigung erteilt wurde, wird die Anfrage abgelehnt.

• Denken Sie daran, dass die explizite Ablehnung immer gewinnt. Wenn eine Richtlinie (identitäts- oder ressourcenbasiert) eine Aktion ausdrücklich verweigert, wird der Zugriff unabhängig von anderen Richtlinien verweigert.

• Verwenden Sie aws:SourceArn und aws:SourceAccount — Fügen Sie die folgenden Bedingungen zu Ihrer Vertrauensrichtlinie für Ausführungsrollen hinzu, um einzuschränken, welche AgentCore Ressourcen diese Rolle übernehmen können:

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "bedrock-agentcore.amazonaws.com"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
          "StringEquals": {
            "aws:SourceAccount": "123456789012"
          },
          "ArnLike": {
            "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:*"
          }
        }
      }
    ]
  }

• Verwenden Sie nach Möglichkeit den vollständigen ARN — Wenn Sie die spezifische Laufzeitressource kennen, verwenden Sie ihren vollständigen ARN aws:SourceArn anstelle von Platzhaltern.

• Policy-based Autorisierung — Verwenden Sie die Policy-Engine des Gateways, um zu kontrollieren, welche Anrufer welche Ziele aufrufen können und unter welchen Bedingungen. Weitere Informationen finden Sie unter Verwenden von Richtlinien zur Steuerung des Zugriffs auf Gateway-Ziele.

• Guardrails — Wenden Sie Amazon Bedrock Guardrails über die Policy-Engine an, um Anfragen und Antworten zu überprüfen. Weitere Informationen finden Sie unter Verwenden von Leitplanken in Richtlinien.

• Request- und Response-Interzeptoren — Untersuchen oder transformieren Sie den Datenverkehr mit auf dem Gateway konfigurierten Interceptor-Lambda-Funktionen.

• IAM-Laufzeiten (SigV4) — Fügen Sie eine ressourcenbasierte Richtlinie hinzu, die den Aufruf auf die Ausführungsrolle des Gateways beschränkt. Weitere Informationen finden Sie unter Einschränken eingehender IAM-Aufrufe (SigV4) auf Ihr Gateway.

• OAuth (JWT) -Laufzeiten — Konfigurieren Sie sie auf dem Authorizer der Laufzeit. allowedWorkloadConfiguration Weitere Informationen finden Sie unter Beschränken des Aufrufs auf Ihr Gateway.

• Wählen Sie die richtige Authentifizierungsmethode — Verwenden Sie IAM SigV4 für Service-to-Service-Anrufe innerhalb. AWS Verwenden Sie die JWT-Bearer-Token-Authentifizierung, wenn sich Endbenutzer direkt über einen Identitätsanbieter authentifizieren. Eine Laufzeit kann jeweils eine Methode unterstützen; separate Versionen für verschiedene Authentifizierungstypen erstellen.

• Bevorzugen Sie die JWT-based Benutzeridentifikation für die Produktion — Wenn Ihr Agent OAuth-Token im Namen von Endbenutzern abruft, bevorzugen Sie den JWT-Bearer-Token Path (GetWorkloadAccessTokenForJWT), der den Aussteller, die Signatur und den Ablauf des Tokens validiert. Der UserId Pfad (GetWorkloadAccessTokenForUserId/X-Amzn-Bedrock-AgentCore-Runtime-User-Idheader) behandelt die Benutzerkennung als undurchsichtige Zeichenfolge ohne IdP-Überprüfung. Verwenden Sie sie nur für Entwicklungs-, Schnellstartszenarien oder Unternehmensarchitekturen, die Benutzeridentität im Upstream auflösen. Weitere Informationen finden Sie unter Workload-Zugriffstoken abrufen.

• Vollständige Konfiguration von JWT-Autorisierern — Wenn Sie die JWT-Authentifizierung verwenden, konfigurieren Sie alle verfügbaren Validierungsfelder: Discovery-URL, zulässige Zielgruppen, zulässige Clients, zulässige Bereiche und erforderliche benutzerdefinierte Ansprüche.

• Kodieren Sie niemals Token im Produktionscode fest — Verwenden Sie sichere Mechanismen zum Abrufen von Token. Hartcodierte Token stellen ein Sicherheitsrisiko bei der Quellcodeverwaltung und den bereitgestellten Artefakten dar.

• Benutzer-ID vom authentifizierten Prinzipal ableiten — Wenn Sie den X-Amzn-Bedrock-AgentCore-Runtime-User-Id Header verwenden, sollte der Wert aus dem Kontext des authentifizierten Prinzipals (IAM-Aufruferidentität oder Benutzertoken-Ansprüche) abgeleitet werden, nicht aus beliebigen vom Client bereitgestellten Werten. Dadurch wird verhindert, dass authentifizierte Benutzer sich als andere Benutzer ausgeben.

• Verweigern ForUserId , wo es nicht benötigt wird — Für Workloads, für die immer ein JWT verfügbar ist, explizit ablehnen bedrock-agentcore:GetWorkloadAccessTokenForUserId und in IAM-Richtlinien enthalten. bedrock-agentcore:InvokeAgentRuntimeForUser Dadurch wird sichergestellt, dass die gesamte Benutzeridentifikation den kryptografisch verifizierten JWT-Pfad durchläuft.

• Konfigurieren Sie VPC-Endpunktrichtlinien für Ihre Authentifizierungsmethode — VPC-Endpunktrichtlinien können nur Anrufer einschränken, die auf IAM-Prinzipalen basieren, nicht auf OAuth-Benutzern. Stellen Sie für OAuth-based Anfragen in der Endpunktrichtlinie auf ein. Principal * Geben Sie für die SigV4-based Authentifizierung die zulässigen IAM-Identitäten an.

• Verwenden Sie AgentCore Identity für ausgehende Authentifizierung — AgentCore Identity verwaltet OAuth-Anmeldeinformationen und API-Schlüssel sicher und verhindert so, dass Anmeldeinformationen im Agentencode oder in Protokollen offengelegt werden. Verwenden Sie es für den gesamten Zugriff auf Dienste von Drittanbietern (Slack, Zoom). GitHub

• Machen Sie sich mit der Offenlegung von MMDS-Anmeldeinformationen vertraut — Der MicroVM Metadata Service (MMDS) stellt Anmeldeinformationen für die Ausführungsrolle für jeden Code bereit, der auf der VM ausgeführt wird, ähnlich wie das IMDS von EC2. Richten Sie die Berechtigungen für Ausführungsrollen nur auf das ein, was Ihr Agent benötigt.

• MMDSv2 aktivieren — Ab dem 30. Juni 2026 muss für Ihre Agentenlaufzeiten MMDSv2 aktiviert sein. Laufzeiten ohne aktiviertes MMDSv2 können nicht aufgerufen werden und geben a zurück. ValidationException Rufen Sie zur Aktivierung UpdateAgentRuntime mit requireMMDSV2 der Einstellung „In“ auf. true metadataConfiguration Weitere Informationen zur Behebung dieses Fehlers finden Sie unter ValidationException MMDSv2-Fehlerbehebung.

• Container als Nicht-Root-Benutzer ausführen — Wenn Sie benutzerdefinierte Container-Images erstellen, konfigurieren Sie sie so, dass sie als Nicht-Root-Benutzer ausgeführt werden. Dadurch werden die Auswirkungen potenzieller Sicherheitslücken bei der Codeausführung begrenzt.

• Separate vom Benutzer delegierte und autonome Anmeldeinformationen — Verwenden Sie die vom Benutzer delegierte Authentifizierung (Authorization Code Grant), wenn Ihr Agent im Namen eines bestimmten Benutzers handelt. Verwenden Sie die autonome Authentifizierung (Client Credentials Grant), wenn der Agent unabhängig arbeitet.

• Bereitstellen von Laufzeiten in einer VPC für den Zugriff auf private Ressourcen — Konfigurieren Sie die VPC-Konnektivität für den Zugriff auf private Datenbanken, interne APIs und Dienste, ohne sie dem Internet auszusetzen. Einzelheiten zur Konfiguration finden Sie unter AgentCore Runtime für VPC konfigurieren.

• AWS PrivateLink Für API-Zugriff verwenden — Erstellen Sie VPC-Schnittstellen-Endpunkte für die AgentCore Datenebene (com.amazonaws.region.bedrock-agentcore) und die Steuerungsebene (), um com.amazonaws.region.bedrock-agentcore-control Internet-Traversal zu vermeiden. Weitere Informationen finden Sie unter Verwenden. AWS PrivateLink

• Sicherheitsgruppen die geringsten Rechte zuweisen — Definieren Sie Regeln für ausgehenden Datenverkehr, die nur den minimal erforderlichen Datenverkehr zulassen. Öffnen Sie keinen breiten ausgehenden Zugriff, es sei denn, dies ist erforderlich.

• Erforderliche VPC-Endpunkte für Container-Agenten konfigurieren — Für VPC-mode Container-Agenten konfigurieren Sie VPC-Endpunkte für ECR (com.amazonaws.region.ecr.dkr,com.amazonaws.region.ecr.api), S3 (com.amazonaws.region.s3Gateway-Endpunkt) und Logs (). CloudWatch com.amazonaws.region.logs Durch den S3-Gateway-Endpunkt fallen keine NAT-Gateway-Datenverarbeitungsgebühren für ECR-Image-Layer-Abrufe an.

• Geltungsbereich der S3-Gateway-Endpunktrichtlinie für Container-Agenten — Beschränken Sie die S3-Gateway-Endpunktrichtlinie auf den Bucket, den Amazon ECR für die Speicherung der Bildebene verwendet:

  {
    "Statement": [
      {
        "Sid": "AllowECRLayerAccess",
        "Principal": "*",
        "Action": [
          "s3:GetObject"
        ],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::prod-region-starport-layer-bucket/*"]
      }
    ]
  }

  regionErsetzen Sie es durch Ihre AWS Regionskennung (z. B.us-east-2).

• Geltungsbereich der S3-Gateway-Endpunktrichtlinie für Agenten zur direkten Codebereitstellung — Beschränken Sie die Richtlinie bei ZIP-basierten Bereitstellungen auf den internen, diensteigenen Code-Artefakt-Bucket. Fügen Sie eine aws:PrincipalServiceName Bedingung hinzu, um sicherzustellen, dass nur der AgentCore Service Principal über diese Endpunktrichtlinie auf Buckets zugreifen kann:

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": [
          "arn:aws:s3:::acr-code-*-region-an",
          "arn:aws:s3:::acr-code-*-region-an/*"
        ],
        "Condition": {
          "StringEquals": {
            "aws:PrincipalServiceName": "bedrock-agentcore.amazonaws.com"
          }
        }
      }
    ]
  }

  regionErsetzen Sie es durch Ihre AWS Regionskennung (z. B.us-west-2). Die AgentCore Code-Artefakt-Buckets werden in Allzweck-Buckets für den regionalen Kontonamespace erstellt. AWS Kann nur die tatsächlichen Bucket-Namen besitzen, die vom Dienst verwendet werden. Die aws:PrincipalServiceName Bedingung stellt sicher, dass nur der AgentCore Dienstprinzipal über diese Endpunktrichtlinie auf Buckets zugreifen kann. Wenn Sie auch persistente Dateisysteme verwenden, fügen Sie den Sitzungsspeicher-Bucket zu dieser Richtlinie hinzu. Weitere Informationen finden Sie unter AgentCore Runtime for VPC konfigurieren.

• Verwenden Sie private Subnetze mit NAT-Gateways — Öffentliche Subnetze bieten für Runtime keinen Internetzugang. AgentCore Platzieren Sie Runtime-ENIs immer in privaten Subnetzen mit einer Route zu einem NAT-Gateway für ausgehenden Internetzugang.

• Transportsicherheit — Alle Verbindungen verwenden TLS 1.2 oder höher. WebSocket Verbindungen, einschließlichInvokeAgentRuntimeCommandShell, verwenden ausschließlich WSS (WebSocket Secure) über HTTPS. ws://Klartext-Verbindungen werden nicht unterstützt.

• Header-Grenzwerte durchsetzen — Benutzerdefinierte Header sind auf 4 KB pro Wert und 20 Header pro Laufzeit begrenzt. Der Authorization Header ist Agenten mit eingehendem OAuth-Zugriff vorbehalten.

• Verschlüsselung bei der Übertragung — Die gesamte Kommunikation zwischen Clients und AgentCore Runtime sowie zwischen AgentCore Runtime und ihren Abhängigkeiten ist mit TLS 1.2 oder höher geschützt. Dies ist standardmäßig konfiguriert und erfordert keine zusätzliche Einrichtung.

• Verschlüsselung im Ruhezustand — Daten im Ruhezustand werden standardmäßig AWS mit eigenen Verschlüsselungsschlüsseln vom AWS Key Management Service (AWS KMS) verschlüsselt.

• Verwenden Sie nach Möglichkeit TLS 1.3 — TLS 1.2 ist zwar das Minimum, AWS empfiehlt aber TLS 1.3 für mehr Sicherheit und Leistung.

• CloudTrail Protokollierung aktivieren — AWS CloudTrail zeichnet API-Aufrufe aufInvokeAgentRuntime, einschließlich, InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, und Operationen auf der Steuerungsebene. Jeder Datensatz enthält die Identität des Anrufers, den Zeitstempel, die Quell-IP-Adresse und den Antwortstatus.

• Verwenden Sie CloudWatch Protokolle für die Befehlsüberwachung — AgentCore Runtime sendet die Anforderungs-ID und den Eingabebefehl an die Protokollgruppe CloudWatch Logs Ihres Agenten. Verwenden Sie diese Protokolle, um einen Prüfpfad der Befehle zu führen, die in Ihren Sitzungen ausgeführt wurden.

• Logs anhand von Anfrage-IDs korrelieren — Verwenden Sie die Anfrage-ID, um CloudTrail Datensätze (wer hat die API aufgerufen) mit CloudWatch Logs (welcher Befehl wurde ausgeführt) zu korrelieren.

• Metrikfilter und Alarme einrichten — Konfigurieren Sie Metrikfilter für CloudWatch Logs, um unerwartete Befehlsmuster oder unbefugte Zugriffsversuche zu erkennen. Erstellen Sie Alarme, um Ihr Team über Anomalien zu informieren.

• Delegierungsbeziehungen mit Benutzer-IDs protokollieren — Wenn Sie den X-Amzn-Bedrock-AgentCore-Runtime-User-Id Header verwenden, protokollieren Sie zu Prüfungszwecken die Beziehung zwischen dem authentifizierten IAM-Prinzipal und dem Benutzer-ID-Wert.

• VPC Flow Logs aktivieren — Aktivieren Sie für VPC-connected Laufzeiten VPC Flow Logs, um den Datenverkehr auf Netzwerkebene zu prüfen und unerwartete Kommunikationsmuster zu identifizieren.

• Regelmäßige Überprüfung der CloudTrail Protokolle — Überprüfen Sie die Protokolle regelmäßig auf unbefugte Zugriffsversuche, insbesondere bei sensiblen Workloads.

AWS Verantwortlichkeiten:

• Sichere Infrastruktur und MicroVM-Isolierung auf Hardwareebene

• Betriebssystem-Kernel-Patching für alle Bereitstellungsmodi

• Sprach-Runtime-Patching für direkte Codebereitstellungen

• Sicherheit der Netzwerkinfrastruktur

• Verfügbarkeit und Belastbarkeit von Diensten

Ihre Aufgaben:

• Sicherheit des Agentencodes und Verwaltung von Abhängigkeiten

• IAM-Zugriffskontrollen und Ressourcenrichtlinien

• Sicherheit von Befehlen, die in Runtime-Sitzungen ausgeführt werden

• Session-to-user Durchsetzung von Kartenergebnissen

• Container-Image-Updates (für Container-Bereitstellungen) — führen Sie regelmäßig eine Neuerstellung mit dem neuesten sicheren Basis-Image durch

• Eingabevalidierung und Verhinderung einer sofortigen Injektion — einschließlich der Validierung von InvokeHarness Eingaben bei Verwendung des verwalteten Harness (siehe Harness teilt die AgentCore Runtime-Vertrauensgrenze)

• Netzwerkkonfiguration (Sicherheitsgruppen, VPC-Endpunkte, Routing-Tabellen)

• InvokeAgentRuntimeCommand— One-shot, nicht interaktive Befehlsausführung beendet HTTP/2. IAM-Aktion:. bedrock-agentcore:InvokeAgentRuntimeCommand

• InvokeAgentRuntimeCommandShell— Interaktive WebSocket Shell-Sitzung mit persistentem PTY-Zugriff. IAM-Aktion:. bedrock-agentcore:InvokeAgentRuntimeCommandShell

• Machen Sie sich mit den Sicherheitsgrenzen vertraut — Befehle haben vollen Zugriff auf das Container-Dateisystem und alle konfigurierten Anmeldeinformationen oder Geheimnisse innerhalb der MicroVM. Die Isolationsgrenze ist die MicroVM selbst. Im Rahmen des Modells der gemeinsamen Verantwortung sind Sie für die Sicherheit des Codes verantwortlich, der in Ihrem Runtime-Container ausgeführt wird.

• Verwenden Sie deterministische Operationen für deterministische Aufgaben — Verwenden Sie InvokeAgentRuntimeCommand oder InvokeAgentRuntimeCommandShell für Operationen wie Tests, Git und Builds. Leitet deterministische Operationen nicht über das LLM weiter. InvokeAgentRuntime

• Beschränken Sie, wer Befehle ausführen kann — Verwenden Sie IAM-Richtlinien, um einzuschränken, welche Principals aufrufen können oder. InvokeAgentRuntimeCommand InvokeAgentRuntimeCommandShell Nicht alle Benutzer, die einen Agenten aufrufen können, sollten in der Lage sein, beliebige Befehle auszuführen. Beispiel für einen Ressourcen-ARN:arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent.

• WebSocket Shell verwendet nur wss://— InvokeAgentRuntimeCommandShell Verbindungen werden ausschließlich über WSS (WebSocket Secure) hergestellt. ws://Klartext-Verbindungen werden nicht unterstützt. Anrufer authentifizieren sich beim Upgrade über Sigv4. WebSocket

• Halten Sie den Datenverkehr in Ihrem Netzwerk aufrecht — Konfigurieren Sie VPC-Endpunkte, um Internet-Traversal bei API-Aufrufen zur Befehlsausführung zu vermeiden.

• Legen Sie angemessene Timeouts fest — Konfigurieren Sie Befehls-Timeouts auf der Grundlage der erwarteten Ausführungsdauer, um eine Verschwendung von Ressourcen durch außer Kontrolle geratene Prozesse zu verhindern.

• Den Localhost-Zugriff im Agentencode einschränken — Konfigurieren Sie Ihren Agenten und alle Netzwerktools so, dass ein uneingeschränkter Zugriff auf Localhost verhindert wird. Der Agentencode sollte keine willkürlichen HTTP-Aufrufe an localhost tätigen, es sei denn, dies ist für eine bestimmte Integration erforderlich.

• Nur erforderliche Ports für Sidecar-Setups zulassen — Wenn Ihre Architektur auf Localhost ein Container-in-Container- oder Sidecar-Muster verwendet, sollten Sie explizit nur die spezifischen Ports zulassen, die Ihre Sidecar-Dienste verwenden. Öffnen Sie keinen breiten Localhost-Zugriff.

• Überprüfen Sie die Reichweite von Netzwerktools auf Localhost — Überprüfen Sie alle Tools, die Sie Ihrem Agenten zur Verfügung stellen (z. B. HTTP-Request-Tools oder allgemeine Netzwerkdienstprogramme), um sicherzustellen, dass keine unbeabsichtigten Anfragen an Localhost-Endpunkte gestellt werden. Wenden Sie URL-Filter oder Zulassungslisten auf Toolebene an.