Execution boundary when authority is delegated

[nayname]

Context

term-llm has a clear model for interactive use: the UI mediates between LLM suggestions and execution, the user confirms, and the right thing happens. The permission system (--read-dir, --write-dir, --shell-allow, approval prompts) reinforces this.

Modes like --auto-pick, --yolo, and loop serve a different purpose - they let users intentionally delegate execution authority to the LLM. For CI pipelines, overnight runs, sensitive operations or composing term-llm into larger systems, this raises a question: what ran, and why?

What I've been exploring

A pattern that makes execution decisions external and explicit:

1. Intent comes in
2. Execution plan is generated
3. Plan is validated against policy (with or without explicit caller approval)
4. Audit trail captures the full cycle: proposed → validated → executed

Core idea: Model proposes, infrastructure enforces.

Why sharing

term-llm already has most of the pieces (permissions, dry-run, directory constraints). An execution layer would unify them into a single, reliable representation - useful when you need to audit, debug, or compose term-llm into larger pipelines.

I've been prototyping this pattern separately. Happy to discuss if it's relevant to where term-llm is heading.

[SamSaffron]

sure happy to hear more ideas, sounds interesting but I need a concrete example or 2

[nayname]

Thanks for engaging.

Right now, safety for state-mutating backend operations usually requires sandboxing or constant human prompting. Without that, complex commands tend to be either risky or drifting, and require repeated user supervision and clarification:

• "Consolidate build folders, remove deprecated ones"
• “Rotate database credentials across all services”
• "Update DNS to point to new server"
• "Purge expired sessions/inactive users from database"
• "Sync config across servers".

These pretty regular tasks demand either continuous human oversight with domain knowledge or blind trust in the model’s reasoning.

What I'm proposing is an explicit execution plan that explains how a task should be run: generated before execution, set up by the user, enforced at runtime. The plan encodes user-specific operational knowledge - paths, procedures, constraints, configs - and serves as an external guiding source of truth for execution, not just a non-binding context. The LLM remains responsible for reasoning, while execution is strictly bound to the plan.

This allows complex backend tasks to run autonomously, while still being safe enough for unattended or composable use.

[nayname]

Hi, following up on prototyping the plan pattern I mentioned earlier.

The core is now working:

• Basic plan → LLM enhancement → validated execution plan
• Basic version of schema-driven system - plan generated based on codified structure with constraints, recovery paths, conditionals, etc.
• Several modes of execution - plan executed outside of LLM by external execution layer, or plan fed to LLM as context to reason about

Building here: nayname/openclaw-secure-stack#8

Still early, but the flow is: intent → plan → validate → execute. The plan captures operational knowledge (paths, configs, constraints) so the LLM reasons within bounds, not in a vacuum.

Would this kind of structure be useful for term-llm?