MCP Gateway for AI Agents: Why Tool Access Needs a Sandbox Contract

MCP Gateway for AI Agents: Why Tool Access Needs a Sandbox Contract

Agent tool access is getting more serious than "give the model another integration." Once an agent can touch repositories, analytics, Search Console, deployment, public publishing, or account state, the real question becomes: what is it allowed to read, where can it write, and who can inspect the route?

GitHub's Agentic Workflows MCP Gateway is useful because it makes that question visible. From a source read, the interesting pattern is not just MCP. It is the contract around MCP: a sandboxed agent talks to a gateway, the gateway routes to backend tool surfaces, and policy defines which sources can be read and where outputs can land.

In this framing, an MCP Gateway for AI agents is the control point between a sandboxed agent and the backend tools it can call: the place where routes, source policies, output sinks, logs, and human review boundaries become inspectable instead of implicit.

Short version

• MCP Gateway matters because agent tool access is becoming a policy problem, not just an integration problem.
• GitHub Agentic Workflows MCP Gateway appears to put a gateway between sandboxed agents and backend MCP servers.
• The reusable contract is: agent -> gateway -> backend tool surface, with source policies and write sinks around the route.
• allow-only is the useful read-side pattern; write-sink is the useful output-side pattern.
• Starkslab should steal the capability-boundary model, not claim runtime validation.

Source boundary: this is a source-read teardown based on the Starkslab dissection of github/gh-aw-mcpg, public GitHub repo metadata, README/docs references, and the WED-443 outline-readiness review. Starkslab did not pull or run Docker images, configure an MCP server, execute GitHub Agentic Workflows, install packages, or perform hands-on runtime validation.

Evidence used in this source-read

This source-read uses:

• public GitHub evidence around github/gh-aw-mcpg and the related github/gh-aw project;
• README/docs references summarized in starkslab/research/2026-05-09-github-agentic-workflows-mcp-gateway-dissection.md;
• outline-readiness review notes from starkslab/symphony/2026-05-09-github-agentic-workflows-mcp-gateway-outline-readiness-review.md;
• draft review notes from starkslab/symphony/2026-05-09-mcp-gateway-source-read-draft-review.md.

It does not add runtime evidence. Starkslab still has no Docker pull/run, MCP server configuration, GitHub Agentic Workflows execution, package install, or hands-on runtime validation for this gateway.

What this covers

This note covers:

• what GitHub Agentic Workflows MCP Gateway appears to do from public docs;
• the agent -> gateway -> backend tool-surface contract;
• why allow-only source policies and write-sink output policy are the reusable ideas;
• how this maps to Starkslab, Symphony, OpenClaw, and Search Console capability boundaries;
• what we can steal now versus what we must not claim until runtime validation exists.

What sits below the gateway? The implementation layer

The gateway is not the whole MCP stack. It is the sandbox contract around agent tool access. Below or beside that contract, developers still need an implementation layer: clients, servers, tool schemas, local inspection, UI hooks, scaffolding, and eventually deployment or marketplace workflows.

That is where mcp-use-ts is useful as source-read comparison evidence. It appears to package MCP development as a TypeScript framework / DX surface: client and server helpers, schema-shaped tools, React widget hooks, inspector-style tooling, and Manufact-hosted lifecycle language. Starkslab has not installed it, run an MCP server, rendered a widget, used Manufact, or performed hands-on runtime validation, so the safe claim is narrow.

The useful distinction is this: MCP Gateway answers what can the agent touch, through which governed route, and where can output land? mcp-use-ts points at what developers touch when they build MCP clients, servers, widgets, and app workflows. Keeping those layers separate makes the sandbox contract stronger instead of turning this note into a broad MCP ecosystem roundup.

What is GitHub Agentic Workflows MCP Gateway?

gh-aw-mcpg is a GitHub-owned repository described as a gateway for Model Context Protocol servers. The public repo is MIT-licensed, written in Go, and tied to GitHub Agentic Workflows through the related github/gh-aw project.

