AMVLET's Secure Border Gateway gives your organisation complete control over who can connect to your Matrix deployment — keeping approved partners seamlessly connected while blocking everything else at the door.
Every connection attempt — from partner servers, external clients, or unknown sources — passes through the gateway and is evaluated against your rules in real time.
The Secure Border Gateway gives regulated organisations what open federation alone cannot: the ability to connect selectively, enforce precisely, and audit completely.
Decide precisely which Matrix servers can communicate with yours. Maintain a list of approved partner organisations and the gateway will silently reject all others — no manual intervention required. You stay connected to who matters; you remain invisible to everyone else.
Ensure only approved Matrix applications can connect to your homeserver. Block personal and unknown clients automatically, enforce corporate-only access, and eliminate shadow IT — without disrupting any legitimate user on an approved device.
Build your security policy as a pipeline of rules, each one adding a precise layer of control. Rules can inspect any part of a request — server identity, user ID, event type, destination room. New rules can be deployed without any service interruption.
Unlike a conventional firewall, the Secure Border Gateway understands the Matrix protocol. Here is what that means in practice.
A traditional firewall sees only IP addresses and port numbers — the equivalent of knowing that a car arrived at your gate, but nothing about who is inside or what they are carrying. The Secure Border Gateway reads and understands the Matrix protocol itself. It knows whether a request is trying to join a room, send a message, or establish server-to-server federation, and it can apply different rules to each scenario.
Security decisions are made using the complete context of every request: which Matrix server it came from, the Matrix ID of the requesting user, the type of event being sent, the destination room, and the precise timestamp. No request can disguise itself by changing a single attribute — the gateway evaluates the full picture before making any decision.
Requests pass through a sequence of security checks, one after another. Each rule can allow, block, or modify the request before passing it to the next rule in the pipeline. This layered approach means complex security policies can be built from simple, composable building blocks — and individual rules can be updated without affecting the rest of the pipeline.
Organisations can write and deploy their own rules to meet specific compliance obligations. Whether you need to enforce regional data residency restrictions, apply sector-specific communication policies, or integrate with an existing identity management system, the pluggable architecture accommodates it — without modifying the core gateway or requiring downtime.
The gateway operates on the principle that no connection is trusted until it has been explicitly approved. Every request — whether from a known partner server, an internal client, or an external federation peer — must satisfy the applicable rule pipeline before being passed through. There is no implicit trust, no bypass, and no exception that is not written into your policy.
When a Matrix server joins the global network without any gatekeeping, it becomes reachable from any other Matrix server on Earth. For a commercial collaboration platform, that openness is a feature. For a government ministry, a defence contractor, or a financial institution, it represents a compliance boundary that cannot be left undefined.
Consider the practical reality: a defence organisation needs to share classified project rooms with specific cleared contractors, but not with every other Matrix user in the world. A hospital network needs to exchange patient-related communications within an approved care pathway, but must be able to demonstrate that no message ever crossed an unapproved boundary. A financial services firm must enable encrypted communications with its regulator — but MiFID II requires that those communications be monitored and archived to a defined standard.
Traditional firewalls cannot solve this problem. They work at the network layer, seeing only IP addresses and port numbers. Matrix federation runs over standard HTTPS, so a conventional firewall cannot distinguish between a legitimate partner server and an unknown one attempting unauthorised access. You need something that understands Matrix itself.
Think of the Secure Border Gateway as the security desk at the entrance of a secure building. A regular firewall is the front door — it checks whether you have the right key. The SBG is a trained security officer who not only checks your credentials, but knows exactly which rooms you are authorised to enter, what you are permitted to carry, and keeps a detailed log of your visit. Nothing gets through that the policy does not explicitly allow.
In technical terms: when any external server or client tries to connect to your AMVLET homeserver, that request first arrives at the Secure Border Gateway — not at the homeserver itself. The gateway evaluates the request against your configured rule pipeline. If the request passes all rules, it is forwarded to your homeserver. If it fails any rule, it is blocked instantly and the decision is logged. Your homeserver never sees traffic it was not supposed to receive.
Because the gateway understands the Matrix protocol at the application layer, it can see context that no IP firewall could access: which Matrix server is sending the request, which user is making it, what type of Matrix event they are attempting to send, and which room they are targeting. That rich context is what enables policy-grade enforcement — not just "block this IP address" but "allow this specific server to federate, but only for these event types, only to these rooms."
The key insight — the one that changes how regulated organisations think about Matrix — is that federation and control are not opposites. The question is not whether to open your server to the world or close it completely. The question is whether you have the tools to make a precise, auditable, enforceable decision about every connection attempt.
With the Secure Border Gateway, you do. You can federate with the five partner organisations your compliance framework requires, while remaining unreachable by every other Matrix server on Earth. You can allow your regulator to join specific audit rooms, while maintaining a complete record of every message that crossed that boundary. You can connect your overseas offices into a single sovereign deployment, while enforcing the data residency requirements that apply to each jurisdiction.
This is sovereign federation. Not a binary choice between open and closed, but a precise, configurable, auditable boundary that you define and control completely.
The questions security, compliance, and engineering teams ask before deploying a Secure Border Gateway.
See how AMVLET's Secure Border Gateway gives your regulated organisation the precise federation control it requires — without sacrificing interoperability.