From f2c70b21ed654316bfbc6aa9266c28882c4a10dc Mon Sep 17 00:00:00 2001 From: Teo Calin Date: Thu, 1 Oct 2026 13:33:32 +0300 Subject: [PATCH] Remove the hosted control plane from the site The hosted control plane has been retired. Remove what described it: - The seven docs/managed-* pages and their plain twins, their data file and component, and the docs navigation and index entries. - The /enterprise/autonomous-ai-agents and /enterprise/claude-code-management landing pages and their stylesheet. - Footer, blog call-to-action, SEO title and llms.txt links to those pages. Old URLs redirect to /docs/enterprise. The harness integration posts now say what `pilot-mcp setup` does after the same removal there: it registers the MCP server and removes the tool hooks earlier releases installed. public/install.sh is synced with pilot-protocol/release (managed adoption removed). The enterprise-* docs and the governance page are unchanged: they describe network RBAC, identity, policy and audit, not the hosted product. Co-Authored-By: Claude Opus 5.5 --- public/_redirects | 25 +- public/install.sh | 377 +---- public/llms.txt | 6 +- scripts/gen-apps.mjs | 10 +- scripts/regen-plain.mjs | 5 - src/components/Footer.astro | 4 +- src/components/ManagedPlainDoc.astro | 20 - src/data/apps.ts | 2 +- src/data/blogPosts.json | 36 +- src/data/docsNav.ts | 15 - src/data/managedDocs.ts | 547 ------- src/layouts/BlogLayout.astro | 16 +- src/lib/seo.mjs | 2 - ...onnect-claude-code-to-pilot-protocol.astro | 6 +- .../connect-cline-to-pilot-protocol.astro | 8 +- .../connect-codex-cli-to-pilot-protocol.astro | 10 +- .../connect-cursor-to-pilot-protocol.astro | 8 +- ...connect-gemini-cli-to-pilot-protocol.astro | 8 +- ...ect-github-copilot-to-pilot-protocol.astro | 8 +- .../connect-hermes-to-pilot-protocol.astro | 8 +- .../connect-openhands-to-pilot-protocol.astro | 10 +- .../connect-picoclaw-to-pilot-protocol.astro | 10 +- ...s-pilot-agent-networking-one-command.astro | 8 +- src/pages/docs/index.astro | 7 - src/pages/docs/managed-accounts.astro | 16 - src/pages/docs/managed-agent-adoption.astro | 16 - src/pages/docs/managed-control-plane.astro | 16 - src/pages/docs/managed-fleet.astro | 16 - src/pages/docs/managed-harnesses.astro | 16 - src/pages/docs/managed-policies.astro | 16 - src/pages/docs/managed-readiness.astro | 16 - .../enterprise/autonomous-ai-agents.astro | 201 --- .../enterprise/claude-code-management.astro | 217 --- src/pages/plain/docs/index.astro | 4 +- src/pages/plain/docs/managed-accounts.astro | 4 - .../plain/docs/managed-agent-adoption.astro | 4 - .../plain/docs/managed-control-plane.astro | 4 - src/pages/plain/docs/managed-fleet.astro | 4 - src/pages/plain/docs/managed-harnesses.astro | 4 - src/pages/plain/docs/managed-policies.astro | 4 - src/pages/plain/docs/managed-readiness.astro | 4 - src/pages/trust.astro | 2 +- src/styles/enterprise-pages.css | 1432 ----------------- 43 files changed, 148 insertions(+), 3004 deletions(-) delete mode 100644 src/components/ManagedPlainDoc.astro delete mode 100644 src/data/managedDocs.ts delete mode 100644 src/pages/docs/managed-accounts.astro delete mode 100644 src/pages/docs/managed-agent-adoption.astro delete mode 100644 src/pages/docs/managed-control-plane.astro delete mode 100644 src/pages/docs/managed-fleet.astro delete mode 100644 src/pages/docs/managed-harnesses.astro delete mode 100644 src/pages/docs/managed-policies.astro delete mode 100644 src/pages/docs/managed-readiness.astro delete mode 100644 src/pages/enterprise/autonomous-ai-agents.astro delete mode 100644 src/pages/enterprise/claude-code-management.astro delete mode 100644 src/pages/plain/docs/managed-accounts.astro delete mode 100644 src/pages/plain/docs/managed-agent-adoption.astro delete mode 100644 src/pages/plain/docs/managed-control-plane.astro delete mode 100644 src/pages/plain/docs/managed-fleet.astro delete mode 100644 src/pages/plain/docs/managed-harnesses.astro delete mode 100644 src/pages/plain/docs/managed-policies.astro delete mode 100644 src/pages/plain/docs/managed-readiness.astro delete mode 100644 src/styles/enterprise-pages.css diff --git a/public/_redirects b/public/_redirects index d11e3188..c529b308 100644 --- a/public/_redirects +++ b/public/_redirects @@ -23,21 +23,40 @@ /plain/terms/ /terms 301 /docs/polo /for/networks 301 /docs/polo/ /for/networks 301 -/docs/console-guide /enterprise/autonomous-ai-agents 301 -/docs/console-guide/ /enterprise/autonomous-ai-agents 301 +/docs/console-guide /docs/enterprise 301 +/docs/console-guide/ /docs/enterprise 301 /blog/service-agents-overlay-network /docs/service-agents 301 /blog/understanding-autonomous-agent-networking-distributed-ai /blog/autonomous-agent-networking-distributed-ai 301 /blog/openclaw-task-delegation-polo-reputation /blog/build-openclaw-agent-self-organizes-pilot 301 /blog/openclaw-task-delegation-polo-reputation.html /blog/build-openclaw-agent-self-organizes-pilot 301 /blog/decentralized-task-marketplace-agents /blog/build-ai-agent-marketplace-discovery-reputation 301 /blog/decentralized-task-marketplace-agents.html /blog/build-ai-agent-marketplace-discovery-reputation 301 -/blog/pilot-console-manage-agent-networks /enterprise/autonomous-ai-agents 301 +/blog/pilot-console-manage-agent-networks /docs/enterprise 301 /blog/ten-thousand-agents-three-vms /blog/scaling-openclaw-fleets-thousands-agents 301 /blog/ten-thousand-agents-three-vms.html /blog/scaling-openclaw-fleets-thousands-agents 301 /blog/polo-score-reputation-without-blockchain /blog/preferential-attachment-ai-networks-trust-graph 301 /blog/how-to-wrap-legacy-protocols-for-p2p-ai-networks /blog/legacy-protocol-integration-for-secure-distributed-ai 301 /blog/network-security-checklist-for-decentralized-p2p-ai-systems /blog/network-security-for-multi-agent-systems-key-strategies 301 +# The hosted control plane was retired (2026-10). Its landing pages and docs +# go to the enterprise overview, which covers the controls that remain. +/enterprise/autonomous-ai-agents /docs/enterprise 301 +/enterprise/claude-code-management /docs/enterprise 301 +/docs/managed-control-plane /docs/enterprise 301 +/docs/managed-accounts /docs/enterprise 301 +/docs/managed-agent-adoption /docs/enterprise 301 +/docs/managed-harnesses /docs/enterprise 301 +/docs/managed-policies /docs/enterprise 301 +/docs/managed-fleet /docs/enterprise 301 +/docs/managed-readiness /docs/enterprise 301 +/plain/docs/managed-control-plane /plain/docs/enterprise 301 +/plain/docs/managed-accounts /plain/docs/enterprise 301 +/plain/docs/managed-agent-adoption /plain/docs/enterprise 301 +/plain/docs/managed-harnesses /plain/docs/enterprise 301 +/plain/docs/managed-policies /plain/docs/enterprise 301 +/plain/docs/managed-fleet /plain/docs/enterprise 301 +/plain/docs/managed-readiness /plain/docs/enterprise 301 + # Consolidate an overlapping P2P explainer into the more complete article. /blog/why-secure-direct-p2p-connections-matter-for-ai-agents /blog/why-direct-p2p-connections-power-secure-ai-networking 301 diff --git a/public/install.sh b/public/install.sh index fea6d263..ee82b5dd 100755 --- a/public/install.sh +++ b/public/install.sh @@ -16,8 +16,6 @@ set -e # before auto stay on UDP unless given --transport compat, and # use no proxy: the installer prints what to do instead. # Proxy credentials that rotate: see PILOT_PROXY_CMD below) -# Managed node: export PILOT_ENROLLMENT_TOKEN # enter it without putting it in shell history -# sh install.sh --managed-url https://management.pilotprotocol.network # Uninstall: curl -fsSL https://pilotprotocol.network/install.sh | sh -s uninstall # # Flags: @@ -38,12 +36,6 @@ set -e # $HTTPS_PROXY/$ALL_PROXY when set (CONNECT by hostname) — # for UDP-blocked hosts and agent sandboxes whose only way # out is an HTTPS proxy. -# --managed-url -# Install the checksum-pinned core managed runtime, claim -# a one-time hosted identity, and start signed reporting. -# This does not install pilot-mcp or a harness adapter. -# --no-start With --managed-url, install and adopt without starting -# the daemon. The hosted onboarding flow omits this flag. # # Legacy env vars (still honored, lower precedence than flags): # PILOT_RELEASE_TAG=vX.Y.Z Same as --version. @@ -64,9 +56,6 @@ set -e # PILOT_ALLOW_ROOT=1 Install as root on a host with systemd/launchd, # or under sudo/doas (not needed where the agent # itself is root in a container/VM without systemd). -# PILOT_MANAGEMENT_URL=https://management.example -# Same as --managed-url. Requires the one-time -# PILOT_ENROLLMENT_TOKEN on first adoption. # # Proxies: every download is a curl HTTPS request, so HTTPS_PROXY / https_proxy / # ALL_PROXY / NO_PROXY are honored (curl asks the proxy to CONNECT by hostname — @@ -145,7 +134,6 @@ REGISTRY="${PILOT_REGISTRY:-$DEFAULT_REGISTRY}" BEACON="${PILOT_BEACON:-$DEFAULT_BEACON}" PILOT_DIR="$HOME/.pilot" BIN_DIR="$PILOT_DIR/bin" -MANAGED_CONTROL_PATH="$PILOT_DIR/managed/enterprise-control.json" # validate_safe LABEL VALUE EXTRA — abort if VALUE contains any character # outside [A-Za-z0-9] plus the punctuation in EXTRA. These values are @@ -188,8 +176,6 @@ PILOT_REQUESTED_VERSION="" PILOT_REQUESTED_CHANNEL="" PILOT_YES=0 PILOT_NO_WARN=0 -PILOT_MANAGED_NO_START=0 -PILOT_MANAGEMENT_URL="${PILOT_MANAGEMENT_URL:-}" PILOT_POSITIONAL="" PILOT_REQUESTED_TRANSPORT="" @@ -214,13 +200,6 @@ while [ $# -gt 0 ]; do PILOT_YES=1; shift ;; --no-warn) PILOT_NO_WARN=1; shift ;; - --managed-url|--management-url) - if [ $# -lt 2 ]; then echo "Error: $1 requires an HTTPS origin" >&2; exit 2; fi - PILOT_MANAGEMENT_URL="$2"; shift 2 ;; - --managed-url=*|--management-url=*) - PILOT_MANAGEMENT_URL="${1#*=}"; shift ;; - --no-start) - PILOT_MANAGED_NO_START=1; shift ;; -h|--help) # The usage header: from line 4 up to "WHAT THIS SCRIPT DOES". awk 'NR >= 4 { if (/^# WHAT THIS SCRIPT DOES/) exit; print }' "$0" 2>/dev/null \ @@ -239,70 +218,6 @@ while [ $# -gt 0 ]; do esac done -PILOT_MANAGED_MODE=0 -MANAGED_TOKEN="" -if [ -n "$PILOT_MANAGEMENT_URL" ]; then - PILOT_MANAGED_MODE=1 - # Accept a cosmetic trailing slash, but require an HTTPS origin with no - # credentials, path, query, or fragment. The value later becomes both a - # manifest URL and the enrollment authority endpoint. - PILOT_MANAGEMENT_URL="${PILOT_MANAGEMENT_URL%/}" - case "$PILOT_MANAGEMENT_URL" in - https://*) ;; - *) echo "Error: --managed-url must be an HTTPS origin." >&2; exit 2 ;; - esac - _managed_host="${PILOT_MANAGEMENT_URL#https://}" - case "$_managed_host" in - ""|*/*|*@*|*\?*|*\#*) - echo "Error: --managed-url must not contain credentials, a path, query, or fragment." >&2 - exit 2 ;; - esac - validate_safe "management host" "$_managed_host" ".:-" - - if [ -n "$PILOT_POSITIONAL" ]; then - echo "Error: --managed-url cannot be combined with an install/uninstall positional command." >&2 - exit 2 - fi - if [ -n "$PILOT_REQUESTED_VERSION" ] || [ -n "${PILOT_RELEASE_TAG:-}" ] \ - || [ -n "$PILOT_REQUESTED_CHANNEL" ] || [ "${PILOT_RC:-}" = "1" ]; then - echo "Error: managed adoption uses the runtime pinned by the management authority; do not combine it with --version or --channel." >&2 - exit 2 - fi - - MANAGED_TOKEN="${PILOT_ENROLLMENT_TOKEN:-}" - # Do not let the bearer secret reach curl, tar, service managers, or any - # other child. It is exported only to the single pilotctl claim process. - unset PILOT_ENROLLMENT_TOKEN - if [ -e "$MANAGED_CONTROL_PATH" ]; then - if [ -L "$MANAGED_CONTROL_PATH" ] || [ ! -f "$MANAGED_CONTROL_PATH" ]; then - echo "Error: the existing managed control attachment is not a regular file." >&2 - exit 1 - fi - if [ -n "$MANAGED_TOKEN" ]; then - echo "Error: this node is already managed; refusing to consume a new enrollment token." >&2 - echo " Re-run without PILOT_ENROLLMENT_TOKEN to repair or update the managed runtime." >&2 - exit 1 - fi - else - if [ -z "$MANAGED_TOKEN" ]; then - echo "Error: PILOT_ENROLLMENT_TOKEN is required for first managed adoption." >&2 - exit 1 - fi - _managed_token_bytes=$(printf '%s' "$MANAGED_TOKEN" | wc -c | tr -d ' ') - if [ "$_managed_token_bytes" -gt 4096 ] \ - || LC_ALL=C printf '%s' "$MANAGED_TOKEN" | grep -q '[[:cntrl:]]'; then - echo "Error: PILOT_ENROLLMENT_TOKEN is invalid." >&2 - exit 1 - fi - fi - # Managed credentials and state created by this process default owner-only. - umask 077 - MANIFEST_URL="${PILOT_MANAGEMENT_URL}/.well-known/pilot-managed-runtime.json" -elif [ "$PILOT_MANAGED_NO_START" = "1" ]; then - echo "Error: --no-start is only valid with --managed-url." >&2 - exit 2 -fi - # Validate channel value early so we fail fast. `edge` is a back-compat alias # for `beta`: the manifest publishes channels.stable and channels.beta only, so # a literal `edge` lookup would resolve empty and (previously) silently fall @@ -376,47 +291,6 @@ if [ "${1:-}" != "uninstall" ] && [ "$(id -u)" = "0" ] && [ -z "${PILOT_ALLOW_RO fi fi -# A managed identity is per node, but the CLI links, service label and daemon -# socket are machine-wide. A different HOME therefore does not make a second -# installation safe. Refuse before downloading, stopping services, replacing -# links or consuming the enrollment token. An existing attachment in this -# same PILOT_DIR remains the ordinary repair/update path handled above. -if [ "$PILOT_MANAGED_MODE" = "1" ] && [ ! -e "$MANAGED_CONTROL_PATH" ] \ - && [ "${PILOT_REPLACE_EXISTING_NODE:-}" != "1" ]; then - _pilot_collision="" - for _pilot_link in /usr/local/bin/pilotctl /usr/local/bin/pilot-daemon; do - if [ -L "$_pilot_link" ]; then - _pilot_target=$(readlink "$_pilot_link" 2>/dev/null || true) - case "$_pilot_target" in - "$BIN_DIR"/*) ;; - */.pilot/bin/*) _pilot_collision="${_pilot_collision}${_pilot_collision:+, }$_pilot_link -> $_pilot_target" ;; - esac - fi - done - _pilot_os=$(uname -s | tr '[:upper:]' '[:lower:]') - if [ "$_pilot_os" = "darwin" ] && command -v launchctl >/dev/null 2>&1; then - _pilot_service=$(launchctl print "gui/$(id -u)/network.pilotprotocol.pilot-daemon" 2>/dev/null || true) - if [ -n "$_pilot_service" ] && ! printf '%s\n' "$_pilot_service" | grep -Fq "$BIN_DIR/pilot-daemon"; then - _pilot_collision="${_pilot_collision}${_pilot_collision:+, }LaunchAgent network.pilotprotocol.pilot-daemon" - fi - elif [ "$_pilot_os" = "linux" ] && command -v systemctl >/dev/null 2>&1; then - _pilot_service=$(systemctl cat pilot-daemon 2>/dev/null || true) - if [ -n "$_pilot_service" ] && ! printf '%s\n' "$_pilot_service" | grep -Fq "$BIN_DIR/pilot-daemon"; then - _pilot_collision="${_pilot_collision}${_pilot_collision:+, }systemd pilot-daemon" - fi - fi - if [ -n "$_pilot_collision" ]; then - MANAGED_TOKEN="" - unset MANAGED_TOKEN - echo "Error: another Pilot node installation already owns machine-wide resources." >&2 - echo " Detected: $_pilot_collision" >&2 - echo " This enrollment token was not consumed and nothing was changed." >&2 - echo " Manage or remove the existing node first; do not run two node identities under one service label." >&2 - exit 1 - fi - _pilot_collision=""; _pilot_target=""; _pilot_service=""; _pilot_os="" -fi - # The transport already saved in config.json, if any ("udp", "compat", # "auto"). A re-run without --transport keeps it, so regenerated service # units stay consistent with it. @@ -604,9 +478,9 @@ manifest_platform_field() { # manifest_describes_tag "" "-" "" — whether the # manifest's per-platform entry is the archive of . The manifest carries # hashes for one release only: the platform url names it -# (…/releases/download//…), and a manifest without urls (the managed -# runtime's) describes its latest_stable. Any other tag — a --version pin, the -# beta channel — has no second anchor, so its hash must not be compared. +# (…/releases/download//…), and a manifest without urls describes its +# latest_stable. Any other tag — a --version pin, the beta channel — has no +# second anchor, so its hash must not be compared. manifest_describes_tag() { [ "$1" = "$(manifest_field "latest_stable" "$3")" ] && return 0 case "$(manifest_platform_field "$2" url "$3")" in @@ -889,11 +763,6 @@ HAVE_MANIFEST=0 if fetch_manifest "$MANIFEST_FILE"; then HAVE_MANIFEST=1 fi -if [ "$PILOT_MANAGED_MODE" = "1" ] && [ "$HAVE_MANIFEST" != "1" ]; then - echo "Error: the management authority did not publish a managed-runtime manifest." >&2 - echo " No binary or enrollment state was changed." >&2 - exit 1 -fi if [ -n "$PILOT_REQUESTED_VERSION" ]; then TAG="$PILOT_REQUESTED_VERSION" @@ -928,16 +797,6 @@ else | tr -d '\r' | head -1) fi -if [ "$PILOT_MANAGED_MODE" = "1" ]; then - case "$TAG" in - managed-runtime-v[0-9]*.[0-9]*.[0-9]*) ;; - *) - echo "Error: the management authority published an invalid managed-runtime version." >&2 - exit 1 ;; - esac - validate_safe "managed runtime version" "$TAG" ".-" -fi - # Fail loudly if the user explicitly asked for a released version/channel but it # resolved to nothing. Silently dropping to the unpinned, UNVERIFIED source # build below would give the user a binary they never asked for, with none of @@ -1071,11 +930,6 @@ if [ -n "$TAG" ]; then fi tar -xzf "$TMPDIR/$ARCHIVE" -C "$TMPDIR" --strip-components=1 else - if [ "$PILOT_MANAGED_MODE" = "1" ]; then - echo "Error: managed runtime ${TAG} could not be downloaded." >&2 - echo " Refusing to fall back to an unmanaged build." >&2 - exit 1 - fi # Archive download failed. Only the automatic default path may fall # back to a source build; an explicit request already hard-failed # above, so reaching here means no version/channel was pinned. @@ -1142,17 +996,6 @@ if [ -z "$STAGED_DAEMON" ] || [ -z "$STAGED_CTL" ]; then echo " Nothing was replaced — your existing install is untouched." >&2 exit 1 fi -if [ "$PILOT_MANAGED_MODE" = "1" ]; then - _managed_probe=$(PILOT_ENROLLMENT_TOKEN='' "$STAGED_CTL" --json enterprise adopt --endpoint "$PILOT_MANAGEMENT_URL" 2>&1 || true) - case "$_managed_probe" in - *PILOT_ENROLLMENT_TOKEN*) ;; - *) - echo "Error: ${TAG} does not contain core managed-adoption support." >&2 - echo " Nothing was replaced and the enrollment token was not consumed." >&2 - exit 1 ;; - esac - _managed_probe="" -fi # gateway is optional: extracted to a sibling repo, no longer ships in # release tarballs (release.yml BINS=daemon/pilotctl/updater) and the # source build only runs when ./cmd/gateway is present in the checkout. @@ -1207,10 +1050,7 @@ if [ "$OS" = "linux" ] && [ "$CAN_PRIV" = true ] \ fi ;; esac if [ -n "$_want" ]; then - if { [ "$PILOT_MANAGED_MODE" != "1" ] || [ "$PILOT_MANAGED_NO_START" != "1" ]; } \ - && { [ "$PILOT_MANAGED_MODE" != "1" ] || [ "$_svc" != "pilot-updater" ]; }; then - RESTART_SYSTEMD="${RESTART_SYSTEMD}${RESTART_SYSTEMD:+ }${_svc}" - fi + RESTART_SYSTEMD="${RESTART_SYSTEMD}${RESTART_SYSTEMD:+ }${_svc}" # shellcheck disable=SC2086 # $PILOT_SUDO is "" or "sudo" — intentional split $PILOT_SUDO systemctl stop "$_svc" 2>/dev/null || true echo " Stopped ${_svc} (will restart after upgrade)" @@ -1231,13 +1071,10 @@ if [ "$OS" = "darwin" ]; then echo "Error: could not unload ${_label}; aborting upgrade" >&2 exit 1 fi - if { [ "$PILOT_MANAGED_MODE" != "1" ] || [ "$PILOT_MANAGED_NO_START" != "1" ]; } \ - && { [ "$PILOT_MANAGED_MODE" != "1" ] || [ "$_new_label" != "network.pilotprotocol.pilot-updater" ]; }; then - case " $RESTART_LAUNCHD " in - *" ${_new_label} "*) ;; - *) RESTART_LAUNCHD="${RESTART_LAUNCHD}${RESTART_LAUNCHD:+ }${_new_label}" ;; - esac - fi + case " $RESTART_LAUNCHD " in + *" ${_new_label} "*) ;; + *) RESTART_LAUNCHD="${RESTART_LAUNCHD}${RESTART_LAUNCHD:+ }${_new_label}" ;; + esac echo " Unloaded ${_label} (will reload as ${_new_label} after upgrade)" fi if [ "$_new_label" != "$_label" ] && [ -f "$_lp" ]; then @@ -1271,32 +1108,6 @@ install_bin "$STAGED_CTL" "$BIN_DIR/pilotctl" [ -n "$STAGED_GATEWAY" ] && install_bin "$STAGED_GATEWAY" "$BIN_DIR/pilot-gateway" [ -n "$STAGED_UPDATER" ] && install_bin "$STAGED_UPDATER" "$BIN_DIR/pilot-updater" -# --- Optional hosted adoption (core Pilot, not MCP) --- -# -# The one-time token is exposed only to this process. pilotctl validates the -# delegated key, root pin, trust bundle, bootstrap policy, authority origins, -# and owner-only output before atomically installing ~/.pilot/managed. -MANAGED_ADOPTED=0 -if [ "$PILOT_MANAGED_MODE" = "1" ] && [ ! -e "$MANAGED_CONTROL_PATH" ]; then - if ! _managed_result=$(PILOT_ENROLLMENT_TOKEN="$MANAGED_TOKEN" "$BIN_DIR/pilotctl" --json enterprise adopt --endpoint "$PILOT_MANAGEMENT_URL" 2>&1); then - MANAGED_TOKEN="" - unset MANAGED_TOKEN - echo "Error: the hosted authority did not complete managed adoption." >&2 - printf '%s\n' "$_managed_result" >&2 - exit 1 - fi - MANAGED_TOKEN="" - unset MANAGED_TOKEN - _managed_result="" - if [ -L "$MANAGED_CONTROL_PATH" ] || [ ! -f "$MANAGED_CONTROL_PATH" ]; then - echo "Error: managed adoption returned without installing the verified control attachment." >&2 - exit 1 - fi - MANAGED_ADOPTED=1 -fi -MANAGED_TOKEN="" -unset MANAGED_TOKEN - # --- Symlink into /usr/local/bin so NON-INTERACTIVE shells can find pilotctl --- # # This symlink is the only thing that makes `pilotctl` resolve from a @@ -1337,7 +1148,7 @@ if [ "$LINK_OK" = true ]; then # shellcheck disable=SC2086 $LINK_SUDO ln -sf "$BIN_DIR/pilot-gateway" "$LINK_DIR/pilot-gateway" 2>/dev/null || true fi - if [ "$PILOT_MANAGED_MODE" != "1" ] && [ -f "$BIN_DIR/pilot-updater" ]; then + if [ -f "$BIN_DIR/pilot-updater" ]; then # shellcheck disable=SC2086 $LINK_SUDO ln -sf "$BIN_DIR/pilot-updater" "$LINK_DIR/pilot-updater" 2>/dev/null || true fi @@ -1733,13 +1544,7 @@ service_proxy_note() { # only when the file is absent so an operator who later runs `pilotctl update # disable` is never silently re-enabled. Turn off any time with # `pilotctl update disable`. -if [ "$PILOT_MANAGED_MODE" = "1" ]; then - # Stable-channel updater builds do not yet carry the managed control - # client. Pin this authority-selected runtime instead of allowing - # a background downgrade to silently remove enforcement. - printf '{\n "enabled": false,\n "reason": "managed-runtime-pinned-by-authority"\n}\n' > "$PILOT_DIR/auto-update.json" - echo "Auto-updates pinned to the management authority runtime channel" -elif [ ! -f "$PILOT_DIR/auto-update.json" ]; then +if [ ! -f "$PILOT_DIR/auto-update.json" ]; then printf '{\n "enabled": true\n}\n' > "$PILOT_DIR/auto-update.json" echo "Auto-updates ENABLED (opt-out) — disable with: pilotctl update disable" fi @@ -1750,8 +1555,6 @@ fi # what makes re-running the installer a real repair path: a host whose unit was # written by an older, buggy installer gets a correct one without uninstalling. -MANAGED_START_STYLE="" - if [ "$OS" = "linux" ] && command -v systemctl >/dev/null 2>&1 && [ -d /run/systemd/system ]; then if [ "$CAN_PRIV" = true ]; then echo "Setting up systemd service..." @@ -1814,7 +1617,7 @@ RestartSec=5 WantedBy=multi-user.target SVC # Auto-updater service - if [ "$PILOT_MANAGED_MODE" != "1" ] && [ -f "$BIN_DIR/pilot-updater" ]; then + if [ -f "$BIN_DIR/pilot-updater" ]; then # shellcheck disable=SC2086 $PILOT_SUDO tee /etc/systemd/system/pilot-updater.service >/dev/null </dev/null || true - fi echo " Service: pilot-daemon.service" - if [ "$PILOT_MANAGED_MODE" != "1" ] && [ -f "$BIN_DIR/pilot-updater" ]; then + if [ -f "$BIN_DIR/pilot-updater" ]; then echo " Service: pilot-updater.service (auto-updates)" fi service_proxy_note "pilot-daemon.service" @@ -1863,7 +1660,7 @@ USVC # operator-tunable flags (-public, -hostname, registry overrides) that the # operator may want to set before first start; on a re-run anything that # was already running is restored below. - if [ "$PILOT_MANAGED_MODE" != "1" ] && [ -f "$BIN_DIR/pilot-updater" ]; then + if [ -f "$BIN_DIR/pilot-updater" ]; then # shellcheck disable=SC2086 if $PILOT_SUDO systemctl enable --now pilot-updater; then echo " Started: pilot-updater (check automatic-update state: pilotctl update status)" @@ -1884,51 +1681,38 @@ USVC fi done - if [ "$PILOT_MANAGED_MODE" = "1" ] && [ "$PILOT_MANAGED_NO_START" != "1" ]; then - # Managed onboarding promises a live signed check-in, so unlike an - # ordinary local install it explicitly enables the daemon now. - # shellcheck disable=SC2086 - $PILOT_SUDO systemctl enable --now pilot-daemon - MANAGED_START_STYLE="systemd" - echo " Started: pilot-daemon (managed reporting enabled)" - elif [ "$PILOT_MANAGED_MODE" != "1" ]; then - case " $RESTART_SYSTEMD " in - *" pilot-daemon "*) ;; - *) - if [ "$PROXY_UNSUPPORTED" = true ]; then - echo " Start daemon:" - start_hint " " "sudo systemctl enable --now pilot-daemon" - else - echo " Start daemon: sudo systemctl enable --now pilot-daemon" - fi ;; - esac - fi + case " $RESTART_SYSTEMD " in + *" pilot-daemon "*) ;; + *) + if [ "$PROXY_UNSUPPORTED" = true ]; then + echo " Start daemon:" + start_hint " " "sudo systemctl enable --now pilot-daemon" + else + echo " Start daemon: sudo systemctl enable --now pilot-daemon" + fi ;; + esac else echo " Skipped systemd setup (run as root or with passwordless sudo to enable)" - if [ "$PILOT_MANAGED_MODE" != "1" ]; then - if [ "$PROXY_UNSUPPORTED" = true ]; then - echo " Start the daemon without a service manager:" - start_hint " " "pilotctl daemon start" - else - echo " Start the daemon without a service manager: pilotctl daemon start" - fi + if [ "$PROXY_UNSUPPORTED" = true ]; then + echo " Start the daemon without a service manager:" + start_hint " " "pilotctl daemon start" + else + echo " Start the daemon without a service manager: pilotctl daemon start" fi fi elif [ "$OS" = "linux" ]; then # systemd is not the init system here (container / WSL / CI runner / # hosted agent sandbox). There is no service to install — tell the agent # the portable start path instead of silently leaving it with no daemon. - if [ "$PILOT_MANAGED_MODE" != "1" ]; then - if [ "$PROXY_ONLY" = true ]; then - echo "No systemd detected (container / WSL / CI / sandbox):" - else - echo "No systemd detected (container / WSL / CI / sandbox) — start the daemon manually:" - fi - start_hint " " "pilotctl daemon start" - if [ "$PROXY_UNSUPPORTED" != true ] && [ "$EFFECTIVE_TRANSPORT" != "udp" ]; then - echo " (transport=${EFFECTIVE_TRANSPORT}; start it from a shell that has HTTPS_PROXY" - echo " set if this host reaches the internet only through a proxy)" - fi + if [ "$PROXY_ONLY" = true ]; then + echo "No systemd detected (container / WSL / CI / sandbox):" + else + echo "No systemd detected (container / WSL / CI / sandbox) — start the daemon manually:" + fi + start_hint " " "pilotctl daemon start" + if [ "$PROXY_UNSUPPORTED" != true ] && [ "$EFFECTIVE_TRANSPORT" != "udp" ]; then + echo " (transport=${EFFECTIVE_TRANSPORT}; start it from a shell that has HTTPS_PROXY" + echo " set if this host reaches the internet only through a proxy)" fi fi @@ -2015,7 +1799,7 @@ ${PLIST_ENV} RunAtLoad PLIST # Auto-updater LaunchAgent - if [ "$PILOT_MANAGED_MODE" != "1" ] && [ -f "$BIN_DIR/pilot-updater" ]; then + if [ -f "$BIN_DIR/pilot-updater" ]; then UPLIST="$PLIST_DIR/network.pilotprotocol.pilot-updater.plist" cat > "$UPLIST" < @@ -2044,13 +1828,7 @@ UPLIST fi echo " Service: network.pilotprotocol.pilot-daemon" - if [ "$PILOT_MANAGED_MODE" = "1" ]; then - _managed_updater_plist="$PLIST_DIR/network.pilotprotocol.pilot-updater.plist" - if [ -f "$_managed_updater_plist" ]; then - launchctl unload -w "$_managed_updater_plist" 2>/dev/null || true - fi - fi - if [ "$PILOT_MANAGED_MODE" != "1" ] && [ -f "$BIN_DIR/pilot-updater" ]; then + if [ -f "$BIN_DIR/pilot-updater" ]; then echo " Service: network.pilotprotocol.pilot-updater (auto-updates)" fi service_proxy_note "the launchd agent" @@ -2065,7 +1843,7 @@ UPLIST # idempotent: any stale running agent is replaced cleanly. -w persists # the load across reboots. The daemon is left as opt-in for the same # reason as the Linux branch. - if [ "$PILOT_MANAGED_MODE" != "1" ] && [ -f "$BIN_DIR/pilot-updater" ] && [ -f "$UPLIST" ]; then + if [ -f "$BIN_DIR/pilot-updater" ] && [ -f "$UPLIST" ]; then launchctl unload "$UPLIST" 2>/dev/null || true launchctl load -w "$UPLIST" echo " Started: pilot-updater (check automatic-update state: pilotctl update status)" @@ -2087,47 +1865,18 @@ UPLIST fi done - if [ "$PILOT_MANAGED_MODE" != "1" ]; then - case " $RESTART_LAUNCHD " in - *" network.pilotprotocol.pilot-daemon "*) ;; - *) - if [ "$PROXY_UNSUPPORTED" = true ]; then - echo " Start daemon:" - start_hint " " "launchctl load -w $PLIST" "launchctl load -w $PLIST" - else - echo " Start daemon: launchctl load -w $PLIST" - fi - echo " Stop daemon: launchctl unload $PLIST" - ;; - esac - fi -fi - -# A managed Connect Agent run is complete only when the newly adopted core -# daemon is locally responsive. The management console independently waits for -# the signed remote report, so this check cannot forge onboarding success. -if [ "$PILOT_MANAGED_MODE" = "1" ]; then - if [ "$PILOT_MANAGED_NO_START" = "1" ]; then - echo "Managed runtime adopted but not started (--no-start)." - elif [ "$MANAGED_START_STYLE" = "systemd" ]; then - _managed_wait=0 - until "$BIN_DIR/pilotctl" daemon status --check >/dev/null 2>&1; do - _managed_wait=$((_managed_wait + 1)) - if [ "$_managed_wait" -ge 30 ]; then - echo "Error: the managed daemon did not become ready under systemd." >&2 - exit 1 + case " $RESTART_LAUNCHD " in + *" network.pilotprotocol.pilot-daemon "*) ;; + *) + if [ "$PROXY_UNSUPPORTED" = true ]; then + echo " Start daemon:" + start_hint " " "launchctl load -w $PLIST" "launchctl load -w $PLIST" + else + echo " Start daemon: launchctl load -w $PLIST" fi - sleep 1 - done - else - # Portable and launchd installs need an explicit restart so a daemon - # that was already running cannot keep the pre-adoption configuration. - if "$BIN_DIR/pilotctl" daemon status --check >/dev/null 2>&1; then - "$BIN_DIR/pilotctl" daemon stop >/dev/null - fi - "$BIN_DIR/pilotctl" daemon start --wait 30s >/dev/null - "$BIN_DIR/pilotctl" daemon status --check >/dev/null - fi + echo " Stop daemon: launchctl unload $PLIST" + ;; + esac fi # --- Add to PATH --- @@ -2199,30 +1948,6 @@ fi # Write version file for the auto-updater [ -n "$TAG" ] && echo "$TAG" > "$BIN_DIR/.pilot-version" -if [ "$PILOT_MANAGED_MODE" = "1" ]; then - echo "" - echo "Managed Pilot node ready:" - echo " Runtime: ${TAG}" - echo " Authority: ${PILOT_MANAGEMENT_URL}" - echo " Control: ${MANAGED_CONTROL_PATH}" - if [ "$MANAGED_ADOPTED" = "1" ]; then - echo " Enrollment: claimed once and installed" - else - echo " Enrollment: existing managed identity preserved" - fi - if [ "$PILOT_MANAGED_NO_START" = "1" ]; then - echo " Daemon: not started (--no-start)" - else - echo " Daemon: running; signed fleet reporting enabled" - fi - echo " MCP: not installed (optional, separate product)" - echo "" - echo "Harness interception is a separate optional attachment step." - echo "The management console will verify the node's signed report before" - echo "it marks onboarding complete." - exit 0 -fi - # transport_line — the transport the installed daemon will run, stated once # the binaries are known (the banner at the top does not guess), plus what to # do on a UDP-blocked host when this release will not fall back by itself. diff --git a/public/llms.txt b/public/llms.txt index 70c649ee..b9185081 100644 --- a/public/llms.txt +++ b/public/llms.txt @@ -25,12 +25,10 @@ A no-styling, no-JS variant of the marketing site is maintained at /plain/ for A - [MCP + Pilot](https://pilotprotocol.network/plain/mcp/): expose MCP servers over the network - [Plans](https://pilotprotocol.network/plain/plans/): Backbone is free, private and enterprise are managed -## Enterprise control plane +## Enterprise -The managed control plane is in preview. Supported adapters can surface agent actions for signed policy decisions, expiring approvals, bounded remote operations, usage attribution, and evidence. Nodes enforce signed decisions locally; organizational business authority remains explicit. +Enterprise controls for private networks are in early access: roles, external identity validation, network policy, key lifecycle, blueprints, and audit export. Organizational business authority remains explicit. -- [Autonomous AI agent control plane](https://pilotprotocol.network/enterprise/autonomous-ai-agents): Fleet inventory, signed policy rollout, live approval, typed commands, and action evidence. -- [Claude Code management](https://pilotprotocol.network/enterprise/claude-code-management): Work-issued runtime inventory, model-call and token attribution, supported settings rollout, and audited remote operations. - [Enterprise architecture](https://pilotprotocol.network/docs/enterprise): Deployment model, identity, policy, roles, and audit controls. - [Enterprise readiness report](https://pilotprotocol.network/enterprise-readiness-report.pdf): Architecture, control boundaries, and deployment considerations. diff --git a/scripts/gen-apps.mjs b/scripts/gen-apps.mjs index eed42f88..4fe5a85f 100644 --- a/scripts/gen-apps.mjs +++ b/scripts/gen-apps.mjs @@ -1,10 +1,8 @@ // Generator for src/data/apps.ts. // -// The records come from the app-store metadata API — the one source the Alpha -// management console reads too. Before it existed this script built them from -// local JSON (app-overrides.json + app-methods.json + app-demos.json) while the -// console carried its own copy pasted across by hand, and the two drifted: -// 25 of 27 apps had different summary copy on the two surfaces. +// The records come from the app-store metadata API. Before it existed this +// script built them from local JSON (app-overrides.json + app-methods.json + +// app-demos.json), and copies of that data drifted between surfaces. // // Editing an app now means editing one file in pilot-protocol/app-template // under appstore-meta/data/apps/ and redeploying the API. Nothing about an @@ -198,7 +196,7 @@ const apps = document.apps.map(toApp); const FEATURED = (document.featured_order || []).filter((id) => apps.some((app) => app.id === id)); const source = fetched ? API : `${path.basename(SNAPSHOT)} (offline)`; -const banner = `// AUTO-GENERATED by scripts/gen-apps.mjs from the app-store metadata API\n// (${source}) — the same document the Alpha management console reads.\n// Do not edit by hand, and do not edit the records here: change an app in\n// pilot-protocol/app-template under appstore-meta/data/apps/ and redeploy.\n// No ratings or install counts — those are not published by the catalogue.\n`; +const banner = `// AUTO-GENERATED by scripts/gen-apps.mjs from the app-store metadata API\n// (${source}).\n// Do not edit by hand, and do not edit the records here: change an app in\n// pilot-protocol/app-template under appstore-meta/data/apps/ and redeploy.\n// No ratings or install counts — those are not published by the catalogue.\n`; const body = `${banner} export interface AppMethod { name: string; summary: string | null; example: string | null; gated: string | null; } export interface AppLimit { label: string; value: string; } diff --git a/scripts/regen-plain.mjs b/scripts/regen-plain.mjs index e32a8e7f..18c256ab 100644 --- a/scripts/regen-plain.mjs +++ b/scripts/regen-plain.mjs @@ -132,11 +132,6 @@ async function loadDocManifest() { const source = `src/pages/docs/${file}`; const dest = `src/pages/plain/docs/${file}`; const full = await readFile(join(REPO_ROOT, source), 'utf8'); - // Managed documentation renders from src/data/managedDocs.ts on both the - // human and plain routes. Feeding the thin route wrapper to the prose - // generator loses the authoritative content and produces placeholders. - // Its plain wrapper is intentionally unstamped and data-driven. - if (full.includes("from '../../data/managedDocs'")) continue; const meta = readDocMeta(full); const isIndex = slugPart === 'index'; const canonical = isIndex diff --git a/src/components/Footer.astro b/src/components/Footer.astro index b9056e2e..0b9ff6d6 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -4,8 +4,8 @@ import { solutionGroups } from '../data/solutions'; const enterpriseLinks = [ - { href: '/enterprise/autonomous-ai-agents', label: 'Autonomous agent control' }, - { href: '/enterprise/claude-code-management', label: 'Claude Code management' }, + { href: '/docs/enterprise', label: 'Enterprise networks' }, + { href: '/plans', label: 'Plans' }, ]; // Social links — add new entries here to extend the row. diff --git a/src/components/ManagedPlainDoc.astro b/src/components/ManagedPlainDoc.astro deleted file mode 100644 index 22641bda..00000000 --- a/src/components/ManagedPlainDoc.astro +++ /dev/null @@ -1,20 +0,0 @@ ---- -import PlainLayout from '../layouts/PlainLayout.astro'; -import { managedDocs } from '../data/managedDocs'; - -interface Props { - slug: string; -} - -const { slug } = Astro.props; -const doc = managedDocs[slug]; -if (!doc) throw new Error(`Unknown managed documentation slug: ${slug}`); ---- - -

