Help wanted: real-world integrations, examples and tests across gateways, IdPs, sandboxes and clouds #734

Agent Mesh's goal is secure communication across environments: an agent on a laptop, inside a sandbox, or in one cluster/cloud should be able to discover and call an authorized tool, model, or agent in another environment, without making that service public or handing the agent broad, long-lived credentials.

Cloud-native integrations are top of mind: agentgateway, kgateway, identity providers (IdPs), OpenShell, Docker Sandboxes, workload identity, and cloud IAM. Agent Mesh should complement these systems, not replace their gateways, identity providers, or sandbox isolation.

Runnable examples, tests, deployment recipes, real use cases, and honest reports of what does not work are first-class contributions. You do not need to be a Go developer or an expert in Agent Mesh to help.

Some examples

• Docker Sandboxes: docker/sbx-kits-contrib#347 is merged. It adds an Agent Mesh kit for sandboxed agents. Follow-up work should demonstrate actual enrollment and authorized remote calls, not only that the kit installs. Existing tracking: #558.
• OpenShell and Substrate: #655 is an open PR with runnable examples of sandboxes/actors reaching the mesh under their own identities. It documents development-only trust settings, token-cache effects, and follow-up work. Coordinate there before duplicating it; it is not yet a released integration.
• Architecture and boundaries: security architecture. Existing gateways remain in the data path; the sandbox remains responsible for isolation. Platform identity establishes who is calling, while mesh policy and task-scoped authorization determine what that caller may do.

Pick an integration

These are some proposals. Each checkbox can be split into small follow-up issues. Pick one platform/version and one user journey first.

• agentgateway: carry the caller's identity to a remote mesh service.
  Project: agentgateway/agentgateway.
  Problem: a gateway can authenticate a user, but an upstream call must not silently become a shared gateway identity with broader permissions.
  Contribution: a runnable agentgateway -> Agent Mesh -> remote MCP tool example using a supported token-exchange or external-authorization path. Demonstrate two callers with different permissions and an expired-token/refresh case.
  Prior art: upstream token-exchange examples. Related problems: per-user MCP authentication and expired-token error handling. These are interoperability test cases, not prerequisites to fixing upstream.

• kgateway: keep the existing cluster gateway and add mesh authorization.
  Project: kgateway-dev/kgateway.
  Problem: teams should not need to replace their Kubernetes gateway to reach tools in another network.
  Contribution: a minimal Gateway API deployment showing the supported integration point with an Agent Mesh node, such as Envoy external authorization/processing. Show one allowed call, one denied call, and fail-closed behavior when the authorization service is unavailable. Document exactly where routing, identity verification, and policy enforcement happen; do not assume kgateway and agentgateway configuration is interchangeable.

• IdPs: turn an existing login into least-privilege mesh access.
  Start with keycloak/keycloak, or propose your organization's OIDC provider.
  Problem: authenticating a user is not the same as authorizing every tool they can discover; issuer, audience, subject, and group mapping must remain correct across environments.
  Contribution: a reproducible login/enrollment and service-access recipe with two users/groups. Verify intended grants, rejection of the wrong issuer/audience, and behavior after token expiry or a permission change. State which changes take effect immediately and which depend on credential/cache lifetime.

• SPIFFE/SPIRE: use workload identity without distributing mesh bootstrap secrets.
  Projects: spiffe/spire, spiffe/spiffe.
  Problem: ephemeral workloads need their own verifiable identities rather than sharing a node or sandbox credential.
  Contribution: build on docs,examples: OpenShell sandboxes and Substrate actors on the mesh under their own identity #655 to exercise JWT-SVID verification and exchange, with one authorized and one unauthorized workload. Document issuer discovery, audience checks, trust configuration, and renewal/rotation behavior. Distinguish today's OIDC-based verification from proposed native SPIFFE bundle-endpoint trust; do not present the latter as implemented.

• OpenShell: reach remote tools while preserving sandbox isolation.
  Project: NVIDIA/OpenShell.
  Problem: an isolated agent still needs useful remote tools and models, without unrestricted internet access or destination credentials inside the sandbox.
  Contribution: reproduce/review docs,examples: OpenShell sandboxes and Substrate actors on the mesh under their own identity #655, then add a focused user journey or automated smoke test. Show a permitted remote tool, a refused tool, and a second sandbox that cannot borrow the first sandbox's permissions. Explain the boundary between OpenShell network policy and mesh service/task policy, and replace or clearly label development-only trust settings.
  Related prior art: agentgateway's OpenShell example, which addresses gateway deployment rather than proving mesh authorization.