From the source-read dissection, the gateway appears to sit between sandboxed agents and backend MCP servers. Instead of handing the agent every backend directly, the sandbox can receive an MCP Gateway endpoint through sandbox.mcp configuration.

The gateway exposes two route shapes:

• a routed endpoint: POST /mcp/{serverID} for a specific backend server;
• a unified endpoint: POST /mcp for one route that can dispatch across configured servers.

The public docs and README describe request forwarding, tools/list, tools/call, health checks, API-key auth, logs, backend server configuration, and policy guards. That is enough to make the operator pattern worth studying.

It is not enough to claim the stack is easy to run, broadly safe, production-ready, or compatible with every MCP server. Starkslab has not run it. This is a governance-pattern teardown.

Why is agent tool access becoming a gateway problem?

Early agent demos often inherit a messy tool surface: local credentials, environment variables, shell access, broad API tokens, writeable workspaces, and a pile of CLI wrappers. That can work for a demo because the blast radius is small and the operator is watching closely.

It gets dangerous when the same agent touches real operating surfaces:

• private repositories;
• analytics and revenue data;
• Search Console and indexing flows;
• deployable site source;
• public note publishing;
• Linear issue writes;
• social posting or outreach;
• package registries, billing, DNS, or account state.

At that point, "the agent has tools" is not a sufficient design. The better question is:

• which sources can this agent read?
• which backend tools can it call?
• where can output go?
• which actions are internal-only?
• which actions require human approval?
• what logs prove the boundary was respected?

A gateway makes tool access declared and inspectable instead of implicit.

That matters for Starkslab because the factory already works through boundaries. Symphony tasks have allowed artifact zones. OpenClaw separates sessions, tools, files, messages, browser control, and human-gated actions. Search Console evidence is valuable, but Request Indexing is still human-gated. Public distribution is useful, but not automatic.

The MCP Gateway pattern gives this discipline a clearer vocabulary.

What does the sandbox contract look like?

The named mini-diagram is The sandbox contract:

sandboxed agent
  -> MCP Gateway endpoint
  -> selected backend MCP server or unified route
  -> source policy / output policy / logs / health checks
  -> returned tool result or allowed write destination

The agent should not receive every raw credential or backend endpoint directly. The gateway owns routing and backend selection. The policy layer owns what sources can be read and where output can go. Logs and health checks make the capability surface reviewable.

That is the useful abstraction: agent tool access becomes a control plane.

For an operator, the gateway is not just plumbing. It is where you can ask: is this worker allowed to read this repository? Is it allowed to write to this folder? Can it comment in Linear? Can it publish? Can it request indexing? Can it call a payment API? Can it reach private data?

If the answer is buried in environment variables, shell habits, and prompt text, the system is fragile. If the answer is declared in a capability contract, the system has a chance to scale.

How does allow-only make source access reviewable?

The source-read dissection identifies allow-only as the read-side policy pattern worth stealing.

In the GitHub MCP Gateway docs summarized by the predecessor artifact, allow-only restricts which repositories can be read and at what minimum integrity level. Selectors can include public repositories, exact owner/repo matches, owner-wide patterns, and trust or approval-related rules.

The GitHub-specific labels are interesting, but the larger idea is more important: sources are not all the same.

A public README is not the same as a runtime trace. A merged source file is not the same as an unreviewed pull request. A user-approved fact is not the same as an inference. A live verified page is not the same as a local draft.

For Starkslab, this maps directly onto evidence classes:

• primary-source public evidence;
• live verified evidence;
• user-approved evidence;
• source-read inference;
• hands-on runtime validation;
• blocked or private material.

Search Console should be a read-only evidence surface unless a human approves an indexing action. Public repo source reads should stay clearly marked as source reads until runtime validation exists. Drafts should preserve that boundary instead of quietly turning "we read the docs" into "we validated the system."

How does write-sink keep agent outputs bounded?

write-sink is the matching output-side pattern.