← Docs index

- - diff --git a/src/data/apps.ts b/src/data/apps.ts index e2d84840..fe124ff7 100644 --- a/src/data/apps.ts +++ b/src/data/apps.ts @@ -1,5 +1,5 @@ // AUTO-GENERATED by scripts/gen-apps.mjs from the app-store metadata API -// (https://appstore-meta.pilotprotocol.network/v1/appstore/metadata) — the same document the Alpha management console reads. +// (https://appstore-meta.pilotprotocol.network/v1/appstore/metadata). // Do not edit by hand, and do not edit the records here: change an app in // pilot-protocol/app-template under appstore-meta/data/apps/ and redeploy. // No ratings or install counts — those are not published by the catalogue. diff --git a/src/data/blogPosts.json b/src/data/blogPosts.json index 4e500c61..44e78f25 100644 --- a/src/data/blogPosts.json +++ b/src/data/blogPosts.json @@ -51,7 +51,7 @@ { "slug": "connect-claude-code-to-pilot-protocol", "title": "Connect Claude Code to Pilot Protocol with MCP Tools", - "description": "Add Pilot agent discovery, messaging, and policy hooks to Claude Code without replacing existing MCP servers or settings.", + "description": "Add Pilot agent discovery and messaging to Claude Code without replacing existing MCP servers or settings.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -64,8 +64,8 @@ }, { "slug": "connect-cursor-to-pilot-protocol", - "title": "Connect Cursor to Pilot Protocol with MCP and Hooks", - "description": "Configure Pilot MCP and fail-closed native tool hooks in Cursor while preserving the rest of your user configuration.", + "title": "Connect Cursor to Pilot Protocol with MCP", + "description": "Configure Pilot MCP in Cursor while preserving the rest of your user configuration.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -78,8 +78,8 @@ }, { "slug": "connect-cline-to-pilot-protocol", - "title": "Connect Cline to Pilot Protocol with MCP and Hooks Safely", - "description": "Connect Cline to Pilot MCP, install its native tool hooks, and preserve existing servers and user-owned hook scripts.", + "title": "Connect Cline to Pilot Protocol with MCP", + "description": "Connect Cline to Pilot MCP while preserving existing servers and user-owned hook scripts.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -92,8 +92,8 @@ }, { "slug": "connect-hermes-to-pilot-protocol", - "title": "Connect Hermes to Pilot Protocol with MCP and Hooks", - "description": "Add Pilot MCP and native pre- and post-tool hooks to Hermes CLI and Gateway sessions with one configuration command.", + "title": "Connect Hermes to Pilot Protocol with MCP", + "description": "Add Pilot MCP to Hermes CLI and Gateway sessions with one configuration command.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -106,8 +106,8 @@ }, { "slug": "connect-picoclaw-to-pilot-protocol", - "title": "Connect PicoClaw to Pilot Protocol with MCP Hooks Safely", - "description": "Enable Pilot MCP and PicoClaw’s process-hook boundary for lightweight agents running on constrained devices.", + "title": "Connect PicoClaw to Pilot Protocol with MCP", + "description": "Enable Pilot MCP in PicoClaw for lightweight agents running on constrained devices.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -120,8 +120,8 @@ }, { "slug": "connect-openhands-to-pilot-protocol", - "title": "Connect OpenHands to Pilot Protocol with MCP Hooks", - "description": "Configure Pilot for OpenHands at user scope and add project-scoped tool hooks without changing unrelated settings.", + "title": "Connect OpenHands to Pilot Protocol with MCP", + "description": "Configure Pilot for OpenHands at user scope without changing unrelated settings.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -134,8 +134,8 @@ }, { "slug": "connect-codex-cli-to-pilot-protocol", - "title": "Connect Codex CLI to Pilot Protocol with MCP Hooks", - "description": "Add Pilot MCP and local tool hooks to Codex CLI while preserving existing TOML configuration and hook groups.", + "title": "Connect Codex CLI to Pilot Protocol with MCP", + "description": "Add Pilot MCP to Codex CLI while preserving existing TOML configuration and hook groups.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -148,8 +148,8 @@ }, { "slug": "connect-gemini-cli-to-pilot-protocol", - "title": "Connect Gemini CLI to Pilot Protocol with MCP Hooks", - "description": "Connect Gemini CLI to Pilot MCP and install sequential BeforeTool and AfterTool hooks in its user settings.", + "title": "Connect Gemini CLI to Pilot Protocol with MCP", + "description": "Connect Gemini CLI to Pilot MCP through its user settings.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -177,7 +177,7 @@ { "slug": "connect-github-copilot-to-pilot-protocol", "title": "Connect GitHub Copilot to Pilot Protocol with MCP Tools", - "description": "Configure Pilot MCP and cross-platform tool hooks for GitHub Copilot CLI without rewriting unrelated user settings.", + "description": "Configure Pilot MCP for GitHub Copilot CLI without rewriting unrelated user settings.", "date": "Sep 5", "category": "Integration", "tags": [ @@ -1069,8 +1069,8 @@ }, { "slug": "openclaw-meets-pilot-agent-networking-one-command", - "title": "Connect OpenClaw to Pilot Protocol with Native Policy", - "description": "Install Pilot’s native OpenClaw plugin for agent networking, message checks, policy decisions, and post-action evidence.", + "title": "Connect OpenClaw to Pilot Protocol with a Native Plugin", + "description": "Install Pilot’s native OpenClaw plugin for agent networking with one command.", "date": "Mar 1", "category": "Integration", "tags": [ diff --git a/src/data/docsNav.ts b/src/data/docsNav.ts index 3762eac7..5b14c0ff 100644 --- a/src/data/docsNav.ts +++ b/src/data/docsNav.ts @@ -53,21 +53,6 @@ export const docsNav: NavItem[] = [ icon: '' }, { label: 'Consent & Privacy', href: '/docs/consent', slug: 'consent', icon: '' }, - // Hosted control plane - { section: 'Hosted Control Plane', label: 'Managed Overview', href: '/docs/managed-control-plane', slug: 'managed-control-plane', - icon: '' }, - { label: 'Accounts & Organizations', href: '/docs/managed-accounts', slug: 'managed-accounts', - icon: '' }, - { label: 'Agent Adoption', href: '/docs/managed-agent-adoption', slug: 'managed-agent-adoption', - icon: '' }, - { label: 'Harness Coverage', href: '/docs/managed-harnesses', slug: 'managed-harnesses', - icon: '' }, - { label: 'Policies & Approvals', href: '/docs/managed-policies', slug: 'managed-policies', - icon: '' }, - { label: 'Fleet & Evidence', href: '/docs/managed-fleet', slug: 'managed-fleet', - icon: '' }, - { label: 'Availability & Readiness', href: '/docs/managed-readiness', slug: 'managed-readiness', - icon: '' }, // Enterprise { section: 'Enterprise', label: 'Security', href: '/docs/security', slug: 'security', icon: '' }, diff --git a/src/data/managedDocs.ts b/src/data/managedDocs.ts deleted file mode 100644 index 6e90edeb..00000000 --- a/src/data/managedDocs.ts +++ /dev/null @@ -1,547 +0,0 @@ -export interface ManagedDoc { - title: string; - description: string; - body: string; -} - -export const managedDocs: Record = { - 'managed-control-plane': { - title: 'Hosted Agent Control Plane', - description: 'Architecture, operating modes, security boundaries, and data flow for the optional Pilot hosted agent management and policy platform.', - body: `

