Research: design inputs for the Immune-system lane

[George-RD]

Part of #182

Question

Return design inputs, not a survey, from: CaMeL / AgentDojo, FIDES, Progent, RTBAS, capability-derived tool catalogs, taint tracking.

Deliverables:

1. The static-vs-runtime enforcement split for a Rust kernel: what each system checks before inference vs during execution, and which side each of our three designs belongs on.
2. What the quarantine boundary returns: the type/shape crossing from untrusted content back into the planning context.
3. The branch-steering residual: what remains exploitable when control flow can branch on tainted data, and what each system does about it.

Findings land on a throwaway research/immune-system-design-inputs branch as a Markdown file, linked from this ticket. Feeds the three design tickets in this lane.

[George-RD]

Resolution. Findings on branch research/immune-system-design-inputs (commit 1f8c228), file .raw/research-immune-system-design-inputs-2026-08-20.md (350 lines, source-cited). Design inputs for the three lane tickets:

1. Static-vs-runtime split for a Rust kernel

• Capability-derived tool catalogs → pre-inference: projected statically from the grant before prompt formatting; the worker never receives schemas for ungranted tools (CaMeL, arXiv:2503.18813).
• Disclosure gating on external egress → runtime: mediated at gate() dispatch; recipient bindings validated, autonomous external egress denied (Progent reference monitor, arXiv:2504.11703; FIDES sink clearance, arXiv:2505.23643).
• Provenance labels with typed identity → hybrid: compile-time untrusted-content wrapper types + runtime label/lineage tracking in the ledger (CaMeL capability tags; FIDES DIFC labels).

2. What the quarantine boundary returns
CaMeL: schema instances or tagged AST variable references. FIDES: opaque refs (selective hiding) or (C,I)-labeled schema projections. Progent: monitor-evaluated observation strings. RTBAS: integrity/confidentiality-labeled messages plus redacted history. Implication for our gate: raw String never crosses into the planning context — an unforgeable selection-token handle or a typed, schema-decoded value does.

3. The branch-steering residual
Untrusted content can't inject instructions but can still steer the model among permitted actions: action suppression/DoS, forcing escalation branches, semantic styling. Defenses: CaMeL taints the program counter; FIDES lowers PC integrity inside tainted branches and blocks high-integrity tools there; RTBAS uses dependency screeners; Progent enforces transition preconditions. Our containment: kernel-owned declarative workflows bound branching; autonomous final send stays denied. The honest residual — within-grant choice steering — must be accepted and bounded by grant design, not eliminated.

AgentDojo numbers: CaMeL 77% utility (84% baseline) at near-0% ASR; FIDES 100% policy-violation prevention; Progent ASR 25.8%→4.2% (~98% utility); RTBAS 100% targeted-attack defense at 2% utility loss; in-band prompt defenses bypassed >90% by adaptive attacks.

[coderabbitai]

Coding Plan

Summary

Produce a single self-contained Markdown research document on the throwaway research/immune-system-design-inputs branch, structured around the three ticket deliverables.

Extract concrete design inputs (not a survey) from the six sources, and map each finding to an OpenSpine mechanism (compose_authority/TaskGrant, gate(), build_prompt_with_untrusted_context, InstructionSources, AuthorityClassId).

Name three working OpenSpine designs and place each on the static side, runtime side, or both, since the repository does not yet enumerate them.

Link the document from the ticket and hand off the named designs and open questions to the three later design tickets in the Immune-system lane.

Design Choices

Design Choice 1: What are "our three designs"?

Options Considered:

1. Wait for external enumeration before writing the split section.
2. Derive the three designs from OpenSpine's existing boundaries and the six sources, then state each design explicitly in the document as a named placeholder for the later design tickets.

Chosen Option: 2

Rationale: The document must produce actionable design inputs now. It must name the three candidate designs explicitly, grounded in OpenSpine's compose/gate/quarantine layers, and mark them as the working set for confirmation in #182.

Design Choice 2: What document format should the deliverable use?

Options Considered:

1. Extend the docs/threat-claims.md register format (| ID | Claim | Verification |).
2. Use a self-contained analytical Markdown structured around the three deliverables, with comparison tables per section.

Chosen Option: 2

Rationale: The threat-claims register requires real backing tests and is a permanent governance artifact. This is a throwaway research branch. A self-contained analytical document keyed to the three deliverables fits the intent and does not pollute the enforced register.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Prepare the research branch and document scaffold

