AutoDocBot V2

AutoDocBot V2 ist ein End-to-End-verifizierter Proof of Concept für einen Copilot-Agenten, der frei formulierte Prozessbeschreibungen in konsistente Confluence-Prozessartikel umwandelt. Der Agent strukturiert den Inhalt, wendet einen verbindlichen und zugleich anpassbaren Styleguide an, erzeugt ein SVG-Prozessdiagramm und veröffentlicht den bestätigten Artikel über einen MCP-Server im Namen des angemeldeten Atlassian-Benutzers.

Dokumentationsstand: 25. August 2026, Version 0.1.6. Lokaler Betrieb, Atlassian OAuth 2.0 (3LO), MCP Streamable HTTP, Microsoft-Entra-Authentifizierung, Copilot Studio, semantische Vorprüfung, agentengesteuerte Strukturreparatur, verschlüsselte Benutzerverbindungen, ein fest begrenzter Ziel-Space, einmal verwendbare Kontoverknüpfungslinks, Adaptive-Card-Bestätigung im Chat, Azure Container Apps sowie die bestätigte Veröffentlichung eines Artikels mit SVG-Diagramm wurden praktisch verifiziert.

Diese README beschreibt Zielbild, Architektur, Funktionsweise und Sicherheitsmodell. Die ausführbaren Schritte für Installation, Konfiguration, Freigabe und Betrieb stehen separat in Bereitstellung und Betrieb.

Inhaltsverzeichnis

• Zielbild

• Funktionsumfang

• Verifizierter End-to-End-Stand

• Präsentations- und Onboarding-Unterlagen

• Architektur

• ELI5-Glossar

• Ablauf aus Benutzersicht

• Projektstruktur

• MCP-Tools

• ArticleSpec und Styleguide

• Authentifizierung und Sicherheit

• Bekannte PoC-Grenzen

• Weiterentwicklung

• Lizenz

• Bereitstellung und Betrieb

Related MCP server: MCP Atlassian

Zielbild

Der Benutzer soll im Copilot-Chat nur den fachlichen Prozess beschreiben müssen, zum Beispiel:

Wenn ein neuer Mitarbeiter eingestellt wird, meldet HR den Eintritt mindestens fünf Arbeitstage vorher an die IT. Die IT erstellt das Benutzerkonto und bereitet einen gereinigten Laptop vor. Fehlen Pflichtangaben, geht die Anfrage zurück an HR. Am ersten Arbeitstag übergibt die Führungskraft die Arbeitsmittel. Das Diagramm soll von oben nach unten verlaufen.

Der Copilot-Agent übernimmt daraus folgende Aufgaben:

1. Fakten, Rollen, Prozessschritte, Entscheidungen und Ausnahmen erkennen.

2. Fehlende fachliche Pflichtangaben beim Benutzer erfragen, statt sie zu erfinden.

3. Den Inhalt als validiertes ArticleSpec strukturieren.

4. Styleguide und erlaubte Benutzeranpassungen anwenden.

5. Eine Vorschau erzeugen und dem Benutzer zur Bestätigung zeigen.

6. Erst nach ausdrücklicher Bestätigung den Artikel veröffentlichen.

7. Ein SVG-Diagramm erzeugen, an die Confluence-Seite anhängen und als letzten Abschnitt einbetten.

Funktionsumfang

• MCP-Server auf Basis von Streamable HTTP

• vier klar getrennte MCP-Tools für Verbindung, Styleguide, Vorschau und Veröffentlichung

• Atlassian OAuth 2.0 (3LO) mit Benutzerdelegation und Refresh Tokens

• Veröffentlichung unter der Identität des verbundenen Atlassian-Benutzers

• Ziel-Site-Prüfung und ausschließliche Veröffentlichung im fest konfigurierten Ziel-Space

• strukturierte, mit Zod validierte Artikeldaten

• deterministisches Confluence-Storage-Format statt ungeprüftem Modell-HTML

