Claw Conduit - open source A2A bridge between NemoClaw and Microsoft Foundry Agent Service or AWS Bedrock AgentCore

[paragontech]

Claw Conduit

Open source A2A bridge connecting NemoClaw to Microsoft Foundry Agent Service and AWS Bedrock AgentCore

10 days after NemoClaw launch we built and open sourced Claw Conduit - an A2A bridge connecting NemoClaw to Microsoft Foundry Agent Service and AWS Bedrock AgentCore Runtime:

https://github.com/Paragon-Technology-Solutions/claw-conduit

We built the NemoClaw client by reading your own e2e test scripts -- the SSH+CLI pattern against the OpenClaw gateway on port 18789. We also authored a vertical-specific OpenShell policy blueprint extending the sandbox defaults for a mid-market enterprise deployment.

We are the first managed AI services firm deploying this stack for mid-market enterprises across the PE ecosystem. Our clients are excited about NemoClaw but all their agents are in their Microsoft or AWS stack. They also want to avoid lock-in / have optionality.

A couple of things we would love your input on as NemoClaw matures toward GA:

• When the programmatic API shape changes before GA, open an issue in our repo and we will update nemoclaw.py same day.
• We would welcome feedback on whether our OpenShell policy blueprint is using the policy model correctly -- particularly the egress controls for operational data store access.

Stack:
Python 3.11, FastAPI, A2A protocol, Entra ID on Azure, SigV4 on AWS. 17 tests passing.

Cheers

Ariel Jalali
Paragon Technology Solutions - paragoncto.com

[ljefford2-cmyk]

I’ve done some work on this. RFC #442 in this repo includes a WAL Integration Profile for OpenShell that covers graduated egress policy binding — how trust levels map to which endpoints a sandboxed agent can reach, and how that policy set widens or narrows based on demonstrated reliability.

The companion governance overlay in the same repo maps the full trust lifecycle onto OpenShell’s policy model, including credential isolation and dual-scan privacy enforcement at the egress boundary.

Both documents are in the local-first-ai-orchestration repo if you want to evaluate whether the patterns apply to your enterprise blueprint.

https://github.com/ljefford2-cmyk/local-first-ai-orchestration

[paragontech]

Thank you RFC #442 is exactly the kind of reference I was looking for. The graduated egress binding pattern is directly relevant to what we are doing with the healthcare vertical blueprint. We currently use a static deny-by-default with a scoped allowlist for the operational data store endpoints. The trust lifecycle overlay and credential isolation piece is the gap we have not solved yet in our OpenShell policy design.

Will review the local-first-ai-orchestration repo and follow up with any questions.