This phase creates the branch and the document skeleton. It fixes terminology and the source list before any analysis. This prevents terminology drift and keeps each external system mapped to a single OpenSpine concept.

Task 1: Create the research branch and Markdown file

Set up the throwaway deliverable location.

• Create branch research/immune-system-design-inputs.
• Add a new Markdown file (for example docs/research/immune-system-design-inputs.md) as the single deliverable.
• Add a header that states the purpose: design inputs for the Immune-system lane, part of #182.
• Add three top-level sections that match the three deliverables exactly: static-vs-runtime split, quarantine boundary return, branch-steering residual.

Task 2: Fix terminology and source anchors

Bind each external system and each OpenSpine mechanism to one term.

• Add a short "Sources" subsection that lists the six inputs: CaMeL/AgentDojo, FIDES, Progent, RTBAS, capability-derived tool catalogs, taint tracking.
• Add a short "OpenSpine anchor" subsection that names the enforcement mechanisms the analysis will reference: compose_authority/TaskGrant (static), gate() (runtime), build_prompt_with_untrusted_context and InstructionSources (quarantine), AuthorityClassId and ActionId keying (control-flow), Plan::digest() (WYSIWYS binding).
• State the working set of "our three designs" as named placeholders for the later design tickets. Base each design on an OpenSpine boundary (for example: a taint-label design over InstructionSources, a quarantine-return-type design over the model-gateway boundary, and a tainted-branch policy design over gate()/route resolution).
• Reference existing threat claims that overlap (CLAIM-04, CLAIM-07, CLAIM-32) so the document extends rather than duplicates docs/threat-claims.md.

🤖 Prompt for AI agents

This phase sets up the research branch and the skeleton of the design-input
Markdown document. The goal is to fix terminology and structure before any
analysis is written.

- Create a branch named `research/immune-system-design-inputs`.
- Add a new Markdown file (for example
`docs/research/immune-system-design-inputs.md`) as the single deliverable for
this ticket.
- Add a header stating the document's purpose: design inputs for the
Immune-system lane, part of `#182`.
- Add three top-level sections matching the three deliverables exactly:
static-vs-runtime split, quarantine boundary return, branch-steering residual.
- Add a "Sources" subsection listing the six inputs: CaMeL/AgentDojo, FIDES,
Progent, RTBAS, capability-derived tool catalogs, taint tracking.
- Add an "OpenSpine anchor" subsection naming the enforcement mechanisms
referenced throughout the analysis: `compose_authority`/`TaskGrant` (static),
`gate()` (runtime), `build_prompt_with_untrusted_context` and
`InstructionSources` (quarantine), `AuthorityClassId` and `ActionId` keying
(control-flow), `Plan::digest()` (WYSIWYS binding).
- State the working set of "our three designs" explicitly as named placeholders
for the later design tickets. Base each design on an OpenSpine boundary: a
taint-label design over `InstructionSources`, a quarantine-return-type design
over the model-gateway boundary, and a tainted-branch policy design over
`gate()`/route resolution.
- Reference existing overlapping threat claims (CLAIM-04, CLAIM-07, CLAIM-32) so
the document extends rather than duplicates `docs/threat-claims.md`.

Phase 2: Write the three design-input sections

This phase produces the analytical content. Each section answers one deliverable question. Each section ends with concrete, actionable inputs for the design tickets, not a survey.

Task 1: Write the static-vs-runtime enforcement split

Map what each system checks before inference against what it checks during execution.

• For each of the six sources, state what it enforces statically (before inference/planning) and what it enforces at runtime (during tool execution).
• Present the mapping as a comparison table: source, static check, runtime check.
• Anchor each row to OpenSpine: static ≈ compose_authority minting a sealed TaskGrant; runtime ≈ gate() re-verifying the seal and re-checking policy per action.
• State the key finding: CaMeL derives control flow statically from the trusted query, then enforces capabilities at runtime; Progent and RTBAS enforce mostly at runtime with per-call policy; FIDES/taint tracking propagate labels at runtime; capability catalogs constrain the static tool surface.
• Place each of the three OpenSpine designs on the static side, the runtime side, or both, with a one-line rationale per design.

Task 2: Write the quarantine boundary return type/shape

Define what type crosses from untrusted content back into the planning context.