• flexibler Styleguide mit unveränderbaren Sicherheits- und Qualitätsregeln

• Diagramme in den Richtungen top-down und left-right

• Vorschau vor jeder Veröffentlichung; Vorschau-IDs sind 30 Minuten gültig und nur für einen Veröffentlichungsversuch verwendbar

• präsentationsfertige Vorschauwerte für eine interaktive Bestätigungs- und Abbruchkarte im Copilot-Chat

• fachliche Seitentitel ohne technischen PoC- oder Zeitstempel-Zusatz

• zentrale MCP-Agentenanweisungen für Ableitung, Rückfragen, Vorschau und Veröffentlichungsbestätigung

• Microsoft-Entra-Prüfung für produktive MCP-Aufrufe

• pro Benutzer getrennte, AES-256-GCM-verschlüsselte Atlassian-Verbindungen

• Container-Image und persistenter Token Store für Azure Container Apps

Nicht Bestandteil dieses PoC sind eine Administrationsoberfläche, eine Datenbank, Versionsverwaltung für individuelle Styleguides und eine vollständig automatisierte Infrastruktur-Pipeline.

Verifizierter End-to-End-Stand

Der Stand belegt die technische Machbarkeit. Die unter Bekannte PoC-Grenzen genannten Punkte bleiben vor einem breiten Produktivbetrieb relevant.

Präsentations- und Onboarding-Unterlagen

• Bereitstellung und Betrieb – lokale Einrichtung, Atlassian- und Entra-Konfiguration, Copilot-Anbindung, Azure-Deployment, Tests und Fehlerbehebung

• Projektbeschreibung für die Vorstellung – verständlicher Überblick über Problem, Nutzen, Ablauf, Architektur, Sicherheitsprinzipien und aktuellen Reifegrad

• Onboarding eines neuen Testusers – ausführbare Checkliste für Microsoft-Zugriff, MCP-Verbindung, Atlassian-Autorisierung, Abnahmetest und Offboarding im aktuellen Cross-Tenant-PoC

Architektur

Die folgenden Abbildungen dokumentieren den tatsächlich getesteten Cross-Tenant-PoC, nicht die später angestrebte Produktivarchitektur. Der Agent und der Teams-Chat liegen im Provectus-Standard-Tenant; Entra-App-Registrierungen und MCP-Server liegen im Provectus-Lab-Tenant. Deshalb benötigt der aktuelle PoC je Testbenutzer eine persönliche Power-Platform-Verbindung mit einer im Lab-Tenant authentifizierbaren Identität. Der vorbereitete SSO-/OBO-Connector ist noch nicht aktiv.

Gesamtübersicht

Microsoft-Cross-Tenant-Authentifizierung

Atlassian-Autorisierung und Publishing

Die Quelldatei mit allen drei bearbeitbaren Draw.io-Seiten liegt unter docs/autodocbot-cross-tenant-architecture.drawio. Die SVG-Dateien unter docs/architecture/ sind die für GitHub und diese README exportierten Ansichten.

Es existieren zwei voneinander getrennte OAuth-Beziehungen:

1. Power Platform → MCP-Server: Microsoft Entra im Lab-Tenant stellt ein delegiertes Access Token für die AutoDocBot-API aus. Der MCP-Server prüft Signatur, Issuer, Audience, Tenant, Benutzer, Scope und erlaubte Client-Anwendung. Im aktuellen Cross-Tenant-PoC wird die zugehörige persönliche Power-Platform-Verbindung beim ersten Toolaufruf manuell hergestellt.

2. MCP-Server → Atlassian: Der Benutzer verbindet sein Atlassian-Konto separat per OAuth 2.0 (3LO). AutoDocBot verwendet dieses Benutzertoken für Confluence-Aufrufe.

