[williamloo-scale]

Stacked on #429.

The gateway side of website/v1: roles that can't be spoofed, the address a site is reached at, and triggers matched by route.

• Role key, opt-in per deploy. A deploy with keyed_roles (deploy_env's keyed_roles: true, or env deploy --keyed-roles) draws a secret role key, gives it to the gateway (AGENTENV_ROLE_KEY) and to each website server (WEBSITE_ROLE_KEY), and records it on the deployed env (DeployedEnv.role_key, sent by role_headers(role)). Its gateway believes a role other than default, on REST and MCP, only beside AgentEnv-Role-Key equal to the key. It strips a client's key and sends its own upstream only beside a verified role, so SDK sites believe it. deploy_agent, the episode proxy, post-turn hook /step calls and the generated MCP CLI send the key. Any other deploy draws none, and its gateway believes the role header alone, as before. A step asking for keyed_roles of an env whose provider doesn't take them is refused at save.
• Forwarded headers. /svc and /website set X-Forwarded-Host, -Proto and -Prefix and drop the client's copies. The SDK takes the prefix as the root path, so base_url, request.url and redirects name the gateway's address.
• Triggers by route. A website trigger's when may name op, a route of the site's card, and then matches only requests that reach it. Registration refuses an op the card doesn't name. triggers/v1 declares website_op, so an older gateway is refused.

Before merging

• On a keyed_roles deploy, a caller that sends a non-default role without role_headers(role) is default; agentenvhub-sdk and the hub don't send the key yet, so their tasks shouldn't turn it on until they do. Unkeyed deploys, the default, are unaffected.
• An agent deployed with a role receives the key, so the key protects against pages and browsers, not a hostile agent.
• The key is stored in plaintext on the instance record, beside the control token.
• The CLI's default role cli is default on a keyed deploy.

Test

Unit suite: 12,712 passed (one GitHub-clone test from main, which hangs on the local machine on main too, deselected).

🤖 Generated with Claude Code

Confidence Score: 5/5

No new blocking issue was established in this review.

Summary

Adds optional role keys, forwarded website addresses, and triggers matched by a named website route.

• Keyed deploys verify non-default roles before the gateway accepts them.
• Website requests now carry the gateway address and path prefix to the site.
• Website triggers can now match requests by a named site route.

Diagram

sequenceDiagram
    participant Caller
    participant Gateway
    participant Website
    participant Triggers
    Caller->>Gateway: Request with role and optional key
    Gateway->>Gateway: Check role key when enabled
    Gateway->>Website: Verified role and forwarded address
    Website-->>Gateway: Response
    Gateway->>Triggers: Match method, path, status, and route name
    Triggers-->>Gateway: Complete any response barrier
    Gateway-->>Caller: Response

Loading

_{Reviews (14) · Last reviewed commit: "feat(gateway): a keyed deploy's role key..." · Reviewed by Greptile}

[earakely-scale]

A heads-up from #478 (M8.54). The driver's /svc/<app>/ now follows this PR's forwarded-header convention: it drops the caller's X-Forwarded-Host, -Proto and -Prefix and sets its own, and drops hop-by-hop headers and those a Connection header names. That lives in agentenv_protocol.computer.svc (passed_on, to_app), while this PR has its own in env/gateway/rest_proxy.py (HOP_BY_HOP, FORWARDED_*).

Once both merge, could the gateway use the same helpers, so there's one convention to keep in step (which headers drop, how X-Forwarded-Proto is set, a chained proxy's values)? No change needed in this PR; I'm happy to do it as a follow-up.