Hot domain approval: move the fetch allowlist into Redis and let Deep ask Kai to approve or deny a host mid-turn #941

New issue

Open

opened 2026-08-18 01:35:54 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-18 01:35:54 +00:00

Member

Requested by Kai, 2026-08-18. Filed by Darren (director seat) and deliberately NOT started.

This is a feature, so it sits behind August 20 under #929. The amendment released operational improvements, and this is not one: it changes what Deep can do, adds a runtime dependency, and opens a new interaction surface. Kai asked for it in the same breath as the operational fetch fix in #940, and I split them so #940 can ship now without waiting on this.

What Kai asked for, in her words

we need to move the allow list into redis so I can approve domains hot. giving owl deep a "approve or deny" prompt would help massively here. maybe as an out of band DM?

Why it is worth building

#940 measures the problem it solves. SIRENS_ECHO_FETCH_HOSTS is a 28-entry environment variable, so every domain approval today is a deploy. In the 2026-08-18 00:20-00:56Z window Deep ran 8 web searches and then failed 6 fetches against hosts the allowlist was never going to admit. A human who could say yes in five seconds was sitting right there.

Three parts, and the third one has a problem

1. Allowlist in Redis. A redis deployment already exists on kai-server (redis/redis-7cbbf6fc8f-bf56g, 4.8MB resident), so the dependency is present rather than new infrastructure. The harness reads the host set at turn start instead of from SIRENS_ECHO_FETCH_HOSTS.

Carry the validation forward or lose it. sirens-deep-owl-glass-values.yaml records that the current list was validated against the merged matcher on sirens-echo#637, at 28 hosts reachable and 17 lookalikes refused, and that *.luma.com deliberately does not cover luma.com with a test pinning it at sirens-echo#663. A Redis-backed list that skips that matcher is a security regression, not a convenience. Whatever writes to Redis has to run the same matcher the env var list was validated against.

2. Approve or deny prompt. Deep hits a refused host, asks, and continues on a yes. Design questions I am not answering here: what the turn does while waiting, whether the approval is one-shot or permanent, whether a denial is remembered, and who other than Kai may approve.

3. Out of band DM, which does not work on this lane as built.

sirens-deep-owl-glass-values.yaml sets SIRENS_ECHO_DISCORD_DM_ENABLED: "false", and the comment above it says exactly why:

DM_ENABLED is false, unlike Deep. A DM carries no guild, so it cannot be split by channel the way guild traffic is, and both lanes would answer one DM. Operator DM access stays on sirens-deep alone.

Both lanes share one DISCORD_TOKEN and both gateway connections receive every event, so a DM to Deep would be answered twice, once by each lane. That is the exact problem the lane split was created to solve.

So the DM idea needs one of these, and picking is a decision rather than an implementation detail:

Route approvals through sirens-deep, which already has operator DM access, and have it write the shared Redis key that owl.glass reads. Cheapest, and it keeps DM handling in one lane.
Use a private channel instead of a DM, which carries a guild and therefore splits cleanly by the existing access policy. Loses the "out of band" property Kai asked for.
Mint a second Discord application for owl.glass. The values file records that sharing the token was deliberate, so this reverses a decision rather than extending one.

I would take the first. It is the only one that gets a real DM without touching the token split.

Dependencies

#940 should land first. If the model is told the allowlist up front, it stops requesting hosts at random, and the approval prompt then fires on considered requests rather than on search noise.
The August 20 freeze lift, or an explicit override from Kai.

What I did not do

No code, no Redis schema, no branch. Recording the request with its blocker found, so that whoever picks it up on August 20 does not spend their first hour discovering the DM conflict.

**Requested by Kai, 2026-08-18. Filed by Darren (director seat) and deliberately NOT started.** **This is a feature, so it sits behind August 20 under `#929`.** The amendment released operational improvements, and this is not one: it changes *what* Deep can do, adds a runtime dependency, and opens a new interaction surface. Kai asked for it in the same breath as the operational fetch fix in `#940`, and I split them so `#940` can ship now without waiting on this. ## What Kai asked for, in her words > we need to move the allow list into redis so I can approve domains hot. giving owl deep a "approve or deny" prompt would help massively here. maybe as an out of band DM? ## Why it is worth building `#940` measures the problem it solves. `SIRENS_ECHO_FETCH_HOSTS` is a 28-entry environment variable, so **every domain approval today is a deploy**. In the 2026-08-18 00:20-00:56Z window Deep ran 8 web searches and then failed 6 fetches against hosts the allowlist was never going to admit. A human who could say yes in five seconds was sitting right there. ## Three parts, and the third one has a problem **1. Allowlist in Redis.** A `redis` deployment already exists on kai-server (`redis/redis-7cbbf6fc8f-bf56g`, 4.8MB resident), so the dependency is present rather than new infrastructure. The harness reads the host set at turn start instead of from `SIRENS_ECHO_FETCH_HOSTS`. **Carry the validation forward or lose it.** `sirens-deep-owl-glass-values.yaml` records that the current list was validated against the merged matcher on `sirens-echo#637`, at 28 hosts reachable and 17 lookalikes refused, and that `*.luma.com` deliberately does not cover `luma.com` with a test pinning it at `sirens-echo#663`. **A Redis-backed list that skips that matcher is a security regression, not a convenience.** Whatever writes to Redis has to run the same matcher the env var list was validated against. **2. Approve or deny prompt.** Deep hits a refused host, asks, and continues on a yes. Design questions I am not answering here: what the turn does while waiting, whether the approval is one-shot or permanent, whether a denial is remembered, and who other than Kai may approve. **3. Out of band DM, which does not work on this lane as built.** `sirens-deep-owl-glass-values.yaml` sets `SIRENS_ECHO_DISCORD_DM_ENABLED: "false"`, and the comment above it says exactly why: > DM_ENABLED is false, unlike Deep. A DM carries no guild, so it cannot be split by channel the way guild traffic is, and both lanes would answer one DM. Operator DM access stays on sirens-deep alone. Both lanes share one `DISCORD_TOKEN` and both gateway connections receive every event, so **a DM to Deep would be answered twice, once by each lane.** That is the exact problem the lane split was created to solve. So the DM idea needs one of these, and picking is a decision rather than an implementation detail: * **Route approvals through `sirens-deep`**, which already has operator DM access, and have it write the shared Redis key that owl.glass reads. Cheapest, and it keeps DM handling in one lane. * **Use a private channel instead of a DM**, which carries a guild and therefore splits cleanly by the existing access policy. Loses the "out of band" property Kai asked for. * **Mint a second Discord application** for owl.glass. The values file records that sharing the token was deliberate, so this reverses a decision rather than extending one. I would take the first. It is the only one that gets a real DM without touching the token split. ## Dependencies * `#940` should land first. If the model is told the allowlist up front, it stops requesting hosts at random, and the approval prompt then fires on considered requests rather than on search noise. * The August 20 freeze lift, or an explicit override from Kai. ## What I did not do No code, no Redis schema, no branch. Recording the request with its blocker found, so that whoever picks it up on August 20 does not spend their first hour discovering the DM conflict.

coilyco-ops added the

labels

2026-08-18 01:35:54 +00:00