Dadurch erhält AutoDocBot weder ein globales Confluence-Servicekonto noch die Berechtigung, unabhängig vom jeweiligen Benutzer zu veröffentlichen. Die Adaptive Card bildet eine dritte, davon getrennte Freigabe: Sie bestätigt genau die aktuell angezeigte Artikelvorschau.

ELI5-Glossar

Dieses Glossar erklärt die zentralen Spezialbegriffe des Projekts bewusst vereinfacht. Allgemeine Grundlagen wie HTTP, API, JSON, Git oder Docker werden nicht erneut erläutert.

Vertiefende Erklärungen stehen in den Abschnitten Authentifizierung und Sicherheit, ArticleSpec und Styleguide sowie Bekannte PoC-Grenzen.

Ablauf aus Benutzersicht

sequenceDiagram
    actor User as Benutzer
    participant Copilot
    participant MCP as AutoDocBot MCP
    participant Atlassian
    participant Confluence

    User->>Copilot: Prozess in normaler Sprache beschreiben
    Copilot->>MCP: get_confluence_connection
    alt Atlassian noch nicht verbunden
        MCP-->>Copilot: signierter Verknüpfungslink
        User->>Atlassian: OAuth-Zustimmung
        Atlassian-->>MCP: Authorization Code
        MCP-->>MCP: Token verschlüsselt je Benutzer speichern
    end
    Copilot->>MCP: get_article_styleguide
    Copilot->>MCP: preview_process_article(sourceText, articleJson, qualityReviewJson)
    MCP-->>Copilot: Vorschau, previewId und confirmationCardData
    Copilot-->>User: Adaptive Card mit Publish- und Abbruchbutton
    User->>Copilot: aktuelle Vorschau per Button bestätigen
    Copilot->>Copilot: cardInstanceId, Aktion und previewId prüfen
    Copilot->>MCP: publish_process_article(previewId, true)
    MCP->>Confluence: Seite erstellen
    MCP->>Confluence: SVG als Attachment hochladen
    MCP->>Confluence: Seite mit eingebettetem Diagramm aktualisieren
    Confluence-->>User: veröffentlichter Artikel

Projektstruktur

.
├── src/
│   ├── article/
│   │   ├── article-spec.ts          # Zod-Schema und fachliche Validierung
│   │   ├── quality-review.ts        # semantische Vorprüfung und Qualitätsbericht
│   │   ├── quality-review-check.ts  # automatisierter Konflikttest
│   │   ├── renderer.ts              # sicheres Confluence-Storage-Rendering
│   │   ├── styleguide.ts            # Standardregeln und erlaubte Overrides
│   │   ├── sample-process.ts        # Beispielprozess für lokale Tests
│   │   └── styleguide-check.ts      # automatisierter Rendering-Check
│   ├── auth/
│   │   ├── account-link.ts          # signierte, einmal verwendbare Verknüpfungslinks
│   │   ├── account-link-check.ts    # Manipulations- und Wiederverwendungstest
│   │   ├── encrypted-json-store.ts  # AES-256-GCM Token Store
│   │   ├── mcp-identity.ts          # Entra-JWT-Prüfung
│   │   └── store-check.ts           # Verschlüsselungstest
│   ├── diagram/
│   │   └── process-svg.ts           # deterministische SVG-Erzeugung
│   ├── mcp/
│   │   └── test-client.ts           # lokaler MCP-Protokolltest
│   └── server.ts                    # HTTP, OAuth, MCP und Publishing-Pipeline
├── docs/
│   ├── architecture/                # exportierte SVG-Architekturansichten
│   ├── autodocbot-cross-tenant-architecture.drawio # bearbeitbare Diagrammquelle
│   ├── styleguide.md                # lesbare Styleguide-Dokumentation
│   ├── copilot-agent-instructions.md # kopierfertige Studio-Anweisungen
│   ├── copilot-preview-confirmation-card.md # Adaptive-Card-Freigabe
│   ├── projektbeschreibung-management.md # verständliche Präsentationsunterlage
│   └── testuser-onboarding.md       # Testuser-Onboarding und Abnahmetest
├── connectors/
│   └── autodocbot-mcp.swagger.yaml  # vorbereiteter, noch inaktiver SSO-Connector
├── azure/containerapp-volume.yaml   # Beispiel für Azure File Mount und Runtime
├── BEREITSTELLUNG.md                # Einrichtung, Deployment und Betrieb
├── Dockerfile                       # Multi-Stage-Produktionsimage
├── .env.example                     # Konfigurationsvorlage
└── package.json

