Warded

Warded 身份访问网关

了解 Warded 如何通过开箱即用的身份访问网关保护 AI Agent 管理入口。

Warded 是面向 AI Agent 管理入口的开箱即用身份访问网关。

它为 OpenClaw Control UI、Hermes Agent Dashboard 以及类似的 Agent 工具提供受保护的 HTTPS 入口,将浏览器登录、Workload Access Token、TLS 终止和本地反向代理整合到一条使用路径中。

AI Agent 工具越来越多地运行在云服务器上,暴露出原本并非面向公网设计的管理入口。当服务可以从互联网访问时,单一的共享令牌或未受保护的控制面板并不足以构成可靠的安全边界。Warded 将身份认证、访问控制和 HTTPS 置于该入口之前,无需你手动拼凑 DNS、TLS、OAuth、会话管理和反向代理规则。

为什么选择 Warded

为 AI Agent 工具而生

Warded 不是一个为 Agent 改名的通用网关。它是围绕 OpenClaw、Hermes Agent、Agent 仪表盘、机器人控制面板以及类似管理入口的实际部署方式构建的:一台云服务器、一个敏感入口,以及少量需要受控访问的人员或 Workload。

开箱即用的受保护 HTTPS 入口

Warded 将域名设置、TLS 终止、基于浏览器的登录和反向代理整合到一条路径中。无需再手动拼接 DNS 提供商、证书自动续期、OAuth 回调、Cookie 会话和代理配置,你只需要创建一个 ward、在浏览器中认领它,然后通过 CLI 启动受保护的入口。

一个 ward,一个清晰的边界

一个 ward 对应一个域名和一个本地上游端口。这让安全边界、计费单元、激活状态和运行状况都易于理解和维护。如果你需要保护另一个域名或另一个管理入口,请创建另一个 ward,而不是通过路径路由将无关的服务隐藏在一起。

人类与 Workload 双路访问

浏览器用户通过 Warded 登录和本地会话 Cookie 访问受保护的服务。Agent、Bot、CI、监控和自动化客户端可以使用 Ward Access Token。这使得人类访问和 Workload 访问处于同一产品边界内,而无需强制所有客户端采用相同的认证形态。

流量直达

Warded 管理控制平面、ward 生命周期、身份状态和本地代理运行时。客户应用流量直接到达你的服务器,并经过本地 Warded 进程。Warded 不会中继或托管你受保护服务的流量。

Warded 不是什么

Warded 不是隧道、NAT 穿透服务、frp 替代品或 Tailscale 替代品。你受保护的服务仍然运行在你的服务器上,流量不会通过 Warded 基础设施进行中继。

Warded 不是通用的多服务 API 网关。当前的产品边界是一个 ward 对应一个受保护的管理入口,而不是面向多个无关服务的通用路径路由器。

Warded 不是通用的人类身份提供商。它对接受支持的登录提供商,用于所有者和浏览器访问流程;而 Ward Access Token 则覆盖受保护 ward 的 Workload 访问。

Warded 不是流量托管平台。它为受保护的入口提供生命周期、身份、域名、TLS 和本地代理控制;它不会接管你的应用运行时。

从这里开始

产品边界

每个 ward 保护一个 Agent 管理入口。一个 ward 对应一个域名和一个本地上游端口。

当前产品聚焦于 Warded Ingress:在现有 Agent UI 或仪表盘前提供受保护的浏览器和 Workload 访问边界。多域名部署使用多个 ward。

工作原理

Warded CLI

CLI 运行在你的服务器上。它负责 TLS 终止、认证中间件处理、本地会话和 Ward Access Token 校验,并将已认证流量代理到配置好的上游。

Warded Platform

平台管理 ward 生命周期、身份、域名归属、TLS 材料和计费状态。它是 ward 是否可激活、是否可服务的权威来源。

Warded Website

网站为人类所有者提供认领、账户、ward 详情和计费等流程。

ward 激活后,所有者和经批准的客户端使用受保护的域名作为 Agent 管理入口的稳定访问点。

On this page