How it works

The permission broker, technically

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.

The lifecycle of a connection

  1. The manifest declares

    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.

  2. The risk assessor rates

    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. The bar for listing: amber or green, with “No risks to other resources identified.”

  3. The user approves — in plain language

    The approval screen describes the access in human terms. One connection per poppy, per account, revocable at any time.

  4. The broker vends

    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.

  5. Everything is attributed

    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.

  6. Teardown, provable

    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.

Where your code runs, and what it can see

Frontend

Renders in the host, sees no secrets

Your UI talks to the host bridge for everything privileged. It cannot read credentials, other poppies, or the management plane.

Backend

Spawned by the host, scoped to itself

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.

Why this matters commercially

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).

// one language note

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.