MCP-Tools

Der Streamable-HTTP-Endpunkt befindet sich unter /mcp und akzeptiert POST.

Vorgesehene Tool-Reihenfolge

1. get_confluence_connection

2. gegebenenfalls Atlassian-Verknüpfung durch den Benutzer

3. get_article_styleguide

4. fachliche Rückfragen stellen, bis keine relevanten Angaben fehlen

5. preview_process_article

6. Vorschau anzeigen und ausdrückliche Bestätigung einholen

7. publish_process_article mit confirmed: true

Für die Bestätigung direkt im Chat liefert die erfolgreiche Vorschau ab Version 0.1.6 zusätzlich confirmationCardData. Die vollständige Einrichtung des Copilot-Themas, die Power-Fx-Karte mit den Buttons Bestätigen und veröffentlichen sowie Ändern / abbrechen und die zugehörigen Abnahmetests sind in Artikelvorschau direkt im Chat bestätigen beschrieben.

Der Agent darf publish_process_article nicht automatisch direkt nach der Vorschau aufrufen. Der Server verlangt zwar den Literalwert confirmed: true, kann aber nicht unabhängig prüfen, ob die Bestätigung tatsächlich im Chat erteilt wurde. Das dedizierte Copilot-Thema wertet deshalb die eindeutige Kartenaktion aus und gibt die geprüfte Freigabe an die generative Orchestrierung zurück; diese ruft anschließend das MCP-Publishing-Tool auf. Serverseitig bleiben Benutzerbindung, Ablaufzeit und Einmalverwendung der Vorschau die maßgeblichen Schutzmechanismen. Eine revisionssichere Freigabehistorie ist weiterhin nicht Bestandteil des PoC.

ArticleSpec und Styleguide

Der Copilot erzeugt keinen fertigen HTML-Artikel. Stattdessen übergibt er drei flache String-Felder: den aktuellen konsolidierten Prozess als sourceText, strukturierte Artikeldaten als articleJson und den obligatorischen Qualitätsbericht als qualityReviewJson. Die Anzahl der Schritte leitet der Agent aus den beschriebenen Hauptaktionen ab; sie ist keine Benutzereingabe. Der MCP-Server prüft zuerst offene Qualitätsprobleme und parst anschließend articleJson als ArticleSpec. Die flachen Tool-Eingabefelder umgehen bekannte Schemaeinschränkungen in Copilot Studio, ohne die serverseitige Validierung aufzuweichen.

Semantische Vorprüfung

Der Qualitätsbericht enthält exakt diese Kategorien:

{
  "contradictions": [],
  "missingResponsibilities": [],
  "openQuestions": [],
  "assumptions": []
}

Jeder gefundene Eintrag besitzt finding und question. Zusätzlich prüft der Server den ProzessText auf explizite Unsicherheiten und typische Konflikte, etwa unbekannte Verantwortlichkeiten, unbestimmte Fristen, widersprüchliche Vorlaufzeiten oder zwei verschiedene Diagrammrichtungen.

Solange mindestens ein Problem offen ist, liefert das Vorschau-Tool:

status: clarification_required
previewCreated: false

Es wird keine previewId erzeugt. Der Agent stellt die gelieferten fachlichen Fragen und ruft das Tool erst mit einem durch die Benutzerantworten bereinigten ProzessText erneut auf. Diese deterministische Vorprüfung ergänzt die Modellbewertung; sie ist keine vollständige allgemeine Widerspruchserkennung.

