Gateway approvals and agent health¶
A human approving a held tool call is the strongest governance signal the platform has. This page says when that approval counts towards an agent's health, when it does not, and why the difference is deliberate.
Two ways a call gets governed¶
| Where the decision is made | Does it know the agent? | |
|---|---|---|
guard_tool_call (Python SDK) |
in your agent's process | Yes — from coalex_context |
| MCP Gateway proxy | at gateway.coalex.ai, in front of the connector |
Only if you tell it |
The first has always counted. The second is the subject of this page: the proxy authenticates a proxy token, which is scoped to a person and a connector. It carries no agent, because the caller might be Claude Desktop, an IDE, a script, or an agent that has nothing to do with Coalex.
Making an approval count¶
Send your agent's own correlation id on the MCP request, as X-Request-Id:
# whatever MCP client you use, the header travels with the call
headers = {"X-Request-Id": request_id} # the same id you pass to coalex.evaluate()
Use the id you already use elsewhere — the request_id from coalex_context, or your trace id.
When a call held behind that id is approved or declined, the platform recovers which agent it
belonged to by matching the id against that agent's traces, and the verdict lands in the agent's
health exactly as an SDK-path approval does.
It also makes the call appear on the decision rail beside the conversation it came from, which is keyed on the same id.
Nothing else is needed: no agent id on the request, no agent on the token, no registration.
What happens when you send nothing¶
The hold still works, is still audited, and still requires a human. What it does not do is contribute to any agent's health — because there is no agent it could honestly be attributed to.
That is not a gap being tolerated; it is the correct answer. Inventing an attribution would put every MCP call in the organisation behind a single phantom agent, and unreviewed holds from a desktop client would drag a real number down.
What those calls contribute instead is the connector's posture: every one is recorded in the Bronze audit log with its policy decision, outcome, latency and upstream status, and shown on the connector's activity. That is the right unit for a surface whose caller is not an agent you run.
Why not put the agent on the token¶
It was the first idea, and the code argues against it. A proxy token is minted per user, per connector, and the common path mints it automatically during OAuth consent — there is no moment at which a human chooses an agent, and nothing meaningful to fill in. The correlation id is a better fit because it is already the thing that ties everything else about a run together.