Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Organisationen können ihren Copilot Studio-Agents eine Sicherheitsebene hinzufügen, indem sie sie mit einem Laufzeit-Bedrohungserkennungssystem verbinden. Nach der Verbindung ruft der Agent dieses System zur Laufzeit auf. Der Agent stellt das System mit Daten bereit, damit das System ermitteln kann, ob ein Tool, das der Agent aufruft, legitim ist oder nicht. Das System antwortet dann auf Copilot Studio mit einer Antwort von "genehmigen" oder "blockieren", wodurch der Agent das Tool aufruft oder überspringt. Weitere Informationen zum Verbinden von Agents mit einem vorhandenen externen Bedrohungserkennungssystem finden Sie unter Enable external threat detection and protection for Copilot Studio custom agents.
Dieser Artikel richtet sich an Entwickler und beschreibt, wie Sie Ihre eigenen Bedrohungserkennungsfunktionen als Sicherheitsanbieter für Copilot Studio-Agents integrieren.
Die Integration basiert auf einer API, die aus zwei Endpunkten besteht. Der Hauptendpunkt, den Sie implementieren müssen, ist der analyze-tool-execution Endpunkt. Sie müssen diesen Endpunkt als Schnittstelle für Ihr Bedrohungserkennungssystem verfügbar machen. Sobald Kunden Ihr System als externes Bedrohungserkennungssystem konfigurieren, ruft der Agent diese API jedes Mal auf, wenn es ein Tool aufrufen möchte.
Neben dem analyze-tool-execution Endpunkt müssen Sie auch einen zweiten Endpunkt verfügbar machen, der aufgerufen wird validate. Der validate Endpunkt wird verwendet, um den Status und die Bereitschaft des Endpunkts im Rahmen der Systemeinrichtung zu überprüfen.
In den folgenden Abschnitten werden die einzelnen Endpunkte ausführlich beschrieben.
POST /validate
Zweck: Überprüft, ob der Endpunkt für die Bedrohungserkennung erreichbar und funktioniert. Wird für anfängliche Setup- und Konfigurationstests verwendet.
Überprüfen der Anforderung
Methode: BEREITSTELLEN
URL:
https://{threat detection endpoint}/validate?api-version=2025-05-01Kopfzeile:
Autorisierung: Bearertoken für DIE API-Authentifizierung
x-ms-correlation-id: GUID für die Ablaufverfolgung
Körper: Leer
Überprüfen der Antwort
200 OK-Antwortbeispiel
{
"isSuccessful": true,
"status": "OK"
}
Beispiel für Fehlerantwort
Wenn ein Fehler auftritt (nicht erfolgreicher HTTP-Code), gibt der Endpunkt einen Fehlercode, eine Meldung und optionale Diagnose zurück.
{
"errorCode": 5031,
"message": "Validation failed. Webhook service is temporarily unavailable.",
"httpStatus": 503,
"diagnostics": "{\\reason\\:\\Upstream dependency timeout\\}"
}
POST /analyze-tool-execution
Zweck: Sendet den Toolausführungskontext für die Risikobewertung. Wertet die Toolausführungsanforderung aus und antwortet, ob die Ausführung des Tools zugelassen oder blockiert werden soll.
Analysetoolausführungsanforderung
Methode: BEREITSTELLEN
URL:
https://{threat detection endpoint}/analyze-tool-execution?api-version=2025-05-01Kopfzeile:
- Autorisierung: Bearertoken für DIE API-Authentifizierung
- Content-Type: application/json
Körper: JSON-Objekt
Beispiel für analyse-tool-execution-Anforderung
POST https://security.contoso.com/api/agentSecurity/analyze-tool-execution?api-version=2025-05-01
Authorization: Bearer XXX……
x-ms-correlation-id: fbac57f1-3b19-4a2b-b69f-a1f2f2c5cc3c
Content-Type: application/json
{
"plannerContext": {
"userMessage": "Send an email to the customer",
"thought": "User wants to notify customer",
"chatHistory": [
{
"id": "m1",
"role": "user",
"content": "Send an email to the customer",
"timestamp": "2025-05-25T08:00:00Z"
},
{
"id": "m2",
"role": "assistant",
"content": "Which customer should I email?",
"timestamp": "2025-05-25T08:00:01Z"
},
{
"id": "m3",
"role": "user",
"content": "The customer is John Doe",
"timestamp": "2025-05-25T08:00:02Z"
}
],
"previousToolOutputs": [
{
"toolId": "tool-123",
"toolName": "Get customer email by name",
"outputs": {
"name": "email",
"description": "Customer's email address",
"type": {
"$kind": "String"
},
"value": "customer@foobar.com"
},
"timestamp": "2025-05-25T08:00:02Z"
}
]
},
"toolDefinition": {
"id": "tool-123",
"type": "PrebuiltToolDefinition",
"name": "Send email",
"description": "Sends an email to specified recipients.",
"inputParameters": [
{
"name": "to",
"description": "Receiver of the email",
"type": {
"$kind": "String"
}
},
{
"name": "bcc",
"description": "BCC of the email",
"type": {
"$kind": "String"
}
}
],
"outputParameters": [
{
"name": "result",
"description": "Result",
"type": {
"$kind": "String"
}
}
]
},
"inputValues": {
"to": "customer@foobar.com",
"bcc": "hacker@evil.com"
},
"conversationMetadata": {
"agent": {
"id": "agent-guid",
"tenantId": "tenant-guid",
"environmentId": "env-guid",
"isPublished": true
},
"user": {
"id": "user-guid",
"tenantId": "tenant-guid"
},
"trigger": {
"id": "trigger-guid",
"schemaName": "trigger-schema"
},
"conversationId": "conv-id",
"planId": "plan-guid",
"planStepId": "step-1"
}
}
Analysetoolausführungsantwort
200 OK (Anforderung erfolgreich)
Wenn die Anforderung gültig ist, wird die in der Anforderung angegebene Toolverwendung basierend auf den definierten Kriterien ausgewertet und entweder zugelassen oder blockiert. Die Antwort kann die folgenden Felder enthalten:
- blockAction (Boolean): Gibt an, ob die Aktion blockiert werden soll.
- reasonCode (ganze Zahl, optional): Numerischer Code, der den Grund für den Block erklärt
- Reason (Zeichenfolge, optional): Menschlichen lesbaren Erklärung
- Diagnose (Objekt, optional): Weitere Details zur Ablaufverfolgung oder zum Debuggen
Beispiel für antwort zulassen
{
"blockAction": false
}
Beispiel für eine Blockantwort
{
"blockAction": true,
"reasonCode": 112,
"reason": "The action was blocked because there is a noncompliant email address in the BCC field.",
"diagnostics": "{\\flaggedField\\:\\bcc\\,\\flaggedValue\\:\\hacker@evil.com\\}"
}
Beispielfehlerantwort
Wenn die Anforderung ungültig ist, wird eine Fehlerantwort mit einem Fehlercode, einer Nachricht, einem HTTP-Status und einer optionalen Diagnose zurückgegeben.
{
"errorCode": 4001,
"message": "Missing required field: toolDefinition",
"httpStatus": 400,
"diagnostics": "{\\missingField\\:\\toolDefinition\\,\\traceId\\:\\abc-123\\}"
}
Referenz zu Anforderungs- und Antworttextstrukturen
In den folgenden Tabellen werden die Inhalte verschiedener Objekte beschrieben, die in den Anforderungs- und Antworttexten für die Endpunkte verwendet werden.
ValidationResponse
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| isSuccessful | Boolean | Yes | Gibt an, ob die Überprüfung bestanden wurde. |
| status | Schnur | Yes | Optionale Statusmeldung oder partnerspezifische Details. |
AnalyzeToolExecutionResponse
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| blockAction | Boolean | Yes | Gibt an, ob die Aktion blockiert werden soll. |
| Grundcode | Integer | Nein | Optionaler numerischer Grundcode, der vom Partner bestimmt wird. |
| Grund | Schnur | Nein | Optionale, vom Menschen lesbare Erklärung. |
| diagnostics | Schnur | Nein | Optionale Freihandform-Diagnoseinformationen zum Debuggen oder Telemetrie. Muss vorserialisiert werden. |
ErrorResponse
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| Fehlercode | Integer | Yes | Numerischer Bezeichner für den Fehler (z. B. 1001 = fehlendes Feld, 2003 = Authentifizierungsfehler). |
| message | Schnur | Yes | Die vom Menschen lesbare Erklärung des Fehlers. |
| httpStatus (Englisch) | Integer | Yes | HTTP-Statuscode, der vom Partner zurückgegeben wird. |
| diagnostics | Schnur | Nein | Optionale Freihandform-Diagnoseinformationen zum Debuggen oder Telemetrie. Muss vorserialisiert werden. |
EvaluationRequest
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| plannerContext | PlannerContext | Yes | Planner-Kontextdaten. |
| toolDefinition | ToolDefinition | Yes | Details zur Tooldefinition. |
| inputValues | JSON-Objekt | Yes | Wörterbuch der Schlüsselwertpaare, die für das Tool bereitgestellt werden. |
| conversationMetadata | ConversationMetadata | Yes | Metadaten zum Unterhaltungskontext, zum Benutzer und zum Planen der Nachverfolgung. |
PlannerContext
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| Benutzernachricht | Schnur | Yes | Die ursprüngliche Nachricht, die vom Agent gesendet wurde. |
| Gedanke | Schnur | Nein | Planner-Erklärung, warum dieses Tool ausgewählt wurde. |
| chatHistory | ChatMessage[] | Nein | Liste der zuletzt ausgetauschten Chatnachrichten mit dem Benutzer. |
| previousToolsOutputs | ToolExecutionOutput[] | Nein | Liste der zuletzt verwendeten Toolausgaben. |
ChatMessage
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| id | Schnur | Yes | Eindeutiger Bezeichner für diese Nachricht in der Unterhaltung. |
| role | Schnur | Yes | Quelle der Nachricht (z. B. Benutzer, Assistent). |
| Inhalt | Schnur | Yes | Der Nachrichtentext. |
| Zeitstempel | Zeichenfolge (Datum-Uhrzeit) | Nein | ISO 8601-Zeitstempel, der angibt, wann die Nachricht gesendet wurde. |
ToolExecutionOutputs
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| toolId | Schnur | Yes | Eindeutiger Bezeichner für diese Nachricht in der Unterhaltung. |
| toolName | Schnur | Yes | Name des Tools. |
| Ergebnisse | ExecutionOutput[] | Yes | Liste der Toolausführungsausgaben. |
| Zeitstempel | Zeichenfolge (Datum-Uhrzeit) | Nein | ISO 8601-Zeitstempel, der angibt, wann die Toolausführung abgeschlossen wurde. |
ExecutionOutput
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| name | Schnur | Yes | Name des Ausgabeparameters. |
| Beschreibung | Schnur | Nein | Erläuterung für den Ausgabewert. |
| type | Objekt | Nein | Datentyp der Ausgabe. |
| value | JSON-Datenwert | Yes | Der Ausgabewert. |
ToolDefinition
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| id | Schnur | Yes | Eindeutiger Bezeichner des Tools. |
| type | Schnur | Yes | Gibt die Art des Tools an, das im Planner verwendet wird. |
| name | Schnur | Yes | Lesbarer Name des Tools. |
| Beschreibung | Schnur | Yes | Zusammenfassung der Funktionsweise des Tools. |
| inputParameters | ToolInput[] | Nein | Eingabeparameter des Tools. |
| outputParameters | ToolOutput[] | Nein | Ausgabeparameter, die das Tool nach der Ausführung zurückgibt. |
ToolInput
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| name | Schnur | Yes | Name des Eingabeparameters. |
| Beschreibung | Schnur | Nein | Erläuterung des erwarteten Werts für diesen Eingabeparameter. |
| type | JSON-Objekt | Nein | Datentyp des Eingabeparameters. |
ToolOutput
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| name | Schnur | Yes | Name des Ausgabeparameters. |
| Beschreibung | Schnur | Nein | Erläuterung des Ausgabewerts. |
| type | JSON-Objekt | Nein | Typ des Ausgabewerts. |
ConversationMetadata
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| Agent | AgentContext | Yes | Agentkontextinformationen. |
| user | UserContext | Nein | Informationen zum Benutzer, der mit dem Agent interagiert. |
| trigger | TriggerContext | Nein | Informationen dazu, was die Planner-Ausführung ausgelöst hat. |
| conversationId | Schnur | Yes | ID der laufenden Unterhaltung. |
| planId | Schnur | Nein | ID des Plans, der zur Erfüllung der Benutzeranforderung verwendet wird. |
| planStepId | Schnur | Nein | Schritt innerhalb des Plans, der dieser Toolausführung entspricht. |
| parentAgentComponentId | Schnur | Nein | ID der übergeordneten Agentkomponente. |
AgentContext
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| id | Schnur | Yes | ID des Agents. |
| tenantId | Schnur | Yes | Mandant, in dem sich der Agent befindet. |
| environmentId | Schnur | Yes | Umgebung, in der der Agent veröffentlicht wird. |
| Ausgabe | Schnur | Nein | Agentversion (optional, wenn isPublished falsch). |
| IsPublished | Boolean | Yes | Gibt an, ob dieser Ausführungskontext eine veröffentlichte Version ist. |
UserContext
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| id | Schnur | Nein | Microsoft Entra-Objekt-ID des Benutzers. |
| tenantId | Schnur | Nein | Mandanten-ID des Benutzers. |
TriggerContext
| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
| id | Schnur | Nein | Die ID des Triggers, der den Planner ausgelöst hat. |
| schemaName | Schnur | Nein | Der Name des Triggerschemas, das den Planner ausgelöst hat. |
Authentifizierung
Die integration, die Sie entwickeln, sollte die Microsoft Entra ID-Authentifizierung verwenden. Befolgen Sie die Anweisungen zum Integrieren von Apps, die Ihre Entwickler erstellen.
Schritte, die sie ausführen müssen, umfassen Folgendes:
- Erstellen Sie eine App-Registrierung für Ihre Ressource in Ihrem Mandanten.
-
Machen Sie einen Bereich für Ihre Web-API verfügbar. Der verfügbar gemachte Bereich muss die Basis-URL für die Ressource sein, die der Kunden aufruft. Wenn die API-URL beispielsweise lautet
https://security.contoso.com/api/threatdetection, musshttps://security.contoso.comder verfügbar gemachte Bereich sein. - Je nachdem, wie Sie Ihren Dienst implementieren, müssen Sie Autorisierungslogik implementieren und eingehende Token überprüfen. Sie müssen dokumentieren, wie der Kunde seine Apps autorisieren muss. Dazu gibt es mehrere Möglichkeiten, z. B. eine Zulassungsliste von App-IDs oder rollenbasierte Zugriffssteuerung (RBAC) zu verwenden.
Antwortzeitanforderungen
Der Agent erwartet eine Antwort vom Bedrohungserkennungssystem innerhalb von weniger als 1.000 ms. Sie sollten sicherstellen, dass Ihr Endpunkt innerhalb dieses Zeitrahmens auf den Anruf antwortet. Wenn Ihr System nicht rechtzeitig reagiert, verhält sich der Agent so, als ob Ihre Antwort "zulassen" ist und das Tool aufruft.
API-Versionsverwaltung
In Anforderungen wird die API-Version über einen api-version Abfrageparameter angegeben (z. B api-version=2025-05-01. ). Ihre Implementierung sollte gegenüber anderen unerwarteten Feldern tolerant sein und sollte nicht fehlschlagen, wenn in Zukunft neue Werte hinzugefügt werden. Partner sollten die API-Version nicht überprüfen, da derzeit alle Versionen als nicht unterbrechend betrachtet werden. Partner sollten die API-Versionen nachverfolgen, die Anforderung jedoch nicht fehlschlagen, um eine neue Version zu sehen.