01 · Connector
A small process inside your perimeter exposes the system as an MCP server.
Connector runs alongside the system it fronts. Native MCP tool surface; per-tool authorization.
Product · Integration & Connectivity · Production
ewii
Secure MCP tunneling. Expose internal data to AI agents without opening a port, without forwarding through a foreign cloud, without exposing the system to the public internet.
The problem
Agentic AI needs to reach internal systems. Most ways of doing that are wrong.
The natural impulse is to expose an internal API endpoint to the AI provider — open a port, terminate TLS at the perimeter, hope the auth holds. The security team rejects that the first time it sees the architecture diagram. The fallback is to copy data to a vendor cloud where the agent runs. That fails the data-residency test.
ewii gives you a third option: an outbound-initiated tunnel from inside the perimeter to a broker that the agent connects to. No inbound port. No forwarded data. The internal system stays where it is; the agent reaches it through MCP, mediated.
How it works
MCP-native. Outbound-only.
02 · Tunnel
Connector dials out to the ewii broker — outbound only, no inbound port.
Persistent gRPC stream over mTLS. Survives NAT, restrictive egress, and the security team's audit.
03 · Broker
Agents connect to the broker; the broker proxies through the tunnel.
Broker holds no data — only the active tunnel sessions. Audit log per call. Deploy the broker in your tenant for full sovereign isolation.
Sovereign by default
Both ends — and the broker — can live in your perimeter.
For the simplest deployments, the broker can run as a managed service we operate. For sovereign deployments, the broker runs inside your tenant — typically next to the agent runtime (Maria, Kacha, or a custom agent runtime build). All three components — connector, broker, agent — live in your environment.
ewii does not see the data flowing through it. The broker is dumb on purpose: it routes byte streams between authenticated tunnel endpoints. The connector enforces authorization at the call site, against the policies you write.
Where it fits
Wherever an inbound port is the wrong answer.
Agent access to legacy databases
Internal SQL stores, legacy customer systems, and bespoke schemas reachable only from inside the corporate network. The connector exposes a curated set of tools — not the raw database — and the agent consumes them through MCP without anyone ever opening a public port to the database tier.
Internal REST APIs without public exposure
Existing internal services that have always been firewalled away from the internet stay that way. The connector reaches them on the inside; the agent reaches the connector through the outbound tunnel. Security review packets are short because the threat model is short.
Cross-tenant federation under explicit policy
When two organizations need a controlled bridge — a regulator and a regulated party, a parent and a subsidiary, a managed-service provider and a customer — ewii lets each side keep its own perimeter and the policy engine enforces what crosses. No shared cloud, no joint VPN, no merged network.
Air-gapped LAN-to-broker bridges
Sites where the operating network is air-gapped or has tightly restricted egress. The connector dials out on a single permitted destination through standard egress controls; nothing about the LAN posture changes. Suitable for industrial control networks and regulated facilities.
Patterns that use this product
Worked examples from real engagements.
Get started
Outbound-only. No port to defend.
Tell us which internal system you want an agent to reach. We'll have a tunnel up in a day, and a security review packet your CISO can sign.
Talk to an engineer