How it works
AgentsPoppy is a desktop host with a local broker that holds the user's AWS credential and vends scoped, short-lived credentials to approved apps. Your poppy never sees the user's keys — and the user can see, and undo, everything your poppy does. Here is the actual mechanism, end to end.
Your extension.json carries a permission set: every
grant as service + actions + resource scope, plus required attribution tags. The host
re-reads it on every load and reconciles the connection — the scope users approved can never
silently drift from the scope you ship.
Before anything is approved, every grant is rated: green scoped reads · amber scoped mutations and unscoped pure-creates · red anything that could mutate resources beyond the poppy's own. Aim for amber or green, with “No risks to other resources identified.”
A red rating is not an automatic no — but treat it as likely rejection unless the poppy makes a strong case. Some genuinely useful software cannot be built without wide access: a mail host has to touch DNS, a VM manager has to terminate instances. What review weighs is whether the user gets something worth that reach, whether the scope is as narrow as the job allows, and whether the manifest says so in plain language. Poppies in the catalogue today carry reds on exactly those grounds.
If you're not sure how yours will land, ask before you build. Signing up as a developer is free, and support@agentspoppy.com will tell you straight whether a permission is likely to pass — it's a much cheaper conversation before the code exists than after.
The approval screen describes the access in human terms. One connection per poppy, per account, revocable at any time.
On demand, the broker mints short-lived session credentials (~1 hour, auto-rotating) via the cloud's native token service, narrowed by a session policy to exactly the approved grants and stamped with transitive session tags carrying the connection's identity. Very wide scopes are automatically promoted to managed session policies — you don't manage any of this, the broker does.
Resources your poppy creates inherit its tags — so the host can show the user a live inventory of what your poppy owns, and prove nothing else was touched.
Removal runs your teardown hook, deletes your stacks, then sweeps by attribution tag.
npm run certify proves the sweep leaves literally nothing — the
certification users install on.
Your UI talks to the host bridge for everything privileged. It cannot read credentials, other poppies, or the management plane.
Your backend receives a bootstrap with a per-connection token that authorises credential minting for its own connection only. One poppy can never enumerate, disable, or tear down another — loopback is not a trust boundary here; tokens are.
Every mechanical guarantee above is a sales argument you don't have to make yourself. The permission screen sells your restraint. The live inventory sells your transparency. The teardown certificate sells reversibility. And because your repo is open, a user's own AI agent can verify that the code matches the declarations — updates are openly auditable before they're applied (the catalogue pins each release's sha256, packages are byte-reproducible from source).
On this page we name the plumbing. In your poppy's UI, don't. Users get plain language — “connecting to your cloud”, not the broker's internal vocabulary. The design guide is explicit about which words stay backstage.