Ist der konsolidierte Prozess fachlich eindeutig, aber articleJson noch unvollständig, antwortet das Tool nicht mit einem technischen Fehler. Stattdessen liefert es article_structure_retry_required, konkrete validationIssues und requiredArticleShape. Der Copilot-Agent versucht daraufhin, die Struktur zu reparieren und den Vorschauaufruf zu wiederholen. Der Server liefert dafür einen deterministischen Reparaturauftrag, die eigentliche inhaltliche Reparatur bleibt jedoch modellgesteuert.

Ein verkürztes Beispiel:

{
  "title": "Onboarding neuer Mitarbeitender",
  "summary": "Der Prozess beschreibt die Vorbereitung eines Neueintritts.",
  "purpose": "Konten und Arbeitsmittel stehen am ersten Arbeitstag bereit.",
  "scope": "Der Prozess gilt für neue interne Mitarbeitende.",
  "roles": [
    {
      "name": "HR",
      "responsibility": "Meldet den Eintritt vollständig und fristgerecht."
    },
    {
      "name": "IT",
      "responsibility": "Erstellt das Konto und bereitet den Laptop vor."
    }
  ],
  "prerequisites": ["Die erforderlichen Personaldaten liegen vor."],
  "steps": [
    {
      "number": 1,
      "actor": "HR",
      "action": "HR meldet den Eintritt mindestens fünf Arbeitstage vorher an die IT.",
      "result": "Die IT hat die Onboarding-Anfrage erhalten.",
      "decision": "Sind alle Pflichtangaben vorhanden?"
    }
  ],
  "exceptions": [
    {
      "condition": "Pflichtangaben fehlen.",
      "handling": "Die IT gibt die Anfrage zur Ergänzung an HR zurück."
    }
  ],
  "relatedLinks": [],
  "metadata": {
    "owner": "HR und IT"
  },
  "optionalContent": {},
  "style": {
    "tone": "concise",
    "audience": "operations",
    "diagramDirection": "top-down"
  }
}

Die vollständige Feldvalidierung steht in src/article/article-spec.ts. Unter anderem gelten folgende Grenzen:

• Titel: 5 bis 140 Zeichen

• mindestens eine Rolle und ein Prozessschritt

• maximal 30 Rollen, 50 Schritte und 30 Ausnahmen

• Schrittnummern beginnen bei 1 und müssen lückenlos sein

• URLs werden validiert

• unbekannte oder unzulässige Style-Overrides werden abgelehnt

Technisch erzwungene und agentengesteuerte Regeln

Nicht jede Qualitätsregel kann mit einem Schema oder regulären Ausdruck vollständig bewiesen werden. Die folgende Abgrenzung ist deshalb bewusst Teil des Sicherheitsmodells:

Erlaubte Benutzeranpassungen

• Ton: formal, neutral, concise, friendly

• Zielgruppe: general, expert, management, operations

• Detailgrad: compact, standard, detailed

• Anrede: neutral, du, sie

• Diagrammrichtung: top-down, left-right

• optionale Abschnitte: Definitionen, Systeme, Risiken/Kontrollen, Kennzahlen, Änderungshistorie

• Terminologie-Ersetzungen und alternative Überschriften

Weitere Beispiele enthält docs/styleguide.md.

Authentifizierung und Sicherheit

AutoDocBot passiert zwei voneinander getrennte Türsteher:

1. Microsoft Entra prüft: „Wer benutzt gerade den Copilot-Agenten?“

2. Atlassian prüft: „Darf AutoDocBot für diese Person in Confluence arbeiten?“

Stell dir AutoDocBot als Assistenten in einem Bürogebäude vor. Dein Microsoft-Ausweis bringt dich in das Büro von AutoDocBot. Dein Atlassian-Ausweis erlaubt AutoDocBot anschließend, in deinem Namen in Confluence zu arbeiten. AutoDocBot erhält dabei keine Passwörter, sondern technische Zutrittskarten – die OAuth-Tokens.

