Servers in Japan · defense in depth · when in doubt, shut it down

Fixed forwarding destinations — the tunnel is never a passageway

WireCanal's most important layer is the fixed forwarding destination. The agent never connects to anything other than the destination you configured (loopback by default). This structurally prevents the accident where a tunnel turns into an open proxy inside your network and gets repurposed as a passageway to other systems.

Turning the entrance into a virtual leased line

WireCanal's public entrance (Edge) can be restricted to accept access only from the fixed IPs of legitimate callers. A public endpoint in form, effectively a leased line in practice. Caller token authentication adds a second layer on top. An entrance that is "public, yet as good as not public."

Defense in depth, centered on fixed forwarding destinations

WireCanal practices defense in depth built on "fail-closed (when in doubt, shut it down)." Rather than boasting numbers, here are the core layers actually in operation, as they are. The centerpiece is the fixed forwarding destination.

In addition, WireCanal provides per-canal access logs (records of incoming access; the most recent 1,000–10,000 entries depending on your plan; available via API / CSV), tenant isolation (a dedicated subdomain and unique ID per canal, with routing decided by values that cannot be spoofed), and flow control and suspension (rate / size / timeout limits, per-canal pause, and immediate cut-off from your side).

Planned for the future: tamper detection for audit logs (hash chains), certificate-based device enrollment, and per-session human approval (available for individual consultation on Enterprise).

Access protection — available on all plans

For each canal, you can apply 8 kinds of access protection to the public entrance. Every kind is available on every plan. Configure them from the "Access Protection" tab in the dashboard (grouped into caller / authentication / exposure / defensive behavior).

• check_circleIP address restriction — allow access only from the IPs / CIDRs you list (decided solely by the real IP of the connecting socket; cannot be spoofed).
• check_circleCountry restriction — allow only the countries you list, or deny only the countries you list (ISO 3166-1 alpha-2).
• check_circleBASIC authentication — username / password authentication for browsers.
• check_circleBearer token authentication — token authentication for programs (multiple tokens can coexist; passes when either this or BASIC matches).
• check_circleTime-window publishing — specify the days and hours the endpoint is public, fixed to JST (closed at all other times).
• check_circlePath restriction — limit the published URL paths by exact match / prefix match (a design that avoids regular expressions).
• check_circleAutomatic blocking (fail2ban) — automatically block callers with repeated authentication failures for a set period (default: 10 times / 10 min → 15 min, lifted automatically over time).
• check_circleStealth mode — turns every blocked response into a uniform 404, hiding the canal's very existence from the outside.

Authentication for AI (MCP) connections — compliant with standard protocols

AI services such as Claude and ChatGPT require OAuth-based authentication when connecting to remote MCP servers. WireCanal has a built-in authorization server compliant with the MCP Authorization specification (the authorization spec of the Model Context Protocol): just create a canal and choose the AI you will use, and you get a fully standards-compliant authenticated MCP endpoint. No need to stand up your own OAuth server. No advance client registration is required either (CIMD supported) — AI services can connect just by presenting a URL. Connection and operation have been verified on the actual Claude / ChatGPT / Grok screens.

• check_circleOAuth 2.1 authorization code flow + PKCE (S256 required) — structurally prevents interception of authorization codes.
• check_circleDiscovery standards supported — responds per canal with RFC 9728 (OAuth 2.0 Protected Resource Metadata) and RFC 8414 (Authorization Server Metadata). The AI service just pastes the URL and auto-detects the authentication settings (OIDC-discovery-compatible responses are supported too; proven with auto-detection in Claude, ChatGPT, and Grok).
• check_circleRFC 8707 (Resource Indicators) — access tokens are bound to a single canal (audience validation). A token cannot be reused against another canal.
• check_circleAccess tokens are short-lived signed JWTs (ES256, valid for 1 hour) — verified with the public key (JWKS), so the entrance server validates on the spot without querying a central service. Once revoked, no new tokens are issued from that point on.
• check_circleRefresh tokens rotate, with reuse detection — every refresh swaps in a new token, and if reuse of an old token is detected, the entire lineage is revoked at once.
• check_circleNo advance client registration required (CIMD) — supports the scheme where the client_id is the URL of the client's metadata document (Client ID Metadata Document). AI services connect just by presenting a URL, with no registration round-trips. Dynamic registration (DCR, RFC 7591) is also supported.
• check_circlePre-issued credentials when you want to pin the client — a client ID / secret can be issued automatically from the canal (token-endpoint authentication is client_secret_post). Only registered redirect URLs are accepted. Connection approval is granted explicitly by the canal owner on a consent screen and can be revoked at any time.

Access logs, and credentials never forwarded

Access logs: for each canal, you can review incoming access in the dashboard (and the public API) — the most recent 1,000 entries depending on your plan (10,000 on Premium / Enterprise). Who came, when, and from where can be traced after the fact. Even in stealth mode, the owner sees the true block reason recorded in the log. The list can be downloaded as CSV for your own aggregation and retention.

Credentials never forwarded: entrance authentication (MCP OAuth, or BASIC / token access protection) is verified by WireCanal at the entrance, and the Authorization header is never passed to the forwarding destination. Your internal systems can keep running locally without holding any authentication of their own, and nothing like "authentication doubled up / slipped through because of WireCanal" can happen.