Markdown-Ausgabe

AI-translated from English; not yet reviewed by a fluent editor.

# Poppy-Entwurf zeigt, wie persönliche Agenten auf Unternehmenskonten zugreifen könnten

> Der Poppy-Entwurf von Sierra vom 9. Oktober legt vorgeschlagene Regeln für Auffindbarkeit, Anmeldung und Sitzungen persönlicher Agenten bei Unternehmen fest. Seine Sicherheitskontrollen und offenen Lücken sind wichtiger als die erweiterte Liste der Designpartner.

By BIG CHANGE Editorial

Published: 2026-10-10T12:09:58.334Z
Updated: 2026-10-10T12:09:58.334Z
Canonical: https://bigchange.ai/blog/poppy-personal-agent-protocol-draft-sessions-permissions

![Conceptual illustration of a visitor holding a blank-screen phone outside an open office doorway while an employee listens and gestures from inside.](https://bigchange.ai/api/media/file/poppy-office-threshold-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. The scene is illustrative only and does not depict an actual Poppy workflow or verified deployment.

Sierra veröffentlichte [Entwurf 0.1 des Personal Agent Protocol](https://personalagentprotocol.org/docs/spec), kurz Poppy, am 9. Oktober, drei Tage nachdem [das Projekt mit Meta und weiteren Partnern angekündigt worden war](https://sierra.ai/blog/introducing-personal-agent-protocol). Das neue Dokument macht aus dem allgemeinen Versprechen der Vorstellung konkrete Vorschläge: wie sich die Agentenschnittstelle eines Unternehmens finden, ein persönlicher Agent identifizieren, ein Kunde anmelden und ein Besuch über Website, APIs und Unternehmensagent hinweg fortsetzen lässt.

Es ist weiterhin ein Entwurf. Laut Spezifikation kann sich jeder Teil vor einer stabilen Version ändern, auch auf inkompatible Weise. Sierra [nannte außerdem 35 weitere Designpartner](https://sierra.ai/kr/blog/poppy). Die Teilnahme am Designprozess belegt nicht, dass diese Unternehmen Poppy-Schnittstellen eingeführt haben.

## Die große Änderung

- **Was sich geändert hat:** Die Ankündigung vom 6. Oktober beschrieb eine Möglichkeit, persönliche Agenten mit Unternehmen arbeiten zu lassen. Der Entwurf vom 9. Oktober konkretisiert die vorgeschlagenen Austausche von Identität, Berechtigungen und Sitzungsdaten, die Unternehmen und Agenten implementieren müssten.
- **Warum es wichtig ist:** Ein Kunde könnte einen Agenten für Kontoaufgaben autorisieren, während das Unternehmen den Agenten identifiziert und seinen Zugriff begrenzt. Der Entwurf verbindet diese Kontrolle mit Website-Nutzung, APIs und Gesprächen; das Unternehmen entscheidet jedoch, welche Kanäle und Berechtigungen es anbietet.
- **Worauf zu achten ist:** Implementierer können nun konkrete Schnittstellen prüfen; Regeln für Zahlungen, Benachrichtigungen und Anhänge sind zugleich noch offen. Sierra plant für den kommenden Monat Design-Workshops und eine Referenzimplementierung. Beides ist noch kein Beleg für breite Interoperabilität.

## Die Suche beginnt bei der Unternehmensdomain

Laut dem [Spezifikationsentwurf](https://personalagentprotocol.org/docs/spec) veröffentlicht ein teilnehmendes Unternehmen über HTTPS eine `/.well-known/poppy.json` Datei. Sie nennt die Organisation und den OAuth-Aussteller, unterstützte Anmeldeverfahren sowie gegebenenfalls einen Website-Sitzungsendpunkt, OpenAPI- oder MCP-APIs und einen Endpunkt für Gespräche mit einem Unternehmensagenten. Das Unternehmen muss nicht jede Route anbieten. Der Agent würde die Datei nutzen, um verfügbare Möglichkeiten zu finden, statt die Website als einzigen Zugang zu behandeln.

Die Datei allein kann einen Agenten nicht autorisieren. Die Organisationsdomain muss mit der vom Agenten angefragten Domain übereinstimmen. Der Agent muss auch die Metadaten des OAuth-Servers prüfen: Der Aussteller muss zur Datei passen, und die Liste `poppy_domains` muss die Organisationsdomain enthalten. Diese Prüfungen sollen verhindern, dass eine nicht zugehörige Domain den Aussteller eines anderen Unternehmens beansprucht und Token erhält.

Der persönliche Agent weist sich über eine HTTPS-`client_id`-URL aus, die seine Client-Metadaten bereitstellt, darunter öffentliche Signaturschlüssel und zulässige Weiterleitungsadressen. Das Unternehmen kann eine vorherige Registrierung verlangen, eine Agenten-ID sperren oder widerrufen und die Erstellung von Sitzungen begrenzen. Der Entwurf gibt dem Unternehmen diese Kontrollen; er verpflichtet nicht jedes Unternehmen, jeden Agenten anzunehmen.

## Aus einer Gastsitzung kann eine Kontositzung werden

Der persönliche Agent weist seinem Nutzer eine stabile, opake ID zu, die bei jedem Unternehmen spezifisch ist, und startet eine Sitzung mit einer signierten Assertion. Das Unternehmen gibt ein Sitzungstoken für einen abgemeldeten Zustand zurück. So kann es denselben Agenten und Nutzer über Sitzungen hinweg wiedererkennen, ohne die Person als angemeldet zu behandeln. Der Entwurf verbietet, diese Nutzer-ID aus Name, E-Mail-Adresse oder Telefonnummer abzuleiten, auch nicht über einen Schlüssel-Hash.

Für den Kontozugriff gibt das Unternehmen die unterstützten Anmeldeverfahren an. Bei der direkten Anmeldung nutzt der Browser des Nutzers eine OAuth-Autorisierungsseite und PKCE. Bei der Geräteanmeldung besucht der Nutzer mit einem Link und Code die Unternehmensseite. Bei der vermittelten Anmeldung kann der Agent vom Nutzer erhaltene Zugangsdaten an einen festgelegten Unternehmensendpunkt senden; dies ist ein eigener, optionaler Weg mit ausdrücklichen Regeln zur Verarbeitung von Zugangsdaten und zur Ratenbegrenzung. Der Entwurf benennt eine Vertrauensgrenze: Ein Unternehmen kann nicht immer überprüfen, ob ein Mensch und nicht der Agent die direkte Anmeldeseite abgeschlossen hat.

Berechtigungen werden als Scopes ausgedrückt. Poppy definiert breite `poppy:read` und `poppy:write`-Scopes, lässt Unternehmen aber auch engere eigene Scopes anbieten. Das Unternehmen kann nicht mehr gewähren, als der Agent angefordert hat oder als das jeweilige Anmeldeverfahren zulässt. Mit einem nach der Anmeldung ausgestellten Kontotoken kann der Agent weitere angemeldete Sitzungstoken innerhalb der genehmigten Scopes beziehen. Benötigt eine Aufgabe mehr Zugriff, muss sich der Nutzer erneut für diese Scopes anmelden.

Der Unterschied zwischen den beiden Token ist wichtig. Ein Sitzungstoken ist kurzlebig und wird für API-Aufrufe und Gespräche verwendet. Ein Kontotoken ist ein langlebigeres OAuth-Aktualisierungsmerkmal, das nur an den Token- und Widerrufsendpunkten des Unternehmens genutzt wird. Laut Entwurf muss der Agent es aus Modellkontext, Nachrichten, Protokollen und URLs heraushalten. Beim Abmelden wird das Kontotoken widerrufen und werden damit verknüpfte Sitzungen abgemeldet; das Unternehmen kann diese Sitzungen ebenfalls beenden. Bereits ausgestellte Sitzungstoken können gültig bleiben. Deshalb empfiehlt der Entwurf, den Sitzungsstatus bei jeder Anfrage zu prüfen oder deutlich kürzere Tokenlaufzeiten zu nutzen.

## Eine Sitzung, drei mögliche Wege

Poppy schlägt eine gemeinsame Unternehmenssitzung für die Aktivitäten eines Nutzers über den persönlichen Agenten vor. Für OpenAPI-Aufrufe und Gespräche mit einem Unternehmensagenten sendet der Agent ein Sitzungstoken im Authorization-Header. Üblicherweise bindet der Entwurf diese Token mit DPoP-Nachweisen an einen vom Agenten gehaltenen Schlüssel; das Unternehmen prüft sie bei jeder Anfrage. MCP ist eine ausdrückliche Ausnahme: Die Autorisierung verwendet ein Bearer-Token, das auf den aufgeführten MCP-Server beschränkt ist, und der Entwurf erlaubt diese Bearer-Form nur für MCP-APIs. Das sind Protokollanforderungen, kein Nachweis dafür, dass eine Implementierung sicher ist.

Das Surfen auf einer Website wird anders in dieselbe Sitzung eingebunden. Veröffentlicht ein Unternehmen einen Browser-Sitzungsendpunkt, sendet der Browser des Agenten eine kurzlebige signierte Assertion und erhält das eigene Sitzungscookie des Unternehmens. Die Website setzt dann den aktuellen Anmeldestatus und die Scopes der Sitzung um. Ohne diesen Endpunkt surft der Agent als gewöhnlicher abgemeldeter Besucher. Sierras [Ankündigung zur Einführung](https://sierra.ai/blog/introducing-personal-agent-protocol) beschrieb einen Besuch über mehrere Kanäle hinweg; der Entwurf legt für Browser- und API-Verkehr innerhalb dieser gemeinsamen Sitzung unterschiedliche Zugangsdaten fest.

Das Unternehmen kann OpenAPI-Beschreibungen, MCP-Server und einen Gesprächsendpunkt in seiner Suchdatei auflisten. Der Entwurf beschreibt ein Poppy-Gesprächsformat für den Austausch mit einem Unternehmensagenten und das Hinzuziehen eines Menschen bei Bedarf. Das Schema jeder API bleibt Sache dieser API. Das Unternehmen entscheidet, welche Wege es bereitstellt, und kann die Aktionen eines Agenten selbst in einer angemeldeten Sitzung begrenzen.

## Was der Entwurf noch offenlässt

Die [Seite mit offenen Themen](https://personalagentprotocol.org/docs/open-topics) des Protokolls nennt drei größere Lücken: Zahlungen, Push-Benachrichtigungen ohne offene Anfrage und Anhänge wie Belege, Etiketten, Bilder oder Formulare. Die Liste sei unvollständig. In den Beispielen des Entwurfs werden fiktive Unternehmen und Platzhalter-Zugangsdaten verwendet.

Sierras Beitrag vom 9. Oktober beschreibt eine [Konferenzvorführung mit Metas Muse und Rocket](https://sierra.ai/kr/blog/poppy). Das ist Sierras Darstellung einer inszenierten Vorführung, keine unabhängige Prüfung eines Produktiveinsatzes. Sierra will im kommenden Monat Design-Workshops veranstalten und eine Referenzimplementierung veröffentlichen. Vorerst ist Poppy ein veröffentlichter Vorschlag mit Implementierungsdetails und einer wachsenden Liste von Designpartnern. Seine praktische Reichweite hängt davon ab, welche Unternehmen und Entwickler persönlicher Agenten kompatible Versionen implementieren und welchen Zugriff sie tatsächlich anbieten.

## Quellen und weiterführende Informationen

- [Spezifikation des Personal Agent Protocol, Entwurf 0.1](https://personalagentprotocol.org/docs/spec), aktualisiert am 9. Oktober 2026. Primärquelle für Regeln zu Auffindbarkeit, Identität, Anmeldung, Scopes, Token, Sitzungen und Kanälen. Sie erlaubt ausdrücklich inkompatible Änderungen vor einer stabilen Version; die Beispiele sind fiktiv.
- [Poppy: offene Themen](https://personalagentprotocol.org/docs/open-topics), aktualisiert am 9. Oktober 2026. Primäre Liste der Zahlungen, Push-Benachrichtigungen und Anhänge, die im aktuellen Entwurf fehlen; laut Seite können weitere Lücken auftreten.
- [Sierras Ankündigung vom 9. Oktober](https://sierra.ai/kr/blog/poppy). Belegt das Veröffentlichungsdatum, 35 weitere Designpartner, eine berichtete Konferenzvorführung und geplante Workshops/Referenzimplementierung. Dies sind Aussagen von Sierra, keine Belege für einen Einsatz.
- [Sierras Einführung vom 6. Oktober](https://sierra.ai/blog/introducing-personal-agent-protocol). Zeigt, was die ursprüngliche Ankündigung vorschlug und wie sich der spätere technische Entwurf davon unterscheidet.

## Sources

- [Spezifikation des Personal Agent Protocol (Entwurf 0.1)](https://personalagentprotocol.org/docs/spec) — Primärtext zu Regeln für Auffindbarkeit, Identität, Sitzungen, Anmeldung, Scopes, Token, Browser, APIs und Gespräche; warnt ausdrücklich vor künftigen inkompatiblen Änderungen und fiktiven Beispielen.
- [Poppy: offene Themen](https://personalagentprotocol.org/docs/open-topics) — Nennt Zahlungen, Push-Benachrichtigungen und Anhänge als größere Lücken; die Liste ist nicht vollständig.
- [Entwurf des Personal Agent Protocol wird geteilt](https://sierra.ai/kr/blog/poppy) — Sierras Darstellung der Veröffentlichung, 35 weiterer Designpartner, einer Summit-Vorführung und geplanter Workshops/Referenzimplementierung; kein unabhängiger Beleg für einen Einsatz.
- [Einführung des Personal Agent Protocol](https://sierra.ai/blog/introducing-personal-agent-protocol) — Ursprüngliche Ankündigung und vorgesehenes Kontrollmodell für Nutzer und Unternehmen, herangezogen, um die Entwicklung vom 9. Oktober einzuordnen.