Hosted agent control plane

-

An optional Pilot-hosted federation, policy, approval, monitoring, and command plane for one agent or a managed fleet.

- -
Current availability. A live pre-release deployment exists at management.pilotprotocol.network. It is invitation-only and currently serves the preconfigured Pilot demonstration organization. Public organization signup is not available. See Availability & readiness for the exact launch boundary.
- -

On this page

- -

Product contract

-

The hosted control plane lets an organization describe what its agents may do, evaluate proposed actions before execution, request human or service approval, inspect actions and exchanged content, operate nodes remotely, and retain signed evidence. It is adjacent to the open Pilot node and protocol: installing Pilot does not automatically place an agent under hosted control.

-

Four boundaries are fundamental:

-
    -
  1. An unmanaged node continues to behave as it did before the hosted platform existed.
    2. -
  2. The management service cannot expand a node's locally pinned trust, mandate, or signed policy ceiling.
    3. -
  3. Semantic analysis can preserve or narrow an executable decision; it cannot turn a deterministic deny into an allow.
    4. -
  4. A configured pre-hook blocks or suspends the side effect before execution. A post-hook records the observed result; it does not retroactively authorize the action.
    5. -
- -

Optional operating modes

- - - - - -
ModeBehaviorHosted dependency
off / no hookThe original agent and node behavior is unchanged.None
observeSelected actions are recorded without blocking them.Optional
local_enforceSigned deterministic rules may deny or constrain locally.No per-action hosted decision
managed_enforceSelected actions wait for the hosted deterministic, semantic, and approval path.Required for governed actions
-

