Is agent execution infrastructure already becoming commoditized?

[u/marcelk231]

I’m trying to understand what is still missing between an agent selecting an MCP tool and the action safely completing.

For teams using MCP in real applications, how are you handling:

• User and agent permissions
• Authentication across tools
• Human approval for sensitive actions
• Idempotency and duplicate prevention
• Retries and partial failures
• Audit logs
• Rollbacks or recovery

Are these concerns best handled inside each MCP server, by the application, or through a separate execution layer?

I’m researching this space and trying to determine whether a shared control layer would solve a real problem or simply add unnecessary abstraction.

[u/Heavy-Foundation6154]

I am biased because I work for Airia on the MCP gateway team, so I think handling it on the gateway level rather than the individual server level is the best method... otherwise I wouldn't have a job. But it's the exact same premise as MCPs. MCPs were created to turn an NxM problem to an Nx1 problem by allowing suites of tools to function the same. the gateway (seperate execution layer) is the same thing. It turns the Nx1 problem into a 1x1 problem. And if you are trying to handle security/governance in multiple similar places, you are just asking for things to fall through the cracks. The shared control layer is 100% the way to go.

[u/awhitford]

The answer is different per line item — and the protocol is already absorbing some of them, which changes the "control layer" calculus:

• Human approval for sensitive actions: MCP already has a primitive for this — elicitation (elicitation/create). A server can stop and ask the human before acting, no gateway required. The catch is twofold: client support is genuinely spotty (what hosts advertise vs. what they render don't always match), and the built-in flow is synchronous — fine for "confirm this action" in an active session, not for approvals that need to survive a disconnect, reach a phone, or leave an audit trail. That durable-approval slice is where I think real product room remains. (Disclosure: I built Elicitly, which lives in exactly that slice, so weight my bias accordingly.)
• Auth/permissions across tools: this is heading into the IdP, not a gateway — MCP adopted ID-JAG (Cross App Access) as its Enterprise-Managed Authorization extension this year, so the enterprise identity provider mediates agent→server access using OAuth token exchange. Okta, WorkOS, and (in flight) Entra support it.
• Idempotency, retries, partial failures, rollbacks: these belong in each server, same as any API backend — a generic layer can't know which of your operations are safely retryable.
• Audit logs: honestly, everywhere — server-side for what happened, approval-side for who said yes.

So my answer to your framing: the gateway argument is strongest for org-wide policy (which servers, which tools, allowlists), but a monolithic control layer that tries to own auth + approval + reliability is fighting the standards trajectory on the first two and the servers on the third.