Egress clause covers evaluation transport only, so production agent lanes are uncovered #1429

New issue

Open

opened 2026-08-30 01:24:09 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-30 01:24:09 +00:00

Owner

The gap

AGENTS.md:29 (the public cloud evaluation approval clause, landed via inbox#429) ends with:

It covers evaluation transport only, never publication or any other external action.

That scoping is deliberate and correct for what it was written to authorize. The gap is that it is now being cited for traffic it does not reach.

Sirens Echo Deep is production Discord traffic, not an evaluation. Every summon composes the advocate role bundle and sends it to a hosted third-party provider. Verified in deploy/agent-routes/service-routes.json: route sirens-echo/deepseek resolves to deepseek-v4-flash on deepseek-api, with a fallback to deepseek-ai/DeepSeek-V4-Pro-0813 on baseten-api. deploy/agent-routes/deployment-targets.json confirms both are hosted API targets with their own credentials, not local weights.

So the standing written authorization for sending composed role bundles to a third-party provider covers the evaluation lane and stops there. The production lane is not prohibited by anything, it is simply not covered by the rule everyone reaches for.

Why this is worth writing down

The clause's exclusion list is the valuable part, and it is the part that does not currently reach production. The graded-layer exclusion exists because a board is an instrument later runs are compared against, so a provider that trains on critiques, evidence spans, and the taxonomy is handed the answer key. That reasoning is about measurement integrity rather than provider terms.

Production has the sibling version of that risk and no written fence: the exclusions for secrets, credentials, private overlays, and unpublished personal information are exactly what a community agent's context could pick up at runtime, and the clause that names them does not apply to it.

What this is not

This is not a terms-of-service finding. Checked directly:

Anthropic AUP, "Do Not Abuse our Platform" - the training bullet has a purpose element ("to train an AI model") and sits in an enumerated list otherwise entirely about enforcement evasion.
Anthropic Commercial Terms D.4 and Consumer Terms section 3 both carry a competing-product / train-competing-models restriction, both structured as a purpose test on accessing the Services.
DeepSeek Open Platform ToS 4.2 assigns Output rights to the developer and explicitly permits the developer to use Inputs and Outputs for training other models. It grants DeepSeek no reciprocal right and is silent on whether it trains on API inputs.

Nothing in the estate trains or tunes weights, so none of those clauses is engaged. Recorded here so the next reader does not redo the search.

Proposed scope

Decide whether the exclusion list (secrets, credentials, private overlays, customer data, unpublished personal information, raw operational payloads) should bind production agent lanes as well as evaluation transport, or whether production gets its own separately-reasoned clause.
If the former, generalize the clause's subject from "repository behavior evaluations" to the transport itself, keeping the graded-layer exclusion evaluation-specific.
Leave routes and provider selection unchanged. This is a documentation-scope question, not a routing one.

Process note

AGENTS.md is composed into every seat's own system prompt, and this paragraph is their own egress authorization. Per inbox#429, the harness guard correctly refuses agent writes to this clause and a human applies the edit. Expect that split again rather than routing around it.

Open question for a human: item 1 is the fork, and it is the only part an agent should not settle alone.

## The gap `AGENTS.md:29` (the public cloud evaluation approval clause, landed via inbox#429) ends with: > It covers evaluation transport only, never publication or any other external action. That scoping is deliberate and correct for what it was written to authorize. The gap is that it is now being cited for traffic it does not reach. **Sirens Echo Deep is production Discord traffic, not an evaluation.** Every summon composes the advocate role bundle and sends it to a hosted third-party provider. Verified in `deploy/agent-routes/service-routes.json`: route `sirens-echo/deepseek` resolves to `deepseek-v4-flash` on `deepseek-api`, with a fallback to `deepseek-ai/DeepSeek-V4-Pro-0813` on `baseten-api`. `deploy/agent-routes/deployment-targets.json` confirms both are hosted API targets with their own credentials, not local weights. So the standing written authorization for sending composed role bundles to a third-party provider covers the evaluation lane and stops there. The production lane is not prohibited by anything, it is simply not covered by the rule everyone reaches for. ## Why this is worth writing down The clause's exclusion list is the valuable part, and it is the part that does not currently reach production. The graded-layer exclusion exists because a board is an instrument later runs are compared against, so a provider that trains on critiques, evidence spans, and the taxonomy is handed the answer key. That reasoning is about measurement integrity rather than provider terms. Production has the sibling version of that risk and no written fence: the exclusions for secrets, credentials, private overlays, and unpublished personal information are exactly what a community agent's context could pick up at runtime, and the clause that names them does not apply to it. ## What this is not This is not a terms-of-service finding. Checked directly: * Anthropic AUP, "Do Not Abuse our Platform" - the training bullet has a purpose element ("to train an AI model") and sits in an enumerated list otherwise entirely about enforcement evasion. * Anthropic Commercial Terms D.4 and Consumer Terms section 3 both carry a competing-product / train-competing-models restriction, both structured as a purpose test on accessing the Services. * DeepSeek Open Platform ToS 4.2 assigns Output rights to the developer and explicitly permits the developer to use Inputs and Outputs for training other models. It grants DeepSeek no reciprocal right and is silent on whether it trains on API inputs. Nothing in the estate trains or tunes weights, so none of those clauses is engaged. Recorded here so the next reader does not redo the search. ## Proposed scope 1. Decide whether the exclusion list (secrets, credentials, private overlays, customer data, unpublished personal information, raw operational payloads) should bind production agent lanes as well as evaluation transport, or whether production gets its own separately-reasoned clause. 2. If the former, generalize the clause's subject from "repository behavior evaluations" to the transport itself, keeping the graded-layer exclusion evaluation-specific. 3. Leave routes and provider selection unchanged. This is a documentation-scope question, not a routing one. ## Process note `AGENTS.md` is composed into every seat's own system prompt, and this paragraph is their own egress authorization. Per inbox#429, the harness guard correctly refuses agent writes to this clause and a human applies the edit. Expect that split again rather than routing around it. Open question for a human: item 1 is the fork, and it is the only part an agent should not settle alone.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agentic-os#1429

No description provided.

Rows
Columns