Action interception and .pilot state synchronization are separate toggles. Signed fleet reporting is required for a managed adoption because it is how the service verifies the allocated node and returns typed control operations. A newly released action is not silently governed: enforcement profiles use an explicit action inventory or a visible wildcard.

- -

Decision and evidence flow

-
    -
  1. The agent harness proposes an action with its action name, target resource, risk, request body, session identity, and available context.
    2. -
  2. The native pre-hook or custom SDK wrapper signs the intent with the adopted node identity and sends it to that organization's federation endpoint.
    3. -
  3. The active deterministic policy establishes the maximum authority. The first matching rule wins; the mandatory fallback is deny.
    4. -
  4. If an active reviewed semantic clause applies, Pilot's hosted evaluator receives the exact eligible content and may only preserve or narrow the base result.
    5. -
  5. If consent is required, the action remains suspended in an expiring transaction bound to the exact intent and payload hash. A successful quorum creates a single-use continuation.
    6. -
  6. The node verifies the signed result. It releases, constrains, suspends, or blocks the side effect locally.
    7. -
  7. The post-hook reports the actual result. Pilot correlates intent, policy, semantic evaluation, approval, continuation, result, receipt, fleet activity, and procedure runs.
    8. -
- -

What runs where

- - - - - - -
ComponentLocationResponsibility
Pilot node runtimeAgent hostNode identity, trust pins, signed policy, enforcement, receipts, fleet reporting, and state reconciliation.
Harness adapterAgent hostOptional native pre/post hooks or MCP bridge around the action boundary exposed by the harness.
Management servicePilot-hostedAccounts, organizations, policies, approvals, fleet desired state, procedures, audit, evidence, monitoring, and integrations.
Federation servicePilot-hosted, tenant routedReceives signed action intents and exact eligible exchange content; returns a signed narrowed decision.
Semantic evaluatorPilot-hostedEvaluates only active reviewed clauses, records model/version/usage evidence, and never grants above deterministic policy.
- -

