Back to blog

Announcing Enforgate: action-boundary security for AI agents

The Enforgate Team ·

AI agents are starting to take real actions: querying production databases, sending email on a team's behalf, moving money, deleting files. The interesting question is no longer whether an agent can call a tool, it's whether it shouldhave, and whether anyone can see what it did afterward. Today we're sharing what we've built to answer that: Enforgate, an MCP gateway that puts a security boundary between agents and the tools they call.

The gap we kept running into

The Model Context Protocol gives agents a standard way to discover and call tools. That standardization is great for interoperability, but it doesn't answer the operational question every team eventually hits: once an agent has a tool, what stops it from calling delete_fileon a path it shouldn't, or firing off a thousand calls in a retry loop? Handing an agent a raw API key is a lot like handing a new intern production credentials and hoping for the best. Most teams either lock things down so hard the agent is useless, or leave them wide open and hope nothing goes wrong.

What Enforgate does

Enforgate sits between an agent and its MCP servers. Every tool call passes through the gateway, gets evaluated against a policy, and comes back with a verdict:

  • allow — the call goes through and is recorded in the audit log.
  • deny — the call is blocked, with a reason the agent (or your logs) can read.
  • require_approval — the call pauses and a person is notified to approve or deny it, by email, Slack, Teams, or Telegram.

Policies match tools by glob (delete_*, send_email, *) and can add parameter conditions, so "deny deletes" and "hold outgoing email for review" are a few rules, not a bespoke integration. Nothing is recorded without a verdict, and a missing or broken policy fails closed, never open.

Built for the operational reality of agents

Beyond the allow/deny/approve decision, Enforgate tracks the patterns that are specific to autonomous callers: a key looping on the same call past a threshold gets blocked, and a daily budget cap stops a runaway agent from racking up unbounded tool calls. Approvals carry full attribution (who resolved it, from where, by what method) and can be reversed within a configurable window if someone made the wrong call. None of this requires changing the agent's code — point it at the gateway's MCP endpoint and the policy applies to every call it already makes.

Try it

The quickstart gets a guarded tool call running in under a minute, and the playground lets you test a policy against real verdicts before connecting a live agent. If you want the deeper mechanics of how a verdict gets decided, we cover that next in how the policy engine works.