Lit Actions: expose the requester's IP address (Lit.Actions.requesterIpAddress())

[clawdbot-glitch003]

Summary

Add a runtime op that returns the IP address of the HTTP client that invoked the current action, e.g.

const ip = await Lit.Actions.requesterIpAddress(); // "203.0.113.7"

Motivation

We're building a programmable credential-access product (a Turnkey "Secrets" clone — see plans/programmable-credential-access.md) as an app on top of Chipotle rather than inside it. The app is control-plane only: a pinned reader action decrypts a secret and returns it directly to the calling agent, gated by an app-signed grant. Today the action has no information about who called it beyond "some usage key in the group", so it cannot enforce caller-scoped policy such as:

• "this credential may only be read from the agent fleet's egress CIDR"
• "bind this grant to the IP it was issued to" (blunts grant theft/replay)
• IP-based rate limiting or geo-fencing inside the action

Rather than adding an enforced per-credential allow_net / egress allowlist to the runtime (bigger change, discussed and deferred), the simplest primitive is to expose the requester IP and let the action enforce whatever it wants in JS.

Proposed implementation

• lit-api-server: capture req.client_ip() in the lit_action / lit_binary_action handlers and pass it into the execution request (new optional field on ExecuteJsRequest in lit-actions/grpc/schema, alongside ipfs_id).
• lit-actions: add op_requester_ip_address (sync op reading from the per-execution state) + a Lit.Actions.requesterIpAddress() binding in ext/js/02_litActionsSDK.js; for the gVisor lane, expose it as a reserved env var (e.g. LIT_REQUESTER_IP) via the existing RESERVED_ENV machinery in gvisor-server/src/supervisor.rs.
• Return null/empty when unavailable rather than throwing.

Trust model note

client_ip() honours Rocket's ip_header (default X-Real-IP) and otherwise falls back to the socket peer. Behind dstack-ingress the peer is always the proxy, so this is only meaningful if the ingress overwrites X-Real-IP with $remote_addr (same caveat already documented in lit-api-server/src/core/v1/guards/rate_limit.rs). Docs for the new op should state that plainly.

Related (optional follow-up)

A sibling op Lit.Actions.requesterApiKeyHash() (keccak256 of the calling usage key, which the server already computes for on-chain authz) would let actions bind grants to a specific agent identity, not just its IP. Worth doing at the same time if cheap — same plumbing.

[GTC6244]

Thanks — this is a well-scoped ask and your proposed implementation is essentially the right plumbing. Confirming feasibility against the current code:

• IP capture: req.client_ip() is available in the Rocket layer (the CPL-367 unauthenticated-new_account rate-limit guard already uses exactly this accessor). The endpoints are lit_action / lit_binary_action in core/v1/endpoints/actions.rs; they'd take the IP and pass it down.
• Transport: add an optional field to ExecutionOptions (actions/client/models.rs) and to ExecutionRequest in lit-actions/grpc/schema/lit_actions.proto (a new optional string field is backward-compatible).
• Op: a sync op mirroring op_show_import_details in lit-actions/ext/bindings.rs (#[op2] #[string], reads a per-execution value from OpState) — no async round-trip needed — plus a requesterIpAddress() wrapper in ext/js/02_litActionsSDK.js. The value gets state.put(..) in server/runtime.rs alongside the other per-execution state.
• gVisor lane: injected as a reserved env var (e.g. LIT_REQUESTER_IP) via the RESERVED_ENV machinery — note this machinery is on the CPL-355 startup-script branch (PR feat(gvisor-server): startup.sh-only execution + separate startup_script field (CPL-355) #571), so gVisor parity depends on that landing. The JS lane can ship independently.

Trust caveat (must be documented on the op): client_ip() is only as trustworthy as the ingress's real-IP handling — behind dstack-ingress the socket peer is always the proxy, so the value is meaningful only if the ingress overwrites X-Real-IP with $remote_addr. If a client-supplied header is passed through, it's spoofable. This is the same caveat already documented on the CPL-367 rate-limit guard. So requesterIpAddress() should be documented as best-effort/untrusted for security decisions unless ingress hardening is guaranteed — which somewhat blunts the "bind grant to IP / egress-CIDR gate" use case; worth stating plainly so integrators don't over-trust it.

The sibling requesterApiKeyHash() idea is cheap on the same plumbing (the server already computes the usage-key hash for on-chain authz) and is arguably the stronger primitive since it isn't spoofable the way a header is — happy to include it.

Accepting as an enhancement; tracking the JS-lane op now, gVisor parity behind #571.