Show HN: Keypost – Policy enforcement for MCP pipelines
keypost.aiHi HN, I built Keypost after running into the same problem repeatedly with MCP servers. They expose powerful tools, but there is no standard way to control who can call what, with which parameters, or under what limits. Keypost sits in the request path between an agent and an MCP server and enforces deterministic policies before tools run. That includes tool allow or deny rules, parameter constraints, rate and cost limits, and auditing. There are no SDKs or agent changes required. You swap one URL and policies apply consistently. I wrote up how the policy engine works here: https://keypost.ai/policy-model We are in private beta and mainly looking for feedback from people actively experimenting with MCP servers or agent workflows.
We’ve seen similar issues while building GTWY. What mattered most for reliability wasn’t how smart the agent was, but how tightly its behavior was constrained at each step.
Policy enforcement feels most effective when it’s scoped to intent, not to the agent as a whole. If a step can only do one narrow thing, you don’t need heavy guardrails everywhere else. The system becomes predictable by construction.
Interesting to see this applied at the pipeline level. Feels like the ecosystem is converging on the idea that fewer degrees of freedom beats more clever models in production.
That matches what we’ve seen too. Reliability seems to come from tightening the scope of each step, not from making the agent itself more sophisticated.
The intent boundary is the key thing for us. Rather than reasoning about an agent end to end, Keypost evaluates policy at a single tool call or pipeline step. If that step is narrow, enforcement stays simple and failures are easier to understand.
Putting those constraints in the pipeline instead of inside each agent has held up better for us as agents change over time. How are you scoping intent in GTWY today?