Lessons learned building Fronteira, an MCP proxy with behavioral guardrails

Lessons learned building Fronteira I designed a harness built on top of dependent types that uses information-flow policies to prevent attacks involving the lethal trifecta . However, expecting users to write liquid types was unrealistic, and creating a custom SDK for every external interface-filesystems, APIs, internet search and MCP tools-was not practical. Following feedback from Lisbon.ai (thanks, Nuno , Fred , Sérgio and David ), I started building Fronteira to make these technical ideas accessible to a wider audience. What is Fronteira? Fronteira is an MCP proxy that acts as a behavioral firewall. You log in through the browser and add integrations with GitHub, Gmail and other services through their MCP servers. You authenticate your harnesses with Fronteira and automatically get access to all your configured MCP servers. You also get portability across harnesses, but that is just a side effect. The main advantage of Fronteira is that all MCP interactions go through it, allowing it to track behavior across multiple MCP servers. You get tool-call logging for your harness for free-or, in an enterprise setting, for all your users. I have to admit that this was extremely useful when debugging Fronteira itself, as well as some custom MCP servers. Because all the data is centralized, we can track where information flows. In particular, this allows Fronteira to stop attacks involving the lethal trifecta . Such an attack can occur when a prompt injection causes an agent to read private data through one tool and expose it to an external endpoint through another. Requiring all interactions to pass through MCP servers is a clear limitation, which I will address later. Because there are countless MCP providers and possible combinations, each with its own schema, it is impossible for me to write a set of rules that prevents harmful actions for everyone. Instead, Fronteira allows you to write your rules in English and translates them into Guard DSL , a language evaluated deterministically on every interaction. Users are not expected to write Guard DSL themselves. Instead, they write rules in natural language and can check that the resulting code matches their expectations. The language's usability could be improved, but it is sufficient for the prototypes I have built. While the rule language is evaluated deterministically, it can invoke nondeterministic components that use decision models-currently JEV-to determine whether content contains trade secrets or medical information. There is also session-level tracking, such as read_private in the example. So far, I have not found anything I could not express, but I am sure that will happen as soon as someone else starts using it. Limitations and Technical Lessons Learned The first limitation is clear: top-level harnesses access the filesystem directly, browse the internet directly, control desktop apps and access APIs directly, usually through skills or other instructions. All these interactions bypass Fronteira, making it useless for day-to-day security in your harness. Second, harnesses come with skills that assume the user is using the harness's official Gmail integration-for example, Codex's integration. If Gmail is only available through Fronteira's MCP endpoint, Codex will sometimes fail to find it out of the box. Deploying Fronteira in the wild would therefore require us to write many skills to change this default behavior. I also learned that no one respects the fact that MCP tool lists can be dynamic according to the specification. Requests for the tool list can return different results throughout a conversation, but harnesses do not implement support for this. They load the tool list at the beginning and do not reload it unless explicitly asked. I understand the challenge: reloading it before every response would increase the load on MCP servers and add latency. I would like a flag in the response that forces clients to refresh the list. Furthermore, the MCP schema can change at any time. There is assumption that MCP schemas do not ever change, but I wonder how reliable the assumption is . MCP does not have explicit versioning , although some providers use REST-style versioned endpoints such as /api/v1 . On the other hand, I do not want Fronteira to expose a million tools at all times. I would like it to receive the prompt, or some related information, and dynamically select the relevant tools. Tools forbidden by the rules could then be excluded from the context, rather than occupying space when any attempt to call them would result in an error. The final technical lesson I learned is that I was too optimistic about trusting Codex with DevOps. I asked it to mirror another app's Django configuration for Fronteira, but it changed the server root, exposing my Resend token and allowing spammers to send spam through my account. The issue was easy to identify and fix, but I expected more from Codex. I also realized that I still do not have a security tool I can point at a deployment, rather than its source code! Alternatives to Fronteira I did not look at competitors before implementing Fronteira. This was not because of laziness or incompetence. It was simply not a priority: I wanted to build it regardless, to understand the challenges firsthand. Behavioral Rules I was aware of Dogwood , Amazon's temporal specification extension to the Cedar specification (mainly used for AWS access permissions). Dogwood can require previous explicit approval for some actions. Approval is something I wanted to add to Fronteira from the start through a mobile app. The following temporal rule in Cedar permits a share sale only if the same stock and number of shares were approved within the past hour. permit ( principal, action == AgentCore::Action::"SellShares", resource ) when temporal { formerly within 1h AgentCore::Action::"ApproveSale"::response{ input.stock: context.input.stock, input.shares: context.input.shares, output.approved: true } }; To address some of the same limitations as Fronteira, Amazon uses the Dogwood engine in the Strands SDK. By combining the policy engine with a sandbox, they prevent agents from circumventing the "firewall." This is still not foolproof: agents can use a remote browser MCP server to call APIs, avoiding detection. The Invariant SDK features dataflow guardrails . Invariant, which was acquired by Snyk, and Cordon offer MCP proxies like Fronteira. They share the same limitations, but I would like to highlight language features such as quantifiers and loop detection. MCP Proxies with Static Rules Mintive , previously MintMCP, is very similar to Fronteira, except that it does not support behavioral rules. You can still detect private information leaking through static rules, but you cannot prevent malicious sequences of individually harmless calls. Both the Lasso Security MCP Gateway and WitnessAI are very similar to Mintive: they automatically manage MCP servers and can detect leaks of information identified as private. MCP Firewall performs a similar role but also focuses on filtering MCP responses, treating their contents as untrusted because they may contaminate subsequent reasoning. NVIDIA NeMo is another proxy that validates tool parameters and responses against a range of requirements. However, it does not relate different tool calls to one another except through custom code. Endram is a proxy that decides whether each call requires manual approval, something Dogwood also supports alongside more complex features. Both WSO2 and Microsoft Global Secure Access support Cedar-like access control lists for MCP servers, with tool- and prompt-level controls. Agent Control allows you to create guardrails in Python. These operate at the level of individual tool calls, but Agent Control also integrates with external guardrail infrastructure, such as Dogwood, whose language is more expressive. Language Specification AgentSpec is a specification language like Fronteira's, with a more principled design but similar features. I would like to study properties of the language, particularly ways to provide feedback when users write inconsistent rules. Others IBM offers MCP ContextForge , a central gateway focused more on discoverability and observability. agentgateway is also mostly focused on observability. TrueFoundry focuses on the M×N problem-M harnesses connecting to N MCP servers-and observability. LlamaFirewall is similar in that it can inspect traces of calls and detect malicious patterns. However, it does so using a BERT-style LLM, whereas Fronteira primarily supports deterministic analysis. Comparison Summary Approach MCP proxying Content guards Behavioral / temporal guards Fronteira ✅ ✅ ✅ Dogwood + Strands Box ✅ ✅ ✅ Invariant + MCP Scan ✅ ✅ ✅ Cordon ✅ 🚫 🟡 Mintive / MintMCP ✅ ✅ 🟡 Lasso MCP Gateway ✅ ✅ 🚫 WitnessAI ✅ ✅ 🚫 MCP Firewall ✅ ✅ 🟡 NVIDIA NeMo Guardrails 🚫 ✅ 🟡 Endram ✅ 🟡 🚫 WSO2 MCP ACL policy ✅ 🚫 🚫 Microsoft GSA MCP firewall ✅ 🚫 🚫 Agent Control 🚫 ✅ 🟡 AgentSpec 🚫 🟡 🟡 IBM ContextForge ✅ 🟡 🚫 agentgateway ✅ ✅ 🟡 TrueFoundry ✅ ✅ 🚫 LlamaFirewall 🚫 ✅ ✅ (probabilistically) Conclusion After this exercise, I no longer believe in MCP proxies as security boundaries for agents. MCP covers only part of an agent's interaction with the world. Another reason is that MCP is a leaky abstraction. Models are post-trained in specific MCP and skill contexts, so they will always prefer direct alternatives, creating friction for the user. However, I strongly believe in the need for logic-based policies to control agents. Those policies should be enforced at the agent boundary and should probably be developed alongside the harnesses and models. I would love this enforcement to be harness-independent and provided by a third party. However, given how models are becoming increasingly harness-specific , I do not see that working in the long term. If you have read this far, I am looking for a new opportunity where I can apply my research experience in programming languages, systems and different areas of artificial intelligence to improve the safety of agentic systems. If you are looking for someone with that background, along with the agency and pace of someone who has worked at several startups, you can find my contact details on this website. Published: Oct 16 , 2026 Author: Alcides Fonseca Language: English Tags: Artificial Intelligence , AI Safety

Source: https://wiki.alcidesfonseca.com/blog/lessons-learned-building-fronteira/