1. Copilot weist den Benutzer gegenüber AutoDocBot aus

Der Benutzer ist im Copilot bereits mit seinem Microsoft-Konto angemeldet. Copilot erhält von Microsoft Entra ein Access Token für die AutoDocBot-API und sendet es bei jedem MCP-Aufruf mit. Der MCP-Server prüft unter anderem:

• Stammt das Token wirklich vom konfigurierten Entra-Tenant?

• Ist es für die AutoDocBot-API bestimmt und noch gültig?

• Besitzt es den erforderlichen delegierten Scope?

• Welcher Benutzer und welche erlaubte Client-Anwendung stecken dahinter?

Damit kennt AutoDocBot die stabile Microsoft-Benutzeridentität, ohne ein Microsoft-Passwort zu erhalten.

2. AutoDocBot prüft die Confluence-Verbindung

Der Agent ruft get_confluence_connection auf. Der MCP-Server sucht im verschlüsselten Token Store nach einer Atlassian-Verbindung für genau diese Microsoft-Benutzeridentität. Existiert noch keine Verbindung, erzeugt er einen kurzzeitig gültigen, signierten Autorisierungslink. Dieser Link ist an den aktuellen Benutzer gebunden und nach dem ersten Öffnen verbraucht. Er bleibt bis dahin ein vertrauliches Bearer-Geheimnis und darf nicht weitergegeben werden.

3. Der Benutzer stimmt bei Atlassian zu

Der Link führt direkt zu Atlassian. Dort meldet sich der Benutzer an und sieht, welche Berechtigungen AutoDocBot anfordert, beispielsweise Confluence-Spaces und Seiten lesen sowie Seiten und Diagramm-Anhänge erstellen. Das Atlassian-Passwort bleibt vollständig bei Atlassian und ist für AutoDocBot nie sichtbar.

4. Atlassian gibt AutoDocBot einen einmaligen Code

Nach der Zustimmung leitet Atlassian den Browser zum registrierten Callback zurück:

/oauth/callback?code=...

Dieser Code ist ein einmalig einlösbarer Abholschein. Der MCP-Server tauscht ihn bei Atlassian gegen ein Access Token und – durch offline_access – ein Refresh Token. Zusätzlich ermittelt AutoDocBot die autorisierte Site, Cloud-ID, Benutzeridentität und verfügbaren Confluence-Spaces.

5. Beide Identitäten werden sicher miteinander verknüpft

AutoDocBot speichert sinngemäß folgende Zuordnung:

Microsoft-Benutzer
→ dessen Atlassian-Verbindung
→ autorisierte Site und Spaces
→ verschlüsselte OAuth-Tokens

Jeder Microsoft-Benutzer besitzt dadurch eine eigene Atlassian-Verbindung. Die Tokens werden nicht an Copilot zurückgegeben und nicht in Git gespeichert. Sie liegen verschlüsselt im persistenten /data-Token-Store.

6. Veröffentlichung im Namen des Benutzers

Nach der ausdrücklichen Bestätigung einer Vorschau bestimmt der MCP-Server über das Entra-Token erneut den aktuellen Benutzer. Er lädt ausschließlich dessen Atlassian-Verbindung und ruft damit die Confluence API auf. Deshalb erscheint der verbundene Atlassian-Benutzer als Autor und nicht ein allgemeiner Bot-Account.

Läuft das kurzlebige Access Token ab, verwendet AutoDocBot das verschlüsselte Refresh Token, um ein neues anzufordern. Eine erneute Anmeldung ist erst nötig, wenn die Verbindung widerrufen oder ungültig wurde beziehungsweise die Berechtigungen nicht mehr ausreichen.

Drei getrennte Sicherheitsentscheidungen

Microsoft Entra
„Wer spricht mit AutoDocBot?“

