The project is pre-1.0. Only the latest minor version receives security fixes.

Please do not open a public GitHub issue for security problems.

Email the maintainers privately at cristoe4@gmail.com with:

1. A description of the issue and its impact.
2. Steps to reproduce (a minimal lab YAML + spec YAML is ideal).
3. Affected version / commit.
4. Any suggested mitigation.

We will acknowledge receipt within 5 business days and aim to provide a remediation plan within 30 days. Coordinated disclosure window: 90 days from acknowledgement, unless an active exploit is observed.

The current code surface is small and intentional:

• No network I/O. No HTTP, no sockets, no telemetry.
• No code execution from untrusted input. YAML is loaded via yaml.safe_load. There is no eval, exec, pickle, or subprocess.run(shell=True) in the core.
• No instrument or device drivers. The Executor port is declared but not used; nothing in this repo turns commands into physical actions.
• Trust boundary: YAML files on local disk → dataclasses. The loader rejects unknown keys (ConfigError) to fail loud on typos and tampering.

If you build adapters that talk to external systems (LLM providers, lab instruments, web APIs), the threat model expands. Document your adapter's security envelope explicitly; reference docs/EXECUTION_SAFETY.md (planned in v0.4) for the executor contract.

• DoS / resource-exhaustion via giant YAML files (mitigation: rely on yaml.safe_load's limits and OS file-size limits).
• Vulnerabilities in your own adapter code unless they exploit a flaw in the contract published by this framework.