Should AI agent tool calls be checked before they run?

[gderamchi]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

I opened an OSS PR for a local MCP policy gateway and would love MCP-specific feedback.

Tide sits before MCP tool calls and applies deterministic pre-execution policy: allow / deny / escalate.

I’m especially looking for feedback on whether this belongs as a gateway pattern in MCP workflows, and what policy cases would be useful or wrong.

PR: rippletideco/rippletide#63

Relevant Links

rippletideco/rippletide#63

[cristianleoo]

This pattern makes sense to me as a gateway, as long as it stays explicit about what it can prove. The useful part is not just "ask before tool call"; it is having a deterministic layer that can normalize the call, classify the risk, and leave a decision record before the model or client mutates anything.

The policy cases I would want first are the boring ones:

• filesystem writes outside an allowed workspace
• shell execution, package installs, and process spawning
• network calls to non-allowlisted domains
• credential/token reads or writes
• customer/account/billing mutations
• tool calls whose arguments include untrusted content returned by another tool

The cases where I would be careful are broad semantic rules like "is this safe?" or "is this user intent?" Those can be useful as escalation signals, but I would not want them to be the only gate. For MCP specifically, a gateway is strongest when it can bind the decision to the exact server, tool name, normalized args, caller/session id, policy version, and expiry. If any of those change, the approval should not silently carry over.

I would also make the output inspectable: allow/deny/escalate, matched policy, redacted args, approval id if any, and execution result after the call. That makes it easier for client authors to debug false positives and gives operators a run receipt rather than a transient prompt.

Disclosure: I work on Armorer Labs.