Atlassian OAuth
„Was darf AutoDocBot für diese Person in Confluence tun?“

Veröffentlichungsbestätigung
„Soll genau diese Vorschau jetzt wirklich veröffentlicht werden?“

Der Entra Admin Consent und die Atlassian-Zustimmung sind nicht dasselbe: Der Admin Consent erlaubt den Zugriff auf die AutoDocBot-API. Die individuelle Atlassian-Zustimmung erlaubt AutoDocBot anschließend die Confluence-Arbeit im Namen des jeweiligen Benutzers.

Lokaler Modus

AUTH_MODE=local ist ausschließlich für Entwicklung gedacht. Ohne Header verwendet der Server LOCAL_USER_ID; über x-autodoc-user-id kann der Testclient eine andere lokale Identität simulieren. Dieser Modus darf nicht offen im Internet betrieben werden.

Entra-Modus

AUTH_MODE=entra erwartet am MCP-Endpunkt ein Bearer Access Token und prüft:

• RS256-Signatur über die Microsoft-JWKs

• Entra-v2-Issuer des konfigurierten Tenants

• Audience der AutoDocBot-API

• Tenant Claim tid

• Benutzerobjekt oid

• delegierten Scope in scp

• Ausschluss reiner App-Tokens

• aufrufende Client-ID über azp beziehungsweise appid

• Client-ID gegen ENTRA_ALLOWED_CLIENT_IDS

Der Benutzer-Schlüssel im Token Store wird aus tenantId:objectId gebildet. Dadurch sind Atlassian-Verbindungen verschiedener Benutzer logisch getrennt.

Atlassian-Kontoverknüpfung

Im Entra-Modus kann /oauth/start nicht frei aufgerufen werden. get_confluence_connection erzeugt einen zeitlich begrenzten, signierten Link, der die aktuelle MCP-Benutzeridentität bindet. Der Server führt die ausgegebene Nonce im Arbeitsspeicher und verbraucht sie beim ersten Öffnen. OAuth-State und Link sind höchstens zehn Minuten gültig; ein Serverneustart macht sie ebenfalls ungültig.

Der Einmalmechanismus verhindert eine erneute Verwendung, aber nicht den Missbrauch eines vor dem berechtigten Benutzer abgefangenen oder bewusst weitergegebenen Links. Der Link muss deshalb wie ein kurzfristiges Passwort behandelt werden. Eine zusätzliche Entra-Anmeldung im Browser wäre für einen späteren Produktivbetrieb die stärkere Absicherung.

Token Store

• jede gespeicherte Verbindung wird separat mit AES-256-GCM verschlüsselt

• zufälliger IV und Authentifizierungs-Tag je Datensatz

• atomisches Schreiben über eine temporäre Datei

• Dateirechte 0600, Verzeichnisrechte 0700

• ablaufende Atlassian Access Tokens werden über den Refresh Token erneuert

• im lokalen Modus entsteht der ignorierte Schlüssel .local/token-encryption.key

• im Entra-Modus ist ein extern bereitgestellter TOKEN_ENCRYPTION_KEY zwingend

Wichtig: Wer sowohl die verschlüsselte Datei als auch den Verschlüsselungsschlüssel besitzt, kann die Tokens entschlüsseln. Beide Komponenten müssen getrennt geschützt und gesichert werden.

Datenverarbeitung und Speicherung

Die folgende Übersicht trennt die Verarbeitung durch AutoDocBot von der Aufbewahrung in angebundenen Plattformen. Für Copilot Studio, Microsoft Entra, Azure Log Analytics und Confluence gelten zusätzlich die im jeweiligen Kundentenant konfigurierten Aufbewahrungs-, Compliance- und Löschrichtlinien.

Vor einem breiten Produktivbetrieb müssen insbesondere eine verbindliche Log-Retention, ein Benutzer-Offboarding, eine Löschfunktion für gespeicherte Verbindungen, Secret-Rotation und die zulässigen Datenklassifikationen festgelegt werden.

