Die AgentinNICOLENDERS.COM
DEEN
← Dispatches

AnalysisTHE HANDLERTHE TECHNICIAN

Agents Build It. You Ship It.

Published

Verriegeltes FörderbandAI generated
Govern MCP tools by using an AI gatewayMicrosoft Learn

On 1 September GitHub shipped a setting that lets Copilot code review approve a pull request, and that approval counts towards the required-reviews rule. I read the changelog twice. A year ago nobody seriously discussed this: one agent writes the code, another reviews it, a third signs it off. If what ships is itself an agent, there is no longer a single point in the loop that a human is forced to pass through.

In this piece I walk through one such loop end to end: a GitHub issue is picked up by the Copilot cloud agent, checked by agentic code review, and merged only if it passes gates a human wrote down. What ships is a Foundry agent, and evaluations keep running after it goes live. The thesis fits in one sentence: instructions are a request, a gate is a decision.

The loop has become faster and sturdier

The Copilot coding agent has been GA since September 2025 and, since April 2026, goes by Copilot cloud agent because it is no longer tied to pull requests. You assign it an issue, it works in a GitHub Actions environment you prepare through .github/workflows/copilot-setup-steps.yml, and it opens a pull request. A single run is hard-capped at 59 minutes. That is enough for a well-cut issue and not for a badly cut one, which turns out to be a useful discipline.

GitHub has clearly invested in the guardrails. The agent only pushes to its own copilot/ branches. It cannot approve or merge its pull request, and whoever assigned the task is not allowed to approve it either. Workflows on its branches only run once someone with write access explicitly starts them. CodeQL, secret scanning and an Advisory Database check run automatically, and since June 2026 they also cover Claude and Codex, which work in the same flow through Agent HQ in public preview.

Copilot code review has run on an agentic, tool-calling architecture since March 2026, and that architecture is GA. A ruleset can request the review automatically. It is not free: since June 2026 GitHub bills in AI Credits, and reviews consume Actions minutes on top. Budget for it rather than finding it on the invoice.

Instructions are a request