Content and data handling

-

In managed enforcement, Pilot may receive the complete tool arguments, message body, explicit file-share bytes, HTTP body, transaction details, and reported result when the selected adapter exposes them. The exchange record binds exact content to the called resource, hashes, policy revision, decision, and retention metadata. Authorized operators can inspect a bounded preview and audit access to complete retained content.

-

No hidden local semantic inspector is installed. If content must be interpreted semantically, the eligible exchange is routed through the Pilot-hosted federation boundary. With no active semantic clause, deterministic evaluation completes without a model call. Actions configured as local-only remain metadata-governed unless an adapter deliberately federates inspectable content.

-

Private keys, enrollment seeds, account passwords, and root signing material are not rendered in the management interface. The .pilot state view fingerprints protected artifacts and permits mutation only for the explicitly safe, revision-checked subset.

- -

Feature map

- - -
Shared responsibility. A harness hook observes the operation proposed through that harness. It is not an operating-system reference monitor. Keep the harness sandbox, workload identity, egress policy, endpoint controls, secret management, and ordinary host hardening.
`, - }, - - 'managed-accounts': { - title: 'Managed Accounts and Organizations', - description: 'Current signup availability, account lifecycle, roles, organization isolation, launch entitlements, and multi-organization behavior in Pilot hosted management.', - body: `

Accounts and organizations

-

How people, service accounts, organizations, tenants, sessions, and adopted agents are separated.

- -
Can a new user create an account today? No, not through a public self-service flow. As verified on 8 August 2026, /v1/auth/signup returns 404 {"error":"signup_unavailable"}. The live login page is available, but accounts must already exist or be created through an invitation or operator-assisted provisioning path.
- -

On this page

- -

Access today

-

The deployed management service serves a preconfigured demonstration organization and supports an ordinary login flow. It is not an open registration service. A person needs a valid existing account or an unexpired, single-use invitation issued by an organization administrator. This is intentional: the development-only open signup route is forbidden in production configuration.

-

After account creation, the first-party identity path supports local password login, password reset, logout, session inventory and revocation, TOTP multifactor authentication, recovery codes, member suspension, and optional OIDC federation. OIDC is an integration, not a prerequisite.

- -

Intended public signup flow

-

The public SaaS code implements the following workflow, but that provisioner is not deployed on the live service:

-
    -
  1. Enter a work email, organization name, workspace slug, and region.
    2. -
  2. Verify the email through a short-lived signed claim.
    3. -
  3. Reserve a unique organization ID, tenant ID, and account subdomain.
    4. -
  4. Provision tenant signing keys, policy, storage bindings, quotas, and either pooled or dedicated placement.
    5. -
  5. Create a single-use owner invitation on the tenant-scoped identity service.
    6. -
  6. Create the owner password directly on the account host, then continue to agent adoption.
    7. -
-

No password should pass through the global signup service. It verifies and provisions the workspace, then hands the browser to the isolated account origin.

- -

Organization and tenant isolation

-

Each authority binds one organization to one cryptographic tenant. Browser sessions obtain tenant scope from the authenticated account context; a tenant_id query parameter cannot switch the user into another organization. Object stores and repository keys repeat tenant ownership checks, while signed node artifacts carry the same tenant identity.

-

Enrollment tokens, node credentials, trust bundles, policies, decisions, receipts, fleet reports, exchanges, audit records, and usage units are tenant-bound. A token issued by Organization A cannot produce an Organization B identity. Separate authority cells are the recommended hard boundary for unrelated customers; pooled placement additionally requires database- and credential-level isolation before general release.

- -

Multiple organizations

-

The product model supports many organizations, each with its own slug, tenant, authority, members, policies, nodes, and evidence. The current live deployment does not yet expose that public multi-organization provisioning layer.

-
    -
  • One adopted agent identity belongs to exactly one tenant.
    • -
  • The default managed attachment path supports one adopted identity per operating-system user home.
    • -
  • Separate users, containers, or isolated homes can hold separate identities on the same physical host.
    • -
  • The installer refuses to consume a second enrollment token while a managed attachment already exists.
    • -
  • Moving an agent between organizations requires retiring or revoking the old identity and performing a fresh adoption. A polished self-service transfer workflow is not available today.
    • -
  • A human who belongs to multiple organizations will require an explicit organization choice or separate host-bound sessions; URL parameter substitution is never a switch mechanism.
    • -
- -

Identity and roles

-

Permissions separate account administration, policy writing, independent policy approval, consent voting, trust and mandate administration, fleet commands, integration management, evidence access, and audit administration. Browser mutations require a session-bound CSRF token and same-origin validation.

- - - - - -
IdentityUseLifecycle
Organization owner/adminMembers, roles, security configuration, and delegated administration.Protected against removing the final administrator.
MemberRole-scoped console and API access.Invite, activate, suspend, reactivate, remove.
Service accountNon-browser automation with explicit permissions.Create, rotate API keys, disable, revoke.
Node identitySigns agent intents, reports, acknowledgements, results, and receipts.Adopt, rotate, quarantine, retire, revoke, re-adopt.
- -

Launch entitlements and metering

-

Plans are disabled for the initial public launch. Every organization receives the same launch entitlement; users do not select a tier, enter payment details, see upgrade prompts, or pass through Stripe. Billing and plan-management routes must remain hidden or return a clear disabled state.

-

Planless does not mean unbounded. Every tenant still needs hard node, request, semantic-token, storage, retention, and event limits plus rate limiting and abuse controls. Semantic/model usage is attributed by tenant, agent, evaluator, model call, and token counts through an idempotent usage ledger for cost visibility and future product decisions, but it is not invoiced.

-

The data model may retain internal entitlement fields so plans can be introduced later without a tenant migration. Those fields are operational defaults, not a customer-visible commercial contract while plan mode is disabled. A metering or quota failure must never expand action authority.

- -

Lifecycle boundaries

-

Invitations, sessions, API keys, members, and nodes have explicit terminal states rather than destructive deletion where evidence must remain verifiable. Organization rename, export, deletion, suspension, owner transfer, legal holds, final-admin protection, node revocation, subdomain cleanup, and usage-ledger closure must behave atomically before public SaaS launch. Those complete organization-lifecycle tests remain a release gate.

- -
Practical answer. Existing invited users can log in and use the deployed demonstration organization. A new unrelated company cannot yet self-register, receive its own subdomain, and adopt an agent without operator assistance.
`, - }, - - 'managed-agent-adoption': { - title: 'Managed Agent Adoption', - description: 'Step-by-step managed node adoption, one-time enrollment security, optional control toggles, signed verification, and organization reassignment.', - body: `

Managed agent adoption

-

Adopt the core Pilot node first; attach a harness action boundary only when in-flight control is wanted.

- -

On this page

- -

Prerequisites

-
    -
  • An existing account in the target organization.
    • -
  • The administrator or fleet.command role.
    • -
  • A supported host for pilotctl and pilot-daemon.
    • -
  • Outbound HTTPS access to the organization's management and federation origins.
    • -
  • Access to the operating-system user that will own the agent runtime. Do not run the installer as root.
    • -
- -

Adoption workflow

-
    -
  1. Open Connect an agent in the management console.
    2. -
  2. Select the real harness that runs the agent. The selection records the expected capability boundary; it does not pretend every harness has universal interception.
    3. -
  3. Enter a node display name and choose action interception and .pilot state synchronization. Fleet reporting is required.
    4. -
  4. Select Create one-time command. Pilot allocates the agent ID server-side and returns a high-entropy claim that expires after 15 minutes and is consumed once.
    5. -
  5. Run the displayed command on the agent host:
    6. -
- 
curl -fsSL https://pilotprotocol.network/install.sh | \
-  PILOT_ENROLLMENT_TOKEN='<one-time token>' sh -s -- \
-  --managed-url https://management.pilotprotocol.network
-
    -
  1. If action interception is enabled, run the separate, version-pinned harness attachment command shown by the console, for example npx -y pilotprotocol-mcp@0.2.13 attach --gemini.
    2. -
  2. Return to the waiting page. Pilot accepts completion only after the allocated identity sends a fresh signed report carrying the exact harness and onboarding-run marker.
    3. -
  3. Create and activate a language policy, then attempt a real violating action. The guided flow completes only after it observes a semantic denial for that exact agent before the side effect.
    4. -
-

The token is a short-lived bearer secret. Do not put the generated command in tickets, chat, source control, shared shell history, process supervisors, or screenshots.

- -

What the one-time claim installs

-

The installer downloads the management-authority-pinned managed runtime, then calls pilotctl enterprise adopt. The service returns exactly one delegated node identity plus the public root pin, signed trust bundle, signed bootstrap policy, organization endpoints, adoption options, and run identity. The browser never creates a node key.

-

The client verifies that the credential, key, trust bundle, policy, tenant, agent ID, and HTTPS authority origins agree. It then atomically writes an owner-only attachment under $HOME/.pilot/managed/:

-
    -
  • enterprise-control.json — tenant, endpoints, policy paths, action inventory, rollout, reporting, and state-sync configuration;
    • -
  • trust.json and policy.json — verified signed bootstrap artifacts;
    • -
  • agent.seed — the delegated node seed, stored with owner-only permissions;
    • -
  • restart-safe receipt, continuation, and state directories.
    • -
-

