EmDash 1.0 moves plugin vetting from manual review to a site owner's signed allowlist

Each EmDash plugin runs in its own V8 isolate on the Workers runtime, with no shared memory, no filesystem access and no direct network calls, according to a dev.to write-up of the release ^[6]. What the plugin gets is a capability token scoped to named CMS APIs and paths, such as "write to /blog/posts" but not "/admin/users" ^[7]. It cannot discover an API it was not granted ^[7]. Each request is capped at 50ms of CPU time and 128MB of memory ^[8]. Those figures come from the write-up, and anyone sizing a plugin against them is relying on one author ^[8].

The author names the cost. Plugins cannot run long tasks or hold persistent connections ^[9]. The write-up calls that acceptable because agents mostly orchestrate short, stateless steps, such as generating a post or triggering a build ^[9]. That holds only where every plugin call finishes its compute inside 50ms and keeps nothing open between requests ^[8]. The case to test first is one the author raises: an agent extending the CMS to integrate a third-party API ^[17]. With no direct network calls, that plugin needs the CMS to make the request through a granted capability, and the write-up does not describe one ^[6].

The registry is a set of signed manifests hosted on IPFS and indexed by a Cloudflare-operated discovery service, according to the same write-up ^[2]. Installation runs in order ^[3]:

1. The author publishes a manifest with the code hash, the plugin's permissions and an Ed25519 signature to IPFS, and can submit its CID to the discovery service for public listing ^[2][3]. 2. The site owner fetches the manifest and checks the signature against a public key they already know ^[3]. 3. If it verifies, the plugin goes on the site's local allowlist ^[3]. 4. EmDash downloads the code from IPFS and checks it against the hash before running it ^[3].

This is careful engineering. Because each site checks signatures itself, a compromised discovery service cannot inject code ^[10]. The same design puts the vetting in step 2. A valid signature proves which key signed a manifest. Whether that key belongs to someone whose code should run on the site is still a judgement, made by the site owner when the key goes on the allowlist ^[3]. The write-up calls managing those keys and allowlists "not trivial for non-technical users" ^[11]. Greg Barbosa, director of innovation and systems at Avulux, said of his company's move: "With EmDash, we now have a shared platform that developers can extend and marketers can edit content." ^[15]

The write-up's premise is that an agent extending a CMS cannot pause for human review, the step older plugin ecosystems assumed ^[17]. After installation, isolation limits the damage. The author says the model stops a malicious plugin from exfiltrating publisher credentials, modifying unrelated content or reading other plugins' state ^[12]. A plugin holding write access to /blog/posts can still write whatever it wants to /blog/posts ^[7][12]. Inside that scope, the agent API logs each action with the agent's identity, parameters and result, and sets a default quota of 100 requests a minute per agent ^[13]. At that default, a looping agent can still send 6,000 requests an hour ^[16].

In my view, isolation by default is the right design for a CMS that agents extend, provided plugins stay inside short, stateless jobs ^[9]. Under the flow as described, a plugin an agent wants to install runs only after its publisher's key passes the site's allowlist check ^[3].