• Describe how each system returns untrusted content into the planning context: CaMeL returns symbolic values/opaque handles with dependency metadata; the dual-LLM pattern returns validated fields or opaque handles; FIDES/RTBAS return labeled values carrying integrity and confidentiality labels; taint tracking returns tainted values.
• Contrast this with OpenSpine's current return shape: a randomized-delimiter text block plus the structural InstructionSources.untrusted_data: Vec<String> split, and worker output as digest ArtifactRef cargo.
• State the design input: the quarantine boundary should return a typed, labeled value (integrity + confidentiality), not raw text, so downstream gating can reason about provenance. Note the gap between the current string-based split and a typed labeled return.
• Keep any type sketch as minimal illustrative pseudo-code, not full source.

Task 3: Write the branch-steering residual

State what remains exploitable when control flow branches on tainted data.

• State the residual risk clearly: if control flow branches on tainted data, the branch outcome itself leaks information and can steer subsequent permitted actions into a malicious overall workflow (the CaMeL "ROP-style" composition and one-bit exception side channel).
• For each system, state its mitigation: CaMeL STRICT mode propagates the branch-condition taint to all state-changing operations inside the branch; RTBAS pauses policy-violating calls for user confirmation and redacts irrelevant history to limit label creep; FIDES blocks unsafe-labeled tool calls; capability catalogs limit the reachable action set.
• Map to OpenSpine's current backstop: control flow keys on ActionId and AuthorityClassId, not payload semantics; route_ambiguity.rs escalates to the owner instead of content-branching; gate() is the real backstop when the model is fooled (skill/containment_tests.rs).
• State the design input: OpenSpine already avoids content-keyed authority branching, so the residual is mostly side-channel and workflow-composition risk. Recommend a tainted-branch policy for the third design, plus explicit result types over exceptions to close the one-bit channel.

🤖 Prompt for AI agents

This phase writes the analytical content of the document. Each of the three
sections must answer one deliverable question with concrete, actionable design
inputs, not a survey.

For the static-vs-runtime enforcement split section:
- For each of the six sources, state what it enforces statically (before
inference/planning) and what it enforces at runtime (during tool execution).
- Present the mapping as a comparison table with columns: source, static check,
runtime check.
- Anchor each row to OpenSpine: static maps to `compose_authority` minting a
sealed `TaskGrant`; runtime maps to `gate()` re-verifying the seal and
re-checking policy per action.
- State the key finding: CaMeL derives control flow statically from the trusted
query, then enforces capabilities at runtime; Progent and RTBAS enforce mostly
at runtime with per-call policy; FIDES and taint tracking propagate labels at
runtime; capability catalogs constrain the static tool surface.
- Place each of the three OpenSpine designs on the static side, the runtime
side, or both, with a one-line rationale per design.

For the quarantine boundary return type/shape section:
- Describe how each system returns untrusted content into the planning context:
CaMeL returns symbolic values/opaque handles with dependency metadata; the
dual-LLM pattern returns validated fields or opaque handles; FIDES/RTBAS return
labeled values carrying integrity and confidentiality labels; taint tracking
returns tainted values.
- Contrast this with OpenSpine's current return shape: a randomized-delimiter
text block plus the structural `InstructionSources.untrusted_data: Vec<String>`
split, and worker output as digest `ArtifactRef` cargo.
- State the design input: the quarantine boundary should return a typed, labeled
value (integrity plus confidentiality), not raw text, so downstream gating can
reason about provenance. Note the gap between the current string-based split and
a typed labeled return.
- Keep any type sketch as minimal illustrative pseudo-code, not full source.

For the branch-steering residual section:
- State the residual risk: if control flow branches on tainted data, the branch
outcome itself leaks information and can steer subsequent permitted actions into
a malicious overall workflow (the CaMeL "ROP-style" composition and one-bit
exception side channel).
- For each system, state its mitigation: CaMeL STRICT mode propagates the
branch-condition taint to all state-changing operations inside the branch; RTBAS
pauses policy-violating calls for user confirmation and redacts irrelevant
history to limit label creep; FIDES blocks unsafe-labeled tool calls; capability
catalogs limit the reachable action set.
- Map to OpenSpine's current backstop: control flow keys on `ActionId` and
`AuthorityClassId`, not payload semantics; `route_ambiguity.rs` escalates to the
owner instead of content-branching; `gate()` is the real backstop when the model
is fooled (`skill/containment_tests.rs`).
- State the design input: OpenSpine already avoids content-keyed authority
branching, so the residual is mostly side-channel and workflow-composition risk.
Recommend a tainted-branch policy for the third design, plus explicit result
types over exceptions to close the one-bit channel.