Bekannte PoC-Grenzen

• Vorschauen und OAuth-State liegen im Arbeitsspeicher. Ein Neustart macht sie ungültig.

• Mehrere Replicas benötigen einen gemeinsamen Store für Vorschauen und OAuth-State; deshalb läuft der aktuelle PoC mit einer Replica.

• Eine Vorschau wird vor dem ersten Confluence-Schreibzugriff verbraucht. Ein fehlgeschlagener Publishing-Versuch benötigt deshalb eine neue Vorschau.

• Die Publishing-Pipeline ist nicht transaktional. Ein Fehler beim Attachment kann eine bereits angelegte Seite ohne fertiges Diagramm hinterlassen; ein erneuter Versuch kann eine zweite Seite erzeugen.

• Neue Seiten verwenden den fachlichen ArticleSpec-Titel ohne PoC-Zusatz. Ein eigener Aktualisierungs- oder Konfliktablauf für bereits vorhandene gleichnamige Seiten fehlt noch.

• Die Sichtbarkeit des Ziel-Spaces wird beim Atlassian-Login aus den ersten 100 gelieferten Spaces geprüft. Die Liste ist nicht paginiert und spätere Berechtigungsänderungen werden nicht aktiv synchronisiert; Confluence prüft sie beim API-Aufruf erneut.

• Die ausdrückliche Chatbestätigung ist eine Agentenregel. Der Server verlangt confirmed: true, besitzt aber keinen unabhängigen Nachweis des Chatverlaufs.

• Ein Verknüpfungslink ist einmal verwendbar, bleibt bis zur ersten Nutzung aber ein weiterleitbares Bearer-Geheimnis. Eine zusätzliche Browser-Anmeldung mit Entra ist noch nicht umgesetzt.

• Es gibt noch keine Benutzeroberfläche zur Verwaltung oder zum Widerruf gespeicherter Verbindungen.

• Die Bereitstellung unterstützt genau einen Entra-Tenant, eine Atlassian-Site und einen Ziel-Space. Eine mandantenfähige Konfigurationsverwaltung ist noch nicht umgesetzt.

• Der aktuelle Cross-Tenant-PoC setzt je Benutzer zusätzlich zur Agentenfreigabe eine persönliche, im Lab-Tenant authentifizierbare Power-Platform-Verbindung voraus. Der vorbereitete SSO-/OBO-Connector ist noch nicht aktiv.

• Weitere Atlassian-Benutzer können die 3LO-App nur autorisieren, wenn Distribution: Sharing aktiviert ist und keine Organisationsrichtlinie benutzerinstallierte Connected Apps blockiert.

• Styleguide und ArticleSpec sind im Code versioniert; organisationsspezifische Versionen sind noch nicht administrierbar.

• Monitoring, Alerting, Rate-Limit-Behandlung, Backups und automatisierte Deployment-Pipelines müssen vor einem Produktivbetrieb ergänzt werden.

Weiterentwicklung

Sinnvolle nächste Schritte:

1. Vorschau- und OAuth-State in Redis oder einer Datenbank persistieren.

2. Idempotente Publishing-Jobs mit Fehlerstatus, Wiederaufnahme und Behandlung gleichnamiger Seiten einführen.

3. Styleguides pro Organisation oder Space versionieren.

4. Audit-Events ohne Token- oder Inhaltslecks protokollieren.

5. Monitoring, Alerting und Backup-Strategien ergänzen.

6. Automatisierte Unit-, Integrations- und Copilot-End-to-End-Tests ausbauen.

7. Infrastructure as Code und CI/CD aufbauen.

Lizenz

Für dieses Repository ist derzeit keine Lizenzdatei hinterlegt. Ohne Lizenz bleiben die gesetzlichen Standardrechte beim Urheber. Vor einer externen Wiederverwendung sollte eine passende Open-Source- oder proprietäre Lizenz festgelegt werden.