.github/copilot-instructions.md, .github/instructions/*.instructions.md, AGENTS.md: the cloud agent and code review read all three. They are useful, and they are not a control. GitHub says so itself: because AI is non-deterministic, Copilot will not follow your instructions the same way every time.

Anthropic is even more explicit for Claude Code. CLAUDE.md is treated as context and expressly not as enforced configuration. If you need to stop an action reliably, the documentation sends you to a hook.

Two vendors, one message. It drives the most important design choice for your repository: anything that must hold does not live in a Markdown file for the model. It lives in a mechanism the platform enforces.

A gate is a decision

A repository built for agentic development should therefore keep the two categories strictly apart.

The last row deserves a closer look. According to the documentation, the cloud agent's firewall only applies to processes the agent starts through its Bash tool. MCP servers and setup steps are outside it, and GitHub itself says it is not a comprehensive security solution.

Approval by code review has been in public preview since 1 September and is off by default. My recommendation: switch it on for application code if your team wants it, but exclude every path that defines a gate. .github/, rulesets as code and eval thresholds belong under CODEOWNERS with a human review. Otherwise one agent can loosen the rule the next agent is measured against.

What ships is an agent

On the far side of the merge sits Microsoft Foundry. The new Foundry Agent Service has been GA since March 2026, builds on the Responses API and versions agents. For a lifecycle that is the key point: a deployment is a version, a rollback is the previous one. Hosted agents went GA in July 2026. The visual workflows, by contrast, are being retired on 1 December 2026, with Microsoft pointing to Microsoft Agent Framework, which reached 1.0 in April 2026.

For model selection I use the model router. It is GA and picks a model from a pool per request, in Balanced, Quality or Cost mode. The trade-off: your agent no longer runs on one model but on a distribution. The context window is set by the smallest model in the pool, and an evaluation that measures one mode tells you nothing about the others.

Guardrails and controls know four intervention points: user input, tool call, tool response and output. For plain models the outer two are GA. At agent level the whole thing is preview, and the documentation contains a sentence worth knowing: risks that agents do not yet support do not take effect, even if you have configured them. A guardrail that silently does nothing is worse than none.

In front of the models sits the AI gateway, built on Azure API Management. It enforces TPM limits and token quotas per project. Under heavy parallel load consumption can briefly overshoot the limit, and the documentation says so.

The catch: tool calls that never reach your gateway

This is the gap the product pages say little about. Governing tools through an AI gateway is in preview, and the documentation is unambiguous: "AI gateways support only MCP tools." Foundry tools such as SharePoint, code-first MCP tools, tools with managed OAuth and OpenAPI tools do not pass through. Only new MCP tools created in the portal are covered. Existing tools are not picked up retroactively, and the gateway does not log tool traces.

In practice your gateway is a gate for tokens, not for actions. An agent writing to a line-of-business system through an OpenAPI tool does so outside your token limits and traffic policies. Control over actions lives elsewhere: in the tool-call guardrail (preview), in network egress controls for hosted agents (preview), and in an Entra Agent ID with least privilege.

Microsoft has seen this. The new AI gateway tier of API Management, in public preview since July 2026 in two regions and without an SLA, is meant to put models and tools behind one endpoint. I would not base a production decision on it today.

Where the sources disagree

The Agent Service GA post from March lists continuous production monitoring as part of the GA scope. The monitoring dashboard documentation marks recurring evaluations, red-team scans and alerts as preview. Probably both are true, because the service is GA and individual surfaces are not. For planning purposes, the stricter reading wins.

What I cannot judge yet: whether the model calls an agent makes internally, and built-in tools such as code interpreter or file search, go through the gateway. The documentation only talks about model deployments and MCP tools. Check it in your own environment with traces. Until then I treat it as not covered.

Excursion: Claude Code, because the patterns transfer

Claude Code separates request and decision particularly cleanly. CLAUDE.md is context. Hooks, by contrast, run deterministically at fixed points in the lifecycle, and a PreToolUse hook exiting with code 2 blocks the tool call before permission rules are even evaluated. Deny rules beat allow rules and are enforced by the client, not the model. Through anthropics/claude-code-action the same runs in GitHub Actions, optionally with inference through Microsoft Foundry, where Claude has been GA since June 2026.

What I find telling is that the gap has the same shape. Claude Code's sandbox only isolates shell commands; MCP servers and hooks run outside it. GitHub's firewall only covers the Bash tool. In Foundry only some tools reach the gateway. Three vendors, three control points, and in every case the tool path is the part you have to secure yourself.

The checks that have to hold before agents ship

  1. No merge without required status checks whose thresholds a human set, including an evaluation of the agent.
  2. Gate files under CODEOWNERS with a human review, and Copilot approval excluded for those paths.
  3. Every deployment is a pinned agent version in Foundry Agent Service, and the rollback has been tested.
  4. Model router with a fixed model subset, evaluated in every mode you use in production.
  5. A tool inventory with a column "goes through the gateway: yes or no", and a dedicated control for every no.
  6. Tool-call and tool-response guardrails switched on, planned as preview, with a test proving they act at agent level.
  7. Evaluations keep running after go-live, with an alert and a named person who receives it.
  8. A cost model for AI Credits, Actions minutes and token quota before the first agent reviews automatically.

My assessment

I think the direction is right. The loop today is fast and noticeably sturdier than the demos of a year ago, and the platforms provide the building blocks for real gates. I keep two reservations. The very controls that govern agent actions are in preview. And for all three vendors, part of the tool path sits outside central control.

Agents build it. You ship it. That is not a division of labour, it is a question of accountability, which is why the decision belongs in a gate and not in a prompt. No loose ends, keine losen Enden.

Sources

Microsoft Foundry · Development