Phase 3: Ground the deliverable and link it

This phase connects the analysis to OpenSpine code and closes the loop with the ticket. It makes the document actionable for the three design tickets.

Task 1: Add the OpenSpine cross-reference map

Tie each external finding to a concrete OpenSpine file or mechanism.

• Add a closing subsection that maps each design input to the OpenSpine file it affects: compose.rs, gate.rs, model_gateway/mod.rs, schemas/src/model.rs, pipeline/route_ambiguity.rs.
• For each of the three designs, state the primary OpenSpine boundary it extends and the one open question the design ticket must resolve.
• Note explicitly which findings already hold in OpenSpine (so the design tickets do not re-litigate them) versus which are gaps.

Task 2: Link the deliverable and hand off to the design tickets

Close the research ticket loop.

• Commit the Markdown file on the research/immune-system-design-inputs branch.
• Add a link to the file from this ticket via gh issue comment, following the docs/agents/issue-tracker.md convention.
• If the Wayfinder map for #182 exists, append a context pointer to its "Decisions-so-far" and note the three named designs the document feeds.

🤖 Prompt for AI agents

This phase grounds the document in concrete OpenSpine code and closes the ticket
loop by linking the deliverable.

- Add a closing subsection mapping each design input to the OpenSpine file it
affects: `compose.rs`, `gate.rs`, `model_gateway/mod.rs`,
`schemas/src/model.rs`, `pipeline/route_ambiguity.rs`.
- For each of the three named designs, state the primary OpenSpine boundary it
extends and the one open question the corresponding design ticket must resolve.
- Note explicitly which findings already hold in OpenSpine, so the design
tickets do not re-litigate them, versus which findings represent gaps.
- Commit the Markdown file on the `research/immune-system-design-inputs` branch.
- Add a link to the file from the ticket via `gh issue comment`, following the
`docs/agents/issue-tracker.md` convention.
- If the Wayfinder map for `#182` exists, append a context pointer to its
"Decisions-so-far" section and note the three named designs the document feeds.

Research

OpenSpine enforces authority through two phases. A one-time static "compose" step mints an immutable, HMAC-sealed TaskGrant (crates/openspine-authority/src/compose.rs). A repeated runtime step, gate() (crates/openspine-gate/src/gate.rs), checks every effectful action against that grant.

Model inference (api/generate.rs) and plan execution (api/plan.rs) are gated actions. They are not an un-gated planning phase.

Untrusted external content enters the model context through a randomized-delimiter wrapper, build_prompt_with_untrusted_context (crates/openspine-kernel/src/model_gateway/mod.rs), and a structural schema split, InstructionSources { trusted, untrusted_data } (crates/openspine-schemas/src/model.rs).

Control-flow decisions (routing, standing rules, skill selection) key only on ActionId, task shape, and authority-equivalence classes. They never key on untrusted payload semantics.

The existing threat model lives in docs/threat-claims.md as an | ID | Claim | Verification | register. CLAIM-04, CLAIM-07, and CLAIM-32 are the closest analogs to this lane.

No ticket #182 or "Immune-system" artifact exists in the repository yet.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase sets up the research branch and the skeleton of the design-input
Markdown document. The goal is to fix terminology and structure before any
analysis is written.

- Create a branch named `research/immune-system-design-inputs`.
- Add a new Markdown file (for example
`docs/research/immune-system-design-inputs.md`) as the single deliverable for
this ticket.
- Add a header stating the document's purpose: design inputs for the
Immune-system lane, part of `#182`.
- Add three top-level sections matching the three deliverables exactly:
static-vs-runtime split, quarantine boundary return, branch-steering residual.
- Add a "Sources" subsection listing the six inputs: CaMeL/AgentDojo, FIDES,
Progent, RTBAS, capability-derived tool catalogs, taint tracking.
- Add an "OpenSpine anchor" subsection naming the enforcement mechanisms
referenced throughout the analysis: `compose_authority`/`TaskGrant` (static),
`gate()` (runtime), `build_prompt_with_untrusted_context` and
`InstructionSources` (quarantine), `AuthorityClassId` and `ActionId` keying
(control-flow), `Plan::digest()` (WYSIWYS binding).
- State the working set of "our three designs" explicitly as named placeholders
for the later design tickets. Base each design on an OpenSpine boundary: a
taint-label design over `InstructionSources`, a quarantine-return-type design
over the model-gateway boundary, and a tainted-branch policy design over
`gate()`/route resolution.
- Reference existing overlapping threat claims (CLAIM-04, CLAIM-07, CLAIM-32) so
the document extends rather than duplicates `docs/threat-claims.md`.
===============================================================================