The predecessor dissection identifies write-sink as a policy that marks where outputs are allowed to land when guards are enabled. That matters because reads and writes should not share one broad capability surface.

A safe agent system needs separate lanes for:

• internal research artifacts;
• content outlines;
• draft notes;
• deployable site source;
• Linear comments;
• public note publishing;
• Search Console Request Indexing;
• social posts;
• outreach emails;
• package/repo/account mutations.

Those are not interchangeable writes.

In Starkslab terms, writing to starkslab/research/ is not the same as writing a deployable note. A Linear comment is not a public post. A local launch packet is not a live publish. A Search Console handoff is not a Request Indexing action.

The useful rule is simple: every output surface should have a name, a scope, and a review gate.

What should Starkslab copy from the gateway pattern?

Starkslab should not blindly adopt gh-aw-mcpg just because it is interesting. The right move is to steal the operating shape.

First, use capability gateway vocabulary. Agent tool access should be routed through declared capability contracts, not inherited through ambient credentials.

Second, keep the source/write-sink split. Read evidence and output destinations should be separate surfaces. A worker that can read public GitHub metadata should not automatically be able to publish a note or request indexing.

Third, keep evidence integrity labels visible. Every artifact should make clear whether a claim comes from public source reading, live verification, runtime validation, user approval, or unvalidated inference.

Fourth, treat sandbox configuration as product surface. sandbox.mcp is a reminder that tool access is part of the product contract, not invisible deployment plumbing.

Fifth, preserve human-review promotion hooks. Starkslab can automate more internal movement, but public effects still need gates: publishing, posting, outreach, Search Console actions, account changes, billing, package mutation, and anything reputationally sensitive.

What should we not claim yet?

Because this is source-read only, the note should not claim:

• that GitHub Agentic Workflows MCP Gateway is production-ready;
• that it is easy to operate;
• that Docker socket access is safe in a given environment;
• that arbitrary MCP backends become safe because a gateway exists;
• that guard policies cover every adversarial case;
• that Starkslab has validated runtime behavior;
• that this should be deployed in the Starkslab stack now.

The safe claim is narrower and stronger: GitHub's MCP Gateway is a useful public example of agent tool access becoming a sandbox contract.

How this maps to Symphony and OpenClaw

Symphony already depends on narrow work packets, target artifacts, and review states. A future capability gateway would make the worker boundary more explicit: this task may read these sources, write this artifact, comment on this issue, and stop before these public actions.

OpenClaw already exposes powerful surfaces: files, browser, messages, sessions, GitHub, Linear, Search Console-adjacent workflows, and more. The long-term safety question is not whether those tools are useful. They are. The question is how sharply each agent receives only the capability it needs for the job.

For Starkslab's current factory, the practical takeaway is immediate: keep the boundaries visible in every note and every Linear ticket. Source-read means source-read. Runtime validation means runtime validation. Launch packet means launch packet. Human-gated means human-gated.

That discipline is not bureaucracy. It is what lets the factory move fast without accidentally turning internal work into public action.

Where this fits in the Starkslab map

This note belongs in the AI Agent Tools lane. If you want the broader build loop, read Build Your First AI Agent: A Practical Tutorial. If you want the small-framework version of the same operator discipline, read How I built a lightweight AI agent framework in Python. If you want another source-read example of tool-surface boundaries, read dmux as a worktree-native coding-agent cockpit.

The shared thread is not hype around one protocol. It is capability design: small tools, visible traces, narrow writes, and review gates before public effects.

The operator lesson

AI agent tools are moving from demo integrations toward operating systems. That shift makes tool access a first-class design problem.

The best agent stack is not the one with the longest tool list. It is the one where each worker has the right tool surface, the right source permissions, the right output sink, and a review trail the operator can trust.

That is why MCP Gateway is worth watching. Not because it magically solves agent safety. Because it gives builders a concrete shape for the question every serious agent system eventually has to answer:

what can this agent touch, and why?

If you are building agents that touch real systems, start there. More tools can wait. The sandbox contract cannot.