Minimize and document ScriptBlock exemptions for AuthSessionBroker trust boundary

[blindzero]

Problem Statement

IdLE enforces a “data-only / no ScriptBlocks” rule for untrusted inputs (workflows, request data, provider maps). At the same time, AuthSessionBroker is a trusted extension point and may contain ScriptMethods/ScriptBlocks by design.

This creates two risks:

1. Boundary confusion: contributors may not clearly understand which objects are allowed to contain ScriptBlocks and why.
2. Drift risk: exemptions in ScriptBlock validation logic may become too broad over time and accidentally allow ScriptBlocks in untrusted objects.

Proposed Solution

Make ScriptBlock handling around AuthSessionBroker explicit, minimal, and test-protected:

1. Audit the current ScriptBlock validation logic and document:
   • Exactly where ScriptBlocks are rejected
   • Exactly what is exempted and why
2. Minimize ScriptBlock surface on the broker object where feasible:
   • Prefer not storing ScriptBlocks as properties (e.g., store a function/command name and resolve internally), or
   • Keep the current model but ensure the exemption logic is narrowly scoped to trusted broker instances.
3. Update security/architecture documentation to clearly define:
   • “Trusted extension objects may contain code (ScriptMethods/ScriptBlocks).”
   • “Untrusted inputs are data-only and must never contain ScriptBlocks.”
   • One canonical place for this rule (other docs must reference it).
4. Add tests that:
   • Confirm ScriptBlocks are rejected in untrusted inputs (regression protection)
   • Confirm the broker exemption is minimal (does not allow arbitrary ScriptBlocks elsewhere)

Alternatives Considered

• Keep everything as-is without explicit documentation/tests.
  • Rejected: encourages silent drift and confusion.
• Remove broker concept entirely.
  • Rejected: contradicts the host-agnostic auth/session orchestration design.

Impact

• Does this affect existing workflows?
  • Potentially none if behavior stays identical; may affect custom brokers if implementation changes.
• Any backward compatibility concerns?
  • If broker shape changes, document migration clearly. Prefer keeping external contract stable.

Acceptance Criteria:

• Documentation clearly defines trusted vs untrusted ScriptBlock rules (single source of truth).
• ScriptBlock validation exemptions are demonstrably minimal.
• Pester tests cover both rejection and allowed broker behavior.

Additional Context

Notes:

• This issue must stay within IdLE’s security guardrails: no “shortcuts” that weaken validation.
• Prefer the simplest implementation that reduces exemption complexity.

Definition of Done:

• Code + tests + docs updated.
• No increase in allowed ScriptBlock surface for untrusted inputs.