Security – Trust boundaries & secure defaults (no ScriptBlocks in data/handlers)

[blindzero]

Fixes #24

Summary

This PR documents and enforces clear trust boundaries for IdLE and introduces secure-by-default guards around host-provided extension points and data inputs.

The main goal is to make the engine deterministic and safer by ensuring that workflow/request data stays data-only, while extension points remain explicit and validated.

What changed

1. Trust boundaries documented (security model)

Added/updated documentation describing:

• Untrusted inputs (data-only): workflow configuration, lifecycle requests, step inputs
• Trusted extension points (code): host-provided StepRegistry, Providers, external EventSink
• The rationale for treating ScriptBlocks as code execution and therefore disallowing them in data paths

2. Secure defaults enforced in code
   ScriptBlocks are rejected in engine data paths:

• Invoke-IdlePlanObject now validates the plan and provider objects using Assert-IdleNoScriptBlock
• This prevents accidental or malicious code injection via “data” inputs

Step handler resolution is hardened:

• StepRegistry handlers must be function names (string) only
• ScriptBlock step handlers are explicitly rejected (secure default)
• Resolution verifies the referenced function exists before invocation

Execution path was aligned to the new contract:

• Step invocation is consistently done via & -Context ... -Step ...

3. Tests updated + extended
   Updated Pester tests to match the hardened behavior:

• Added/updated coverage for rejecting ScriptBlock step handlers
• Ensured test step handlers are visible to the engine by defining them as global functions (since handlers are referenced by name)
• Fixed a bug in Assert-IdleNoScriptBlock uncovered by the new guards:
• Correct property traversal uses .Value (not a non-existent .InputObject)

Breaking / behavioral changes

• StepRegistry no longer accepts ScriptBlock handlers.
• Hosts must register steps as function name strings, e.g.: 'IdLE.Step.SomeStep' = 'Invoke-IdleStepSomeStep'
• Plan/Providers/Workflow data must not contain ScriptBlocks.
• Any ScriptBlock found in these objects will throw with a path pointing to the offending location.
• These changes are intentional and align with “secure defaults” and the trust model described above.

Why this is the right default

ScriptBlocks in “data” effectively mean “execute code from configuration”.

Enforcing data-only inputs keeps IdLE portable, testable, and predictable across hosts.

Clear separation between data and code makes future security reviews and extension work much easier.

How to test

pwsh -NoProfile -File ./tools/import-idle.ps1
pwsh -NoProfile -File ./tools/run-tests.ps1
pwsh -NoProfile -File ./examples/run-demo.ps1

Notes for reviewers

Please focus review on:

• Validations and error messages (are they clear and actionable?)
• Contract clarity: data-only vs. host extension points
• Any remaining surface where ScriptBlocks could slip into execution paths