The enrollment token is stored server-side only as a hash, consumed before private credential material is released, removed from the process environment, and never reused. Unknown, expired, and consumed tokens return the same generic error.

- -

Optional controls

- - - - -
OptionWhen enabledWhen disabled
Fleet connectionSigned health, desired state, rollout, and typed commands.Not a managed adoption; this option is required.
In-flight action controlSelected harness actions wait for signed hosted decisions and produce receipts.Ordinary harness actions remain unchanged.
.pilot state visibilitySafe state manifests and revision-checked mutations synchronize over the fleet channel.No state tree or remote state mutation.
-

Core adoption installs the node runtime; it does not install pilot-mcp. Harness attachment is a separate opt-in integration that reads the existing managed attachment. See Harness coverage.

- -

How Pilot verifies adoption

-

The console does not trust a client-side success message. It checks:

-
    -
  • the report signature against the exact delegated key in tenant trust;
    • -
  • the server-allocated agent ID;
    • -
  • the exact harness and one-time onboarding run marker;
    • -
  • a fresh observation time after the command was issued;
    • -
  • the policy revision the node reports as active;
    • -
  • for the guided proof, a durable hosted exchange with a semantic-clause denial for the same agent.
    • -
- -

Moving or replacing a node

-

A managed identity is not portable between organizations. The installer deliberately refuses a new enrollment token when $HOME/.pilot/managed/enterprise-control.json already exists. To replace or move a node, an administrator must retire or revoke the old identity, preserve required evidence, remove the old managed attachment through an approved local decommissioning procedure, and issue a fresh organization-bound adoption. There is no public self-service cross-organization transfer workflow today.

-

Do not copy agent.seed or the complete managed directory to clone a node. Each runtime instance should receive a distinct delegated identity and appear separately in fleet inventory.

- -

Unmanaged compatibility

-

Running the ordinary Pilot installer without --managed-url and without an enrollment token preserves unmanaged behavior. Installing a harness adapter without a valid owner-only managed attachment is a zero-side-effect pass-through. Disabling or removing an optional harness boundary should restore the harness's original execution path, subject to that harness's own configuration.

- -
Before calling a node governed: prove an allowed action, a denied action with no side effect, an approval that resumes only the exact request, an expired approval that stays blocked, a failed tool with terminal evidence, and the documented hook-timeout behavior.
`, - }, - - 'managed-harnesses': { - title: 'Managed Harness Coverage', - description: 'Exact Pilot interception boundaries, attachment commands, failure modes, and production validation requirements for supported agent harnesses.', - body: `

Harness coverage

-

A connector is only as complete as the native action boundary its harness actually exposes.

- -
Core node management is harness-independent. Adoption, signed reporting, policy rollout, typed commands, and safe state synchronization belong to core Pilot. The optional harness adapter adds in-flight control only around the tool, message, or SDK events listed here.
- -

Coverage matrix

- - - - - - - - - - - - - - -
HarnessCurrent boundaryImportant limitation
Claude CodeLive-verified PreToolUse, PostToolUse, and failure events for built-in and MCP tools.A Bash hook sees the proposed command, not every syscall made by its child process.
Codex CLINative pre/post tool hooks plus Pilot MCP.User hooks require review/trust; specialized hosted paths may opt out unless managed requirements cover them.
Gemini CLINative BeforeTool/AfterTool; real allow, result, and denial paths exercised.Model-request interception is separate, and identical parallel calls have limited post-call correlation.
GitHub Copilot CLILocal and repository preToolUse/postToolUse contracts.Documented timeouts fail open; cloud agents need committed repository hooks and reachable ingress.
OpenHandsClaude-compatible pre/post hooks per repository.User-home configuration is not fleet-wide; distribute the repository contract to every workspace.
OpenClawBundled plugin for built-in tools, results, and outbound messages.Only OpenClaw-owned paths are covered; retain sandbox and egress controls.
Hermes AgentNative CLI/Gateway pre/post tool hooks; pinned wire protocol verified.Malformed output, process death, and timeout behavior requires additional containment because upstream failure modes may be fail open.
ClineGlobal PreToolUse/PostToolUse scripts for desktop and SDK-hosted tools.Hook crashes and timeouts are documented as fail open; existing global hooks must be composed explicitly.
CursorNative pre/post tool hooks with fail-closed Pilot preflights.User hooks do not reach cloud agents; use repository, team, or enterprise distribution there.
JetBrains JuniePilot MCP plus Junie's action allowlist.Native Junie actions remain outside Pilot evaluation without a supported interception API.
PicoClawJSON-RPC process hooks for before_tool/after_tool.The upstream runtime is pre-1.0. Pin and certify an exact build; it is not production-certified.
Any MCP clientComplete arguments and results for calls to the Pilot MCP server.Installing Pilot MCP does not intercept other MCP servers or built-in shell, browser, or file tools.
Custom SDK hostPotentially complete BeforeAction/AfterAction wrapping around host-owned side effects.Unwrapped adapters remain outside control; the host must attest and test the complete action inventory.
- -

Attach after adoption

-

Use the version-pinned command shown by the onboarding page. Examples:

- 
npx -y pilotprotocol-mcp@0.2.13 attach --claude
-npx -y pilotprotocol-mcp@0.2.13 attach --codex
-npx -y pilotprotocol-mcp@0.2.13 attach --gemini
-npx -y pilotprotocol-mcp@0.2.13 attach --openclaw
-npx -y pilotprotocol-mcp@0.2.13 attach --hermes
-

The adapter verifies that $HOME/.pilot/managed/enterprise-control.json is a regular owner-owned file with owner-only permissions. It merges supported hook configuration without deliberately replacing an unrelated existing hook. Some harnesses require an explicit restart, trust review, repository-level file, or first-use command approval; follow the connector-specific instructions displayed in the console.

- -

What Pilot receives

-

Where the harness supplies it, a pre-hook sends the canonical action, called tool, complete parameters, explicit file bytes, destination, session and working-directory correlation, permission mode, and timing metadata. A post-hook adds the result, response content, duration, or failure. The hosted exchange makes those fields visible alongside the signed policy and decision.

-

Coverage must be stated per event. An outbound-message hook can govern message delivery even when it is not a general tool hook. MCP coverage means Pilot sees calls to Pilot MCP, not the entire agent. A shell hook is not kernel mediation.

- -

Failure posture

-

Pilot can emit a valid deny when the hosted decision service is reachable but rejects or times out according to policy. It cannot prevent a harness from killing or bypassing its hook process if the harness itself defines that path as fail open. For high-risk actions, choose harnesses and deployment controls that can enforce the required failure posture.

-
    -
  • Use managed hook requirements or repository-distributed hooks where user configuration is optional.
    • -
  • Keep host sandboxing and outbound network policy for child-process containment.
    • -
  • Do not give the Pilot adapter unrelated model-provider or application secrets.
    • -
  • Version-pin both the harness and adapter, then retest after either changes.
    • -
- -

Production certification checklist

-
    -
  1. Inventory every side-effect path: process, file, browser, HTTP, MCP, messages, transfers, trust, events, and payments.
    2. -
  2. Prove an allowed action runs and produces a completed exchange.
    3. -
  3. Prove a denied action leaves no external artifact.
    4. -
  4. Prove approval, exact continuation, expiry, cancellation, and replay rejection.
    5. -
  5. Prove failed tool and post-hook evidence is terminal and non-replaying.
    6. -
  6. Kill and time out the hook to confirm the actual failure posture.
    7. -
  7. Disable the attachment and verify the original unmanaged behavior returns.
    8. -
- -
Do not infer coverage from a logo. The connector's signed capability report and recent runtime evidence determine what a policy can truthfully claim to enforce.
`, - }, - - 'managed-policies': { - title: 'Managed Policies and Approvals', - description: 'Create deterministic and natural-language agent policies, use hosted semantic narrowing, request expiring approval, and deploy signed revisions.', - body: `

Policies and approvals

-

Pilot separates operator intent, executable policy, semantic interpretation, consent, rollout, and post-action response.

- -

On this page

- -

Choose a control surface

- - - - - - -
SurfaceUse it forRuntime effect
Signed policy ruleExact node, action, resource, risk, disclosure, amount, destination, or approval behavior.The first matching rule establishes the deterministic ceiling.
Policy statementHuman-readable restrictions such as “Do not accept trust from anyone.”Compiles into reviewed deterministic rules and/or semantic clauses; no effect until rollout activation.
Semantic clauseMeaning that cannot be resolved from exact metadata, such as confidential content leaving the company.A hosted evaluator may deny or request the pinned approval plan; it never grants above the base answer.
Approval planEligible approvers, quorum, validity, approved outcome, and constraints.May create one payload-bound, single-use continuation after quorum.
ProcedureAlert, investigate, quarantine, refresh, export, or notify after an outcome.Runs after durable activity and cannot modify the original authorization.
- -

Governed actions

-

The managed action vocabulary covers browser navigation; process execution; arbitrary tool invocation; HTTP and webhook requests; data read, export, and text/JSON/binary send; file read, write, delete, and share; event publication; trust request, accept, auto-accept, reject, revoke; wallet payment; and custom registered actions.

-

Policies also bind the target resource, risk, recipient, purpose, labels, content type, residency, retention class, transaction value, destination, and node scope where relevant. An adapter must report an action before Pilot can govern it. Publishing a rule does not create interception.

- -

Natural-language policy workflow

-
    -
  1. Create or select an approval-plan revision first if the desired semantic outcome is approval.
    2. -
  2. Open Policy statements and create a statement with an explicit node scope. * means all nodes in the tenant.
    3. -
  3. Enter the ordinary-language instruction. Add entity-to-resource bindings when a human name must map to a canonical target.
    4. -
  4. Select exact action hints for content-sensitive meaning. Semantic fallback is opt-in and limited to the reviewed deny or approval outcome.
    5. -
  5. Compile the statement. Inspect the source hash, compiler version, deterministic rules, semantic clauses, failure posture, warnings, and unresolved phrases.
    6. -
  6. Edit and recompile until the interpretation is exact. Unresolved compilation cannot enter review.
    7. -
  7. Submit review, approve the source, create a signed rollout draft, inspect its diff and simulations, publish it, obtain signed node acknowledgements, and activate it.
    8. -
-

A prose sentence is never sent directly to a model as unrestricted authority. It remains a revisioned source object bound to the reviewed compilation and active signed policy revision.

- -

Structured policy workflow

-
    -
  1. Select the target node or fleet scope.
    2. -
  2. Choose registered actions, resource prefixes, and applicable risk classes.
    3. -
  3. Select deny, allow, allow with constraints, or approval required.
    4. -
  4. For constraints, set maximum value, allowed destinations, and typed disclosure requirements.
    5. -
  5. For approval, select the exact immutable approval-plan revision.
    6. -
  6. Enter a title and auditable reason; choose full-fleet or canary rollout and acknowledgement thresholds.
    7. -
  7. Create the inactive candidate, run diff and deterministic simulation, obtain required independent approval, publish, then activate.
    8. -
-

Editing produces a higher immutable revision. Removing a rule is also a reviewed signed change. Rollback creates a new higher revision rather than lowering a node's rollback floor.

- -

Runtime order and composition

-
    -
  1. Locally pinned trust and mandate define the hard maximum.
    2. -
  2. The active signed policy evaluates deterministic rules in document order. The first match wins; no match means deny.
    3. -
  3. An eligible active semantic clause may inspect exact hosted content. Semantic allow preserves the base result; deny or approval may narrow it. A base deny remains deny.
    4. -
  4. Conflicting semantic approval plans fail closed. Evaluator, model, prompt, policy, clause, timeout, failure mode, and usage metadata are journaled.
    5. -
  5. The node verifies the final signed result before releasing or blocking the side effect.
    6. -
-

No active semantic clause means no model call and no semantic usage charge. High- and critical-risk failure posture should be explicitly fail closed when the business requirement cannot tolerate an unevaluated action.

- -

Approval and continuation

-

An approval plan is tenant-scoped and immutable by revision. It lists purpose-limited approver keys, required quorum, validity duration, approved outcome, and optional constraints. A transaction binds the exact signed intent and payload hash. Distinct eligible signatures count toward quorum.

-

Approval is not a reusable exception. Quorum creates one single-use continuation for the same request. Rejection, cancellation, expiry, payload mismatch, agent mismatch, plan mismatch, or replay remains blocked. The node stores payload-free continuation state with exclusive creation and a restart-safe lease so at most one resume attempt can occur.

- -

Examples

