Does @microsoft/agent-governance-sdk support Cloudflare Workers / workerd?

[Kevin Knapp (Knapp-Kevin)]

I have a concrete edge-runtime use case and wanted to clarify the intended support boundary before treating accidental compatibility as supported behavior.

The execution runner is a Cloudflare Worker using the workerd runtime. We want deterministic pre-execution governance around consequential agent/tool actions, ideally by evaluating policy in-process before allowing the action to execute.

@microsoft/agent-governance-sdk currently declares Node.js >=18 as its runtime requirement, and I could not find workerd or Cloudflare Workers mentioned in the package documentation.

A few questions:

1. Is running @microsoft/agent-governance-sdk directly inside a Cloudflare Worker/workerd an intended or supported deployment model today?
2. If only part of the SDK is runtime-portable, is there an edge-safe subset intended for policy evaluation and pre-tool-call governance?
3. If workerd is deliberately out of scope, is the recommended architecture for edge runtimes to call an AGT HTTP policy/engine service before executing the governed action?
4. Would maintainers be interested in a minimal workerd/Miniflare conformance test if the dependency surface is already close to compatible?

The distinction matters because successful bundling/import is not sufficient evidence that the governance path actually works. I would want a compatibility claim to cover at least one real pre-execution policy evaluation and deterministic allow/deny result under the Worker runtime.

This came up while reviewing several “false green” production incidents in an autonomous deployment workflow, where configuration or status surfaces appeared healthy while the intended operational consequence never occurred. For the action-shaped case, pre-execution policy is exactly the control we want. The runner simply happens to live at the Cloudflare edge.

Happy to test against a small Worker fixture or contribute documentation/tests if this is a runtime the project wants to support.

[Kevin Knapp (Knapp-Kevin)]

I did some more digging on this and now have actual runtime evidence rather than just package inspection.
The good news is that AGT 5.0.0 works in a modern Cloudflare Worker when Cloudflare’s current Node compatibility behavior is enabled. I ran the real PolicyEngine path under workerd, not just a bundle/import test, and the behavior was what we’d want to see: an allowed capability executed once, a denied capability never executed, unknown decisions failed closed, and unregistered capabilities were rejected before policy evaluation.
So for the Cloudflare deployment I’m working on, I no longer think this is a blocker.
There is still a narrower portability issue, though. If I explicitly disable Node compatibility with no_nodejs_compat and no_nodejs_compat_v2, the current AGT SDK fails during bundling before the behavioral tests even start. The failures come from Node built-ins such as crypto and fs being pulled in through the SDK module graph. There’s also a smaller TypeScript portability wrinkle where the published declarations reference Buffer.
What I don’t think the evidence shows is that the policy engine itself fundamentally needs Node. The basic in-memory policy path works perfectly well once the package can load. So this looks more like a package/module-boundary issue than a policy-engine limitation.
My current read is basically:
Modern Node-compatible Cloudflare Worker: works, verified with real policy execution.
Strict no-Node workerd: not currently supported by the published SDK package.
For normal current Cloudflare Workers: not a blocker.
An edge-safe/runtime-neutral AGT entry point would still be useful.
That seems like a much narrower and more actionable question than “does AGT support Cloudflare Workers?” The answer to that broader question is now effectively yes, with the caveat that strict no-Node portability still has some work to do.

[Kevin Knapp (Knapp-Kevin)]

Update after live edge-runtime testing

I took this beyond the earlier bundle/import compatibility question and exercised AGT 5.0.0 in a live Cloudflare Worker execution path.

What is now demonstrated:

• the TypeScript AGT policy path executes inside the Worker runtime and makes real allow/deny decisions;
• an allowed, registered capability proceeded through the agent's pre-capability governance boundary and performed a real durable external mutation;
• the execution claim was not treated as proof of outcome: a separate reader independently observed the resulting object and matched the claimed object version and content digest;
• cleanup was a separate governed operation with its own operation identity, followed by independent verification that the object no longer existed;
• prohibited capability names returned native AGT deny decisions;
• separately, an unregistered capability was rejected by the host before AGT evaluation, which demonstrates that host capability registration and policy authorization can remain distinct authority layers.

So the compatibility question is substantially answered: AGT's TypeScript policy evaluation can participate in a real pre-capability governance path in an edge/workerd environment. This was not only an import or packaging test.

One narrow enforcement case remains before I would call the full allow/deny execution path proven: register an otherwise executable test capability, allow it to reach the AGT interceptor, have AGT deny it, and independently verify that its handler produced zero external side effect. The current unregistered-capability test is intentionally stopped one layer earlier, so it does not establish that particular property.

A second, separate observation came out of the exercise: authorization evidence and outcome evidence should remain distinct. AGT established whether the action was permitted. Independent external observation established whether the permitted action actually occurred. I would not attribute the latter to AGT itself.

At this point I think the useful follow-on is less “can this run in a Worker?” and more “should the TypeScript policy surface have an explicit edge-runtime support/conformance contract so this does not remain downstream knowledge?”