Dora NodaOpen a repo on GitHub today and a pull request might have been opened by Copilot, reviewed by Claude, and merged after Codex ran the test suite — three different AI vendors, one branch, no way to tell from the commit history which one you're actually trusting. That's not a hypothetical. It's what GitHub's Agent HQ shipped: a "mission control" layer that lets a team direct, monitor, and govern coding agents from Anthropic, OpenAI, and other vendors, all running in parallel against the same codebase.
If you build a deploy platform with an MCP server — a deploy, rollback, or logs tool an AI agent can call directly — Agent HQ just handed you a concrete design question, not an abstract one: when a deploy call arrives, does your server need to know which AI vendor issued it? Or is "an authenticated identity called this tool" already the right line to draw, regardless of whether that identity is currently driving Claude, Codex, or Copilot?
The short answer, grounded in how Agent HQ itself is built and in a protocol-level change MCP shipped the same week this post went up: the calling identity is the trust boundary. The vendor brand is a routing choice, not a security boundary. Here's the evidence, and what it means for how you should actually build the auth layer on an agent-facing MCP server.
What Agent HQ Actually Shipped
GitHub unveiled Agent HQ at Universe on October 28, 2025, then brought Anthropic's Claude and OpenAI's Codex into public preview alongside its own Copilot agent on February 4, 2026 — no separate subscription required, bundled into existing Copilot Pro+ and Enterprise plans. Three pieces matter for the trust-boundary question:
- Mission Control — a single command center, consistent across the GitHub web UI, VS Code, mobile, and CLI, where a developer assigns, steers, and tracks work across whichever agents are active on a repo.
- Plan Mode — a developer describes a high-level objective; Agent HQ breaks it into steps and suggests which agent is best suited for each one, so a single task can hand off between vendors mid-flight.
- Control Plane — the enterprise governance layer: granular access policies, agent allowlists, audit logging, and sandboxed execution. Reporting on the launch describes agents from multiple vendors operating "within GitHub's security perimeter, using the same identity controls, branch permissions and audit logging that enterprises already trust for human developers." Concretely, agents are restricted to pushing only to branches they created — they can't touch
mainor a human teammate's branch — and they execute inside sandboxed GitHub Actions runners with firewall protections.
Read that Control Plane description again: identity controls, branch permissions, audit logging. Not "Claude gets policy A, Codex gets policy B." One governance model, applied uniformly, regardless of which vendor's model is doing the reasoning behind a given tool call.
The Governance Model Answers the Question Before You Ask It
This is the part worth sitting with. GitHub had every reason to build vendor-aware governance — Agent HQ explicitly supports multiple competing AI vendors, and a naive design would gate each one separately. It didn't. The allowlist, the branch restriction, and the audit trail all attach to the same place: the identity the org already controls, extended to whichever agent is currently acting under it. An org admin who hasn't approved a given model blocks it at the identity/policy layer — not by teaching every downstream system to recognize a new vendor.
That's the pattern a self-hosted PaaS's own MCP server should copy, and it's worth being precise about why it works: an agent calling a deploy tool through Agent HQ is still operating through a GitHub App installation, an OAuth grant, or a CLI session tied to an org and a human owner. The vendor is upstream of that identity, not part of it. Vendor brand is metadata about how the call got constructed — which model reasoned its way to calling deploy — not who is accountable for the call having been made. Authorization decisions belong on the second question.
MCP's Own Spec Just Confirmed the Same Design
If Agent HQ's governance model is one data point, MCP's protocol-level identity design is a second, independent one — and it points the same direction. The Model Context Protocol's 2026-07-28 specification update formalizes exactly this: identity attaches to the calling application, not to the underlying model. Every request now carries client identity in a _meta field:
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}That clientInfo block travels with the request regardless of which model is driving the client — Claude, Codex, or a homegrown agent framework all populate the same field with their own application identity, not a model name. The same spec update also formalizes an Enterprise Managed Authorization (EMA) extension and moves to a fully stateless core — no session handshake, so client identity and capabilities travel on every request instead of being negotiated once and cached server-side. The design intent is explicit: the tool server's trust decision is about the calling application (and, through EMA, the enterprise that authorized it), not about which model is inside the loop generating the tool call.
Two systems — GitHub's own multi-vendor orchestration product and the open protocol those agents speak to reach a tool server — independently converge on the same answer: identity is an application/organization-level property, not a per-model one.
What This Means for bex's MCP Server
Concretely, this rules out a design that's tempting to reach for: a header like X-Agent-Vendor: claude that your deploy tool checks before deciding what a caller is allowed to do. Don't build that. It adds a second, weaker identity system next to the one you already trust (the GitHub App installation token, OAuth client, or API key that authenticated the call), and it's spoofable by anything that can set an HTTP header — an agent framework has no reason to tell the truth about which vendor built it, and no way for your server to verify the claim even if it does.
Instead, the authorization decision on a deploy, rollback, or logs tool call should rest entirely on the calling identity your server already issues and controls: which GitHub App installation, which OAuth client, which API key — tied to a human owner and an org, exactly like Agent HQ's branch-permission model ties every agent's push access back to the identity that installed it. A concrete audit-log line needs no vendor field to make an authorization decision defensible after the fact:
{
"timestamp": "2026-07-28T14:32:07Z",
"tool": "deploy",
"installation_id": "app-inst-8841",
"org": "acme-corp",
"actor": "jane@acme-corp.dev",
"repo": "acme-corp/api-service",
"result": "success"
}Every field there is something your server issued or verified. None of them require trusting a claim about which model made the call.
Where Vendor Identity Actually Does Matter
None of this means vendor identity is useless — it just isn't an authorization input. It's an observability one. If a given installation's call volume to deploy spikes 50x in an hour, that's worth flagging regardless of which agent triggered it — a runaway retry loop looks the same from a rate-limiting perspective whether it's Claude, Codex, or a buggy custom script. Logging a self-reported vendor label alongside the authenticated fields above is fine, even useful for debugging which agent framework tends to generate malformed tool calls — but it belongs in the metadata column, not the if statement that decides whether the call gets to run.
The distinction is the whole lesson: log vendor identity for observability, gate access on the identity you actually control. Agent HQ didn't need to invent per-vendor security because the identity layer underneath every agent — human or AI — was already doing that job. An MCP server sitting behind a deploy platform doesn't need to invent one either.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server built around exactly this identity model: the calling installation, not the calling model, is what's authorized to deploy. Star the repo on GitHub or deploy your first app today.