- - - - - -
Operator statementCompiled or runtime meaning
Don't accept trust from anyone.Deterministic deny for trust.accept and trust.auto_accept on the selected nodes.
Do not transact with Acme.After binding Acme to a canonical merchant resource, deny matching wallet.pay actions.
Do not send confidential material outside the company.Explicit send/share scope plus a reviewed hosted semantic clause that may deny or request security approval.
Finance may pay approved-vendor up to 1,000 USD.Structured node/action/resource rule with amount and destination constraints.
- -

Prove enforcement

-
    -
  1. Confirm the target node reports a blocking capability for the governed action.
    2. -
  2. Activate the exact signed policy revision and wait for the node acknowledgement.
    3. -
  3. Run one allowed action and inspect its complete exchange and post-hook result.
    4. -
  4. Run a violation with a distinctive inert marker.
    5. -
  5. Confirm the decision cites the expected deterministic rule or semantic clause.
    6. -
  6. Confirm the external side effect or marker does not exist.
    7. -
  7. Test approval, expiry, cancellation, replay, evaluator outage, and hook timeout separately.
    8. -
- -
Policy presence is not enforcement proof. Pilot's coverage report combines the signed connector capability, action inventory, blocking/approval support, receipts, and recent runtime evidence. Uncovered targets require an explicit audited exception.
`, - }, - - 'managed-fleet': { - title: 'Managed Fleet and Evidence', - description: 'Operate Pilot nodes remotely, inspect signed state and exchanges, monitor health, automate responses, and retain tenant-scoped audit evidence.', - body: `

Fleet, evidence, and operations

-

Signed inventory, desired state, typed control, exact exchange evidence, audit, monitoring, and bounded automation.

- -

On this page

- -

Inventory and health

-

The native management dashboard summarizes connected nodes, policy coverage, decision outcomes, pending approvals, evaluator health, command state, and recent activity. Fleet views support server-side filters and pagination for node status, group, tag, policy drift, connector capability, runtime version, and last report time.

-

Each node detail joins its signed identity, harness and connector versions, uptime, counters, connectivity, current and desired policy revisions, groups, tags, quarantine posture, recent actions, receipts, commands, state root, and acknowledgements. A stale or missing report is visible; the UI does not silently treat configured state as observed state.

- -

Desired state and drift

-

Authority-signed desired state can set group, tags, desired runtime version, desired policy revision, and quarantine posture. The node verifies the command key and monotonic floors, persists before applying, reconciles locally, then returns a signed applied, partially_applied, or rejected acknowledgement. Drift remains visible until the reported state converges.

-

Runtime version is a desired target, not permission for the control plane to replace arbitrary executables. The deployment supervisor remains responsible for changing installed software.

- -

Remote commands

-

Remote operations are typed, targeted, authority-signed, reason-bound, expiring, cancellable, and auditable. Supported commands are:

-
    -
  • refresh_policy — fetch and acknowledge the current signed rollout;
    • -
  • export_receipts — flush pending signed receipt evidence;
    • -
  • reload_control — reload the verified local control attachment;
    • -
  • sync_state — report and reconcile the safe state tree;
    • -
  • collect_diagnostics — return bounded diagnostic status;
    • -
  • restart_runtime and shutdown_runtime — graceful typed lifecycle requests.
    • -
-

Pilot is not a remote shell. Operators cannot type arbitrary commands into the fleet console. Nodes return bounded signed result codes, and protected local authority cannot be widened through command parameters.

- -

.pilot state visibility

-

An adopted node can report a signed manifest of its managed state directory: relative paths, file or directory kind, size, mode, modification time, content hash, revision, and root hash. Safe text files may expose sanitized or bounded content. Keys, seeds, credentials, identity, policy internals, trust material, and rollback floors are fingerprint-only and immutable through this channel.

-

Supported state changes use optimistic concurrency. A mutation names the expected tree revision and existing file hash, contains an auditable reason, expires, and is signed by the authority. The node independently validates safe paths and modes, applies the change locally, and reports the resulting signed revision. History records additions, changes, removals, and root hashes.

- -

Exchanges and tracing

-

The Exchanges workspace stores tenant-scoped request and response evidence with server-side search and pagination. A detail view correlates:

-
    -
  • agent, action, called resource, intent ID, session, and signing key;
    • -
  • exact request and reported response content, content type, length, encryption key ID, hash, and retention;
    • -
  • recipient, purpose, labels, residency, and retention class;
    • -
  • deterministic and semantic decisions, matched rules and clauses, evaluator/model/prompt versions;
    • -
  • approval transaction, votes, expiry, continuation, and execution state;
    • -
  • post-hook result, receipt, fleet activity, audit entries, and procedure runs.
    • -
-

Browser previews are bounded. Complete retained objects require explicit evidence permission and an audited download. Audit metadata and exact exchange content are separate stores with different access and retention concerns.

- -

Audit and investigations

-

Management mutations write an append-only attempt event and a terminal result event. Records include actor, roles, authentication method, operation, reason, correlation ID, status, duration, and request/response hashes without copying secrets. Operators can filter, paginate, inspect, export NDJSON, monitor continuous delivery, and retry dead-letter exports.

-

Investigations have assignee, severity, status, resolution, timestamps, and links to action, exchange, receipt, command, and audit evidence. Legal hold and retention policy preserve required objects. Signed action receipts are verified at ingest and may be mirrored into compliance-retention object storage.

- -

Procedures

-

Procedures are immutable, revisioned, post-action response policies. Triggers match action, node, risk, decision, or observed result. The closed response vocabulary can create an alert, open an investigation, quarantine a node, request policy refresh, request receipt export, or notify an active integration.

-

A run is durable and idempotent for the activity and procedure revision. Procedures cannot grant or retry the original action, inspect arbitrary content, execute shell commands, or invent remote methods.

- -

External integrations

- - - - - - - - -
KindPurposeLifecycle
OIDC / KeycloakOptional workforce identity federation.Stage, inspect, probe, activate, rotate, disable.
OpenBao / KMSExternal signing-key custody.Reference-only secrets and signature verification.
S3-compatible Object LockImmutable receipt and evidence mirror.Retention and legal-hold evidence.
PostgreSQLReplica-safe shared authority state.TLS, migrations, backup, restore, and health.
Prometheus-compatible storageMetrics retention.Pilot's native UI remains the operator dashboard.
Usage sinkAsynchronous idempotent commercial usage delivery.Tenant-scoped credentials and delivery health.
Audit/SIEM and webhookManagement export, approval, and procedure notifications.Retry, dead letter, health, and rotation.
-

Connectors store secret references, not rendered secret values. Hosted semantic evaluation is Pilot platform infrastructure and is not configured as a customer-owned integration.

- -

Object lifecycle

- - - - - - - -
ObjectCreateChangeTerminal behavior
NodeOne-time adopted identity and signed report.Desired state, tags, groups, quarantine, commands.Retire or revoke; reactivate only where policy permits.
Policy statementInactive source revision.Compile, review, approve, deploy.Reject or retire; signed policy removal is a higher revision.
Policy changeDraft candidate.Diff, simulate, approve, publish, canary, promote.Withdraw, terminate, or monotonic rollback.
Approval transactionExact intent and payload binding.Vote, escalate, cancel.Execute once, reject, cancel, or expire.
ProcedureInactive draft revision.New revision, activate, disable.Retire while retaining run evidence.
IntegrationStaged revision.Probe, activate, rotate, disable.Retain revision and audit history.
- -
High-volume behavior. Fleet, exchanges, approvals, receipts, audit, procedures, and activity lists use tenant-scoped server-side filters and pagination. Production sizing still requires load, retention, backup, and failover evidence for the intended fleet and event rate.
`, - }, - - 'managed-readiness': { - title: 'Hosted Availability and Readiness', - description: 'Honest current availability, production-readiness status, validated control-plane functionality, remaining launch blockers, and deployment guidance.', - body: `

Availability and production readiness

-

What is live, what has been proved, and what still prevents a general production launch.

- -
Verdict as of 8 August 2026. The hosted management deployment is online and its central enforcement path has been validated with real adopted agents. It is not production-grade as a public multi-tenant SaaS. It should be described as a production-hosted pre-release or design-partner environment, not generally available production service.
- -

On this page

- -

Current live status

- - - - - - - - - - -
CapabilityStatusMeaning
Management loginLiveThe HTTPS login page is reachable and existing accounts can authenticate.
Public account signupNot deployed/v1/auth/signup returns signup_unavailable; new unrelated organizations cannot self-register.
Organization availabilitySingle preconfigured tenantThe live service currently serves the Pilot demonstration organization.
Managed node adoptionLive for the configured tenantShort-lived one-time enrollment, verified delegated identity, bootstrap policy, and signed first report work.
Policy and semantic denialValidatedA real Gemini-driven adopted agent was denied before executing a prohibited command; the expected filesystem side effect was absent.
Policy, approval, fleet, state, audit UIValidated pre-releasePrimary CRUD/lifecycle paths and 31 management pages have passed production-host UI sweeps.
Harness adaptersMixed by harnessSeveral native paths are verified; partial and fail-open connectors remain explicitly labelled.
Plans and paymentsDisabled by product decisionPublic launch has one common entitlement, no checkout, no upgrade UI, and no customer charging. Usage remains measured for cost control.
Public multi-tenant platformNot deployedThe SaaS provisioner, pooled runtime, account subdomains, and workspace controller are implemented/tested locally but not installed in the hosted GCP environment.
- -

What has been proved

-
    -
  • HTTPS management health, invitation-oriented login, tenant-scoped browser access, and cross-tenant query rejection.
    • -
  • One-time managed adoption with server-assigned identity, signed trust and policy verification, secure local attachment, and fresh signed check-in.
    • -
  • Structured policy creation, review, activation, semantic-clause evaluation, signed denial, post-hook evidence, and deletion/retirement paths.
    • -
  • A real agent model proposed a prohibited process.execute action; Pilot denied it and the intended file was not created.
    • -
  • Fleet detail, desired state, commands, acknowledgements, safe .pilot state create/read/history/delete, monitoring, traffic, approvals, audit, investigations, integrations, and readiness pages.
    • -
  • Tenant-attributed evaluator usage and idempotent usage-ledger behavior in local full-stack and Kubernetes acceptance environments.
    • -
  • Version-pinned adapter packaging and regression coverage, including compatibility for the removed legacy heartbeat hook command.
    • -
-

These proofs establish that the core security concept works. They do not establish the operational, organizational, and provider controls required for a generally available SaaS.

- -

Actual public SaaS blockers

-

There are seven launch gates. Plans and Stripe are deliberately disabled and are not an eighth gate.

-
    -
  1. Signup and provisioning: deploy and prove the full email verification, workspace reservation, owner creation, exact account subdomain, first session, adoption, retry, rollback, and cleanup journey without operator intervention.
    2. -
  2. Tenant isolation: add a database-enforced boundary such as PostgreSQL RLS with mandatory tenant context or separate credentials/schema, then prove host routing, secrets, workers, caches, exports, logs, metrics, and backups cannot cross organizations.
    3. -
  3. GCP KMS and storage integration: exercise native Cloud KMS signing/content-key wrapping and native Cloud Storage conditional writes, locked retention, legal hold, rotation, restore, outage, and cross-tenant denial through workload identity.
    4. -
  4. Quotas and abuse controls: enforce distributed signup defenses plus hard node, request, event, content, storage, retention, queue, and semantic-spend ceilings, noisy-neighbor isolation, reservation cleanup, and operator response.
    5. -
  5. Organization lifecycle: prove audited rename, owner transfer, suspension/resume, export, deletion, legal hold, node and credential revocation, usage closure, subdomain cleanup, retry, and partial-failure recovery.
    6. -
  6. Load and disaster-recovery evidence: retain the declared workload envelope, latency/error/saturation and soak results, backup/PITR and object restore, key recovery, failover, provider outage, rolling upgrade, rollback, and measured RPO/RTO.
    7. -
  7. Security assurance: complete independent penetration and architecture review, close findings, approve the pooled-tenancy, hosted-content/LLM, hook-bypass, privileged-support, supply-chain, recovery, and abuse threat models, and retain exact-release security evidence.
    8. -
- -

What production-grade means here

-

A service being deployed on a production hostname is not enough. General production readiness requires all of the following:

-
    -
  • new account to isolated tenant to real-agent denial works without operator intervention;
    • -
  • cross-tenant reads, writes, host routing, secrets, usage, and backups fail closed under adversarial tests;
    • -
  • every marketed harness claim is version-pinned and has allowed, denied, approval, timeout, and bypass evidence;
    • -
  • provider credentials, keys, content, logs, evidence, and backups have reviewed retention and recovery controls;
    • -
  • quota and usage-metering failures cannot expand authority or create unbounded model or infrastructure spend;
    • -
  • documented SLOs, support, incident response, vulnerability handling, deployment rollback, and change management are staffed and exercised.
    • -