Task: 2

This phase writes the analytical content of the document. Each of the three
sections must answer one deliverable question with concrete, actionable design
inputs, not a survey.

For the static-vs-runtime enforcement split section:
- For each of the six sources, state what it enforces statically (before
inference/planning) and what it enforces at runtime (during tool execution).
- Present the mapping as a comparison table with columns: source, static check,
runtime check.
- Anchor each row to OpenSpine: static maps to `compose_authority` minting a
sealed `TaskGrant`; runtime maps to `gate()` re-verifying the seal and
re-checking policy per action.
- State the key finding: CaMeL derives control flow statically from the trusted
query, then enforces capabilities at runtime; Progent and RTBAS enforce mostly
at runtime with per-call policy; FIDES and taint tracking propagate labels at
runtime; capability catalogs constrain the static tool surface.
- Place each of the three OpenSpine designs on the static side, the runtime
side, or both, with a one-line rationale per design.

For the quarantine boundary return type/shape section:
- Describe how each system returns untrusted content into the planning context:
CaMeL returns symbolic values/opaque handles with dependency metadata; the
dual-LLM pattern returns validated fields or opaque handles; FIDES/RTBAS return
labeled values carrying integrity and confidentiality labels; taint tracking
returns tainted values.
- Contrast this with OpenSpine's current return shape: a randomized-delimiter
text block plus the structural `InstructionSources.untrusted_data: Vec<String>`
split, and worker output as digest `ArtifactRef` cargo.
- State the design input: the quarantine boundary should return a typed, labeled
value (integrity plus confidentiality), not raw text, so downstream gating can
reason about provenance. Note the gap between the current string-based split and
a typed labeled return.
- Keep any type sketch as minimal illustrative pseudo-code, not full source.

For the branch-steering residual section:
- State the residual risk: if control flow branches on tainted data, the branch
outcome itself leaks information and can steer subsequent permitted actions into
a malicious overall workflow (the CaMeL "ROP-style" composition and one-bit
exception side channel).
- For each system, state its mitigation: CaMeL STRICT mode propagates the
branch-condition taint to all state-changing operations inside the branch; RTBAS
pauses policy-violating calls for user confirmation and redacts irrelevant
history to limit label creep; FIDES blocks unsafe-labeled tool calls; capability
catalogs limit the reachable action set.
- Map to OpenSpine's current backstop: control flow keys on `ActionId` and
`AuthorityClassId`, not payload semantics; `route_ambiguity.rs` escalates to the
owner instead of content-branching; `gate()` is the real backstop when the model
is fooled (`skill/containment_tests.rs`).
- State the design input: OpenSpine already avoids content-keyed authority
branching, so the residual is mostly side-channel and workflow-composition risk.
Recommend a tainted-branch policy for the third design, plus explicit result
types over exceptions to close the one-bit channel.
===============================================================================

Task: 3

This phase grounds the document in concrete OpenSpine code and closes the ticket
loop by linking the deliverable.

- Add a closing subsection mapping each design input to the OpenSpine file it
affects: `compose.rs`, `gate.rs`, `model_gateway/mod.rs`,
`schemas/src/model.rs`, `pipeline/route_ambiguity.rs`.
- For each of the three named designs, state the primary OpenSpine boundary it
extends and the one open question the corresponding design ticket must resolve.
- Note explicitly which findings already hold in OpenSpine, so the design
tickets do not re-litigate them, versus which findings represent gaps.
- Commit the Markdown file on the `research/immune-system-design-inputs` branch.
- Add a link to the file from the ticket via `gh issue comment`, following the
`docs/agents/issue-tracker.md` convention.
- If the Wayfinder map for `#182` exists, append a context pointer to its
"Decisions-so-far" section and note the three named designs the document feeds.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!