• Docker Sandboxes: demonstrate the merged kit solving a real task.
  Project: docker/sbx-kits-contrib.
  Problem: installing a kit does not prove a sandbox can securely use a tool or model in another environment.
  Contribution: extend the work in feat: Add agentmesh kit (v3) docker/sbx-kits-contrib#347 and Integrate with docker sandboxes #558 with a reproducible sandbox -> remote MCP/model journey against a real local test mesh. Verify successful enrollment, an allowed call, a refused call, and useful diagnostics when enrollment/connectivity fails. Record the minimum network policy actually required; do not assume allowing only the control-plane hostname covers every deployment topology.

• Substrate: federate an actor's identity instead of sharing a gateway token.
  Project: agent-substrate/substrate.
  Problem: an external relying party needs a stable actor-token contract and verifiable issuer keys.
  Contribution: reproduce the actor example in docs,examples: OpenShell sandboxes and Substrate actors on the mesh under their own identity #655 and test isolation between two actors. Track agent-substrate/substrate#1756, which covers actor JWT contracts and OIDC discovery/JWKS. As upstream support becomes available, validate native actor-token federation and document whether/when the example's stand-in credential provider can be removed.

• Kubernetes Agent Sandbox: give each ephemeral sandbox its own mesh identity.
  Project: kubernetes-sigs/agent-sandbox.
  Problem: a sandbox lifecycle, workload identity, network isolation, and mesh permissions must fit together without a shared long-lived secret.
  Contribution: a small cluster example with per-sandbox identity, access to one remote service, and a denied sibling sandbox. Include teardown/recreation behavior and a network-policy-enforcing CNI; document the responsibility of the sandbox runtime versus the mesh.

• Cloud IAM: call one cloud API without putting a cloud key in the agent.
  Pick one provider and one API first: Google Cloud workload identity federation, AWS web identity federation, or Microsoft Entra workload identity federation.
  Problem: an agent outside the cloud needs bounded access without inheriting a shared, broadly privileged service account.
  Contribution: validate an end-to-end mesh egress/federation recipe. Show an allowed operation and a denied operation, short-lived credentials kept out of the agent, and what principal actually appears in the cloud audit log. Document any limits on translating mesh task restrictions into provider-side permissions; do not imply they map automatically.

• Cross-environment use case: show why the integration matters.
  Combine any of the projects above: for example, a sandboxed coding agent on a laptop calling an MCP service in a private cluster, or an on-premises agent using a cloud-hosted model.
  Problem: same-machine demos do not establish that discovery, authentication, routing, NAT/relay behavior, and policy work across the intended boundary.
  Contribution: a concrete topology and reproducible walkthrough with an allowed task, an out-of-scope request that is denied, and logs explaining both outcomes. Describe network prerequisites, where credentials live, and which services remain private. A documented failed attempt with a minimal reproduction is useful too.

What a useful contribution looks like

Start small; a focused reproduction or documentation improvement is welcome before a full example:

1. A real problem and topology: who is calling what, across which boundary, and why existing connectivity/identity alone is insufficient.
2. Repeatable steps: tested versions, prerequisites, minimal configuration, setup, expected output, and cleanup. Never commit credentials or put secrets in command-line arguments.
3. Evidence: an allowed request and a denied request, plus the logs or audit records that explain the decision. For lifecycle work, include the relevant expiry, renewal, rotation, or policy-cache behavior.
4. Clear boundaries: distinguish tested behavior, development shortcuts, unsupported combinations, and production requirements. Do not weaken authentication, TLS, or isolation to make a demo appear successful.
5. Tests at the right level: prefer focused unit/integration coverage for protocol and policy edge cases; reserve black-box E2E tests for the core cross-system user journey. Do not make every case a slow E2E test.

How to pick something up

Comment with the checkbox, project/version, and use case you want to try. Link an existing issue or open a focused follow-up linked here so we can track ownership and check items off when the agreed scope is done. Coordinate with #558 and #655 where relevant.

Examples, tests, documentation, deployment experience, and reports from users of these platforms are as valuable as implementation PRs. If you have another gateway, IdP, sandbox, or cloud use case, propose it here with the problem you want to solve.