- -

Where it is appropriate today

- - - - - - -
Use caseRecommendation
Internal demonstration with the existing tenantYes. The live environment and permanent proof agents support this use.
Supervised design-partner evaluationYes, with a written scope, connector boundary, data/retention agreement, and operational owner.
Single-organization production pilotConditional. Perform organization-specific threat modelling, capacity tests, backup/restore, key custody, and incident readiness first.
Open public self-service SaaSNo. Signup, provisioning, multi-tenant hardening, planless cost controls, and cloud platform gates remain.
Regulated or safety-critical autonomous productionNo general approval. It requires independent assurance, exact harness certification, retention/legal review, and customer-specific controls.
- -
Status discipline. This page records a dated deployment assessment, not a permanent guarantee. Reassess it after every authority, adapter, cloud, identity, evaluator, entitlement, or quota release.
`, - }, -}; diff --git a/src/layouts/BlogLayout.astro b/src/layouts/BlogLayout.astro index afde4ad9..6e4f810b 100644 --- a/src/layouts/BlogLayout.astro +++ b/src/layouts/BlogLayout.astro @@ -132,14 +132,6 @@ const funnelCtaGroups = [ href: '/solutions/grounded-agent-search', label: 'Explore grounded agent search', }, - { - slugs: new Set(['claude-agent-teams-over-pilot']), - eyebrow: 'For engineering leaders', - title: 'Manage coding-agent settings and usage as a fleet', - body: 'Review the early-access control surface for inventory, signed settings, usage attribution, and audited remote operations.', - href: '/enterprise/claude-code-management', - label: 'Review enterprise management', - }, { slugs: new Set([ 'enterprise-identity-integration-pilot-protocol', @@ -148,10 +140,10 @@ const funnelCtaGroups = [ 'enterprise-production-complete-identity-directory-audit-export', ]), eyebrow: 'For enterprise AI teams', - title: 'Put autonomous agents inside an operating control loop', - body: 'Connect fleet state, signed policy, approvals, bounded remote operations, usage telemetry, and action evidence.', - href: '/enterprise/autonomous-ai-agents', - label: 'Explore the agent control plane', + title: 'Review the controls for private agent networks', + body: 'Roles, external identity validation, network policy, key lifecycle, blueprints, and audit export for networks you operate.', + href: '/docs/enterprise', + label: 'Read the enterprise documentation', }, ]; const funnelCta = funnelCtaGroups.find((group) => group.slugs.has(currentSlug)); diff --git a/src/lib/seo.mjs b/src/lib/seo.mjs index 8aca12a1..8aa5c882 100644 --- a/src/lib/seo.mjs +++ b/src/lib/seo.mjs @@ -16,8 +16,6 @@ const ROUTE_TITLES = new Map([ ['/contact', 'Contact Pilot Protocol: Sales, Partnerships and Press'], ['/cookies', 'Cookie Policy and Tracking Controls | Pilot Protocol'], ['/docs', 'Pilot Protocol Documentation: Guides and API Reference'], - ['/enterprise/autonomous-ai-agents', 'Autonomous AI Agent Control Plane | Pilot Protocol'], - ['/enterprise/claude-code-management', 'Claude Code Management for Enterprise | Pilot Protocol'], ['/governance', 'Agent Network Governance and Controls | Pilot Protocol'], ['/learn', 'Pilot Protocol Learning Center: Guides and Concepts'], ['/news', 'Pilot Protocol Company News and Product Announcements'], diff --git a/src/pages/blog/connect-claude-code-to-pilot-protocol.astro b/src/pages/blog/connect-claude-code-to-pilot-protocol.astro index af5e1c67..489fef82 100644 --- a/src/pages/blog/connect-claude-code-to-pilot-protocol.astro +++ b/src/pages/blog/connect-claude-code-to-pilot-protocol.astro @@ -4,12 +4,12 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl diff --git a/src/pages/blog/connect-cline-to-pilot-protocol.astro b/src/pages/blog/connect-cline-to-pilot-protocol.astro index d1fdd37d..c7866768 100644 --- a/src/pages/blog/connect-cline-to-pilot-protocol.astro +++ b/src/pages/blog/connect-cline-to-pilot-protocol.astro @@ -3,13 +3,13 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- diff --git a/src/pages/blog/connect-codex-cli-to-pilot-protocol.astro b/src/pages/blog/connect-codex-cli-to-pilot-protocol.astro index 800dc880..f27f1672 100644 --- a/src/pages/blog/connect-codex-cli-to-pilot-protocol.astro +++ b/src/pages/blog/connect-codex-cli-to-pilot-protocol.astro @@ -3,13 +3,13 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- diff --git a/src/pages/blog/connect-cursor-to-pilot-protocol.astro b/src/pages/blog/connect-cursor-to-pilot-protocol.astro index 30c7cad9..9e1b25cf 100644 --- a/src/pages/blog/connect-cursor-to-pilot-protocol.astro +++ b/src/pages/blog/connect-cursor-to-pilot-protocol.astro @@ -3,13 +3,13 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- diff --git a/src/pages/blog/connect-gemini-cli-to-pilot-protocol.astro b/src/pages/blog/connect-gemini-cli-to-pilot-protocol.astro index cbcfeaaa..fdebdb4b 100644 --- a/src/pages/blog/connect-gemini-cli-to-pilot-protocol.astro +++ b/src/pages/blog/connect-gemini-cli-to-pilot-protocol.astro @@ -3,13 +3,13 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- diff --git a/src/pages/blog/connect-github-copilot-to-pilot-protocol.astro b/src/pages/blog/connect-github-copilot-to-pilot-protocol.astro index a253429b..0bb9e339 100644 --- a/src/pages/blog/connect-github-copilot-to-pilot-protocol.astro +++ b/src/pages/blog/connect-github-copilot-to-pilot-protocol.astro @@ -4,12 +4,12 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl diff --git a/src/pages/blog/connect-hermes-to-pilot-protocol.astro b/src/pages/blog/connect-hermes-to-pilot-protocol.astro index bda1f792..b445e3e4 100644 --- a/src/pages/blog/connect-hermes-to-pilot-protocol.astro +++ b/src/pages/blog/connect-hermes-to-pilot-protocol.astro @@ -3,13 +3,13 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- diff --git a/src/pages/blog/connect-openhands-to-pilot-protocol.astro b/src/pages/blog/connect-openhands-to-pilot-protocol.astro index 7604feac..35fefa9b 100644 --- a/src/pages/blog/connect-openhands-to-pilot-protocol.astro +++ b/src/pages/blog/connect-openhands-to-pilot-protocol.astro @@ -3,13 +3,13 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- diff --git a/src/pages/blog/connect-picoclaw-to-pilot-protocol.astro b/src/pages/blog/connect-picoclaw-to-pilot-protocol.astro index 237bc1b4..9a6f0750 100644 --- a/src/pages/blog/connect-picoclaw-to-pilot-protocol.astro +++ b/src/pages/blog/connect-picoclaw-to-pilot-protocol.astro @@ -3,14 +3,14 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- diff --git a/src/pages/blog/openclaw-meets-pilot-agent-networking-one-command.astro b/src/pages/blog/openclaw-meets-pilot-agent-networking-one-command.astro index 0b25e930..ae24577d 100644 --- a/src/pages/blog/openclaw-meets-pilot-agent-networking-one-command.astro +++ b/src/pages/blog/openclaw-meets-pilot-agent-networking-one-command.astro @@ -3,14 +3,14 @@ import HarnessIntegrationArticle from '../../components/HarnessIntegrationArticl --- - - diff --git a/src/pages/docs/managed-agent-adoption.astro b/src/pages/docs/managed-agent-adoption.astro deleted file mode 100644 index 9088a170..00000000 --- a/src/pages/docs/managed-agent-adoption.astro +++ /dev/null @@ -1,16 +0,0 @@ ---- -import DocLayout from '../../layouts/DocLayout.astro'; -import { managedDocs } from '../../data/managedDocs'; - -const doc = managedDocs['managed-agent-adoption']; ---- - - - diff --git a/src/pages/docs/managed-control-plane.astro b/src/pages/docs/managed-control-plane.astro deleted file mode 100644 index be8ccb6a..00000000 --- a/src/pages/docs/managed-control-plane.astro +++ /dev/null @@ -1,16 +0,0 @@ ---- -import DocLayout from '../../layouts/DocLayout.astro'; -import { managedDocs } from '../../data/managedDocs'; - -const doc = managedDocs['managed-control-plane']; ---- - - - diff --git a/src/pages/docs/managed-fleet.astro b/src/pages/docs/managed-fleet.astro deleted file mode 100644 index 977a0167..00000000 --- a/src/pages/docs/managed-fleet.astro +++ /dev/null @@ -1,16 +0,0 @@ ---- -import DocLayout from '../../layouts/DocLayout.astro'; -import { managedDocs } from '../../data/managedDocs'; - -const doc = managedDocs['managed-fleet']; ---- - - - diff --git a/src/pages/docs/managed-harnesses.astro b/src/pages/docs/managed-harnesses.astro deleted file mode 100644 index 453bcf06..00000000 --- a/src/pages/docs/managed-harnesses.astro +++ /dev/null @@ -1,16 +0,0 @@ ---- -import DocLayout from '../../layouts/DocLayout.astro'; -import { managedDocs } from '../../data/managedDocs'; - -const doc = managedDocs['managed-harnesses']; ---- - - - diff --git a/src/pages/docs/managed-policies.astro b/src/pages/docs/managed-policies.astro deleted file mode 100644 index d9ec1781..00000000 --- a/src/pages/docs/managed-policies.astro +++ /dev/null @@ -1,16 +0,0 @@ ---- -import DocLayout from '../../layouts/DocLayout.astro'; -import { managedDocs } from '../../data/managedDocs'; - -const doc = managedDocs['managed-policies']; ---- - - - diff --git a/src/pages/docs/managed-readiness.astro b/src/pages/docs/managed-readiness.astro deleted file mode 100644 index 462b9683..00000000 --- a/src/pages/docs/managed-readiness.astro +++ /dev/null @@ -1,16 +0,0 @@ ---- -import DocLayout from '../../layouts/DocLayout.astro'; -import { managedDocs } from '../../data/managedDocs'; - -const doc = managedDocs['managed-readiness']; ---- - - - diff --git a/src/pages/enterprise/autonomous-ai-agents.astro b/src/pages/enterprise/autonomous-ai-agents.astro deleted file mode 100644 index 9ec5ef09..00000000 --- a/src/pages/enterprise/autonomous-ai-agents.astro +++ /dev/null @@ -1,201 +0,0 @@ ---- -import BaseHead from '../../components/BaseHead.astro'; -import Nav from '../../components/Nav.astro'; -import Footer from '../../components/Footer.astro'; -import '../../styles/system.css'; -import '../../styles/enterprise-pages.css'; - -const title = 'Autonomous AI Agent Control Plane | Pilot Protocol'; -const description = 'Operate autonomous AI agent fleets with signed policy, live approvals, typed remote commands, usage telemetry, and cryptographically bound action evidence.'; -const canonicalUrl = 'https://pilotprotocol.network/enterprise/autonomous-ai-agents'; - -const controlLoop = [ - ['Observe', 'Collect signed health, runtime, policy, activity, and drift signals from every enrolled agent.'], - ['Decide', 'Apply deterministic rules first, with reviewed semantic clauses only where an operator permits them.'], - ['Approve', 'Hold consequential actions for expiring, payload-bound human consent instead of blanket permission.'], - ['Enforce', 'Let the local node verify the signed decision before the governed side effect proceeds.'], - ['Prove', 'Join intent, decision, approval, result, and receipt into one inspectable evidence trace.'], -]; - -const capabilities = [ - ['01', 'Fleet inventory', 'Enroll, group, tag, quarantine, retire, and inspect agents with observed versus desired state.'], - ['02', 'Signed policy lifecycle', 'Simulate changes, review diffs, canary a revision, collect acknowledgements, activate, and roll back monotonically.'], - ['03', 'Live approval', 'Bind a vote to the exact intent and payload hash, with quorum, expiry, cancellation, and one-time resumption.'], - ['04', 'Governed actions', 'Constrain tool calls, processes, browser navigation, files, HTTP, data export, messages, wallets, and webhooks.'], - ['05', 'Operational evidence', 'Search exchanges and action traces across called resource, policy decision, approval, result, and signed receipt.'], - ['06', 'Identity and access', 'Separate tenant roles, sessions, node identity, enrollment, delegation, and management-plane authority.'], -]; ---- - - - - - - - -