Free text execution breaks determinism. The agent may skip steps, process them out of order, extract the wrong arguments, or select the wrong tools from context. That makes the workflow unreliable and difficult to trust at scale. A structured schema turns the plan into discrete micro tasks that the system can carry out consistently.
Why Free Text Runbooks Fail as an Execution Contract
Free text is fine for human interpretation, but it is a weak contract for an executing system. Once an AI agent is asked to turn narrative instructions into action, ambiguity moves from being a readability problem to an execution problem: step boundaries blur, conditions are implicit, and the system has to infer sequencing, parameters, and tool selection from prose. That makes the workflow harder to verify, harder to audit, and much more likely to behave differently from one run to the next.
What breaks first is predictability. A structured schema makes each task explicit, so the system can validate inputs, preserve order, and stop when a precondition is missing. Without that structure, even a competent model may produce locally plausible actions that do not match the intended procedure. For teams building automations, the issue is not whether the model understands the runbook in a broad sense; it is whether the runbook can be executed consistently under operational pressure. The OWASP Non-Human Identity Top 10 is relevant here because execution reliability quickly becomes an identity and authorization problem when tools are invoked on behalf of systems rather than people.
In practice, many teams discover the weakness only after an agent has already completed the wrong action with plausible confidence.
How Structured Schemas Restore Determinism
A structured schema converts a runbook from narrative guidance into machine-readable intent. Instead of asking an agent to infer what a paragraph means, the schema defines discrete fields such as task name, required inputs, allowed tool, preconditions, dependencies, and expected output. That reduces the model’s freedom at the point where freedom is most dangerous: during execution. The result is not just cleaner parsing, but a tighter control over ordering, parameter handling, and exception handling.
This matters because free text tends to collapse several different decisions into one sentence. A single instruction can contain the action, the target system, the fallback path, and the approval condition, all of which may need different treatment. When the structure is explicit, the system can treat each as a separate micro task. That enables validation before execution, clearer logging after execution, and more reliable replay or review when something fails.
- Separate the objective from the step, so the agent does not have to infer both at once.
- Represent dependencies explicitly, so the system cannot advance before prerequisites are satisfied.
- Constrain tools and arguments, so the model is not choosing from an open-ended context window.
- Emit machine-parseable outputs, so downstream automation can confirm completion instead of guessing intent.
Structured execution also improves governance. It creates a stable place to attach approvals, policy checks, and exception handling rules, which is much harder when the instruction is buried in prose. If the schema is missing, inconsistent, or too loose, the system falls back to interpretation and the original runbook becomes a suggestion rather than an executable plan.
Where the Pattern Breaks Down and What Teams Miss
Tighter structure often increases authoring overhead, requiring teams to balance execution reliability against the cost of maintaining a more formal runbook format.
The main edge case is mixed-use documentation. Human operators often want narrative context, troubleshooting notes, and escalation guidance in the same document that an agent must execute. That is workable only if the executable portion is clearly separated from explanatory text; otherwise the model may treat commentary as instruction. Another common exception is conditional logic. Free text can describe nuanced judgement, but if the condition determines whether a dangerous action is taken, it usually belongs in an explicit field rather than in a paragraph that must be interpreted correctly under time pressure.
There is also a governance trade-off. A schema can make execution safer, but it can also create false confidence if the fields are too loosely defined or if the team assumes that parsing equals correctness. A structured runbook still needs validation of inputs, authorization to act, and a way to reject malformed or incomplete tasks. The strongest pattern is to keep narrative guidance for humans and reserve structured fields for what the agent must actually do. Teams that blur those layers tend to discover the problem when the agent executes a syntactically valid but operationally wrong workflow.
Risk and Threat Considerations
Free-text execution creates a control gap because the system must infer intent, ordering, and tool use from unstructured language. That increases the chance of unsafe actions, silent drift from the approved procedure, and misuse of access when the agent is allowed to operate tools or systems directly.
Failure mechanism: Ambiguous instructions can be parsed differently across runs, and an attacker or careless author can exploit that ambiguity by inserting misleading context, hidden assumptions, or malformed steps that steer the agent toward the wrong tool, wrong parameter, or wrong sequence. Where tool use is delegated, the agent may also over-apply trust to instructions that were never meant to be executable.
Impact: The result can be incorrect system changes, broken approvals, incomplete remediation, or unauthorized use of privileged actions. At scale, the larger risk is not a single bad run, but a repeatable execution path that is difficult to detect, harder to audit, and easier to abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Runbook-executed agents create machine-action ownership and execution scope issues. |
| NHI-02 — Secrets and Credential Management | Free-text execution can expose or misuse credentials embedded in steps. | |
| Recommendation — Inventory the executing identities and restrict each runbook to the minimum permitted scope. Separate secrets from runbook text and rotate any exposed credentials immediately. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Structured execution is needed to prevent tool misuse and unauthorized actions. |
| Recommendation — Enforce explicit authorisation checks before any agent action changes state. | ||
| CIS Controls v8 | 6.3 — Account Monitoring and Control | Execution drift is easier to catch when tool use and account activity are tightly logged. |
| Recommendation — Log agent actions with enough detail to reconstruct the exact instruction-to-action path. | ||
| MITRE ATT&CK | T1204 — User Execution | Adversaries can exploit instruction ambiguity to steer execution toward unintended actions. |
| Recommendation — Hunt for prompts or runbooks that coerce users or agents into unsafe execution paths. | ||
Practitioner Guidance
What to prioritise: Separate narrative guidance from executable fields before expanding agent autonomy. If a runbook contains steps that can change state, access systems, or invoke tools, those steps need explicit structure and validation, not just clearer wording.
What to verify: Confirm that the schema captures the minimum execution contract the agent actually needs: task order, required inputs, allowed actions, and stop conditions. If any of those are still implied by prose, the workflow is still vulnerable to misinterpretation.
Common mistake: Treating a well-written paragraph as if it were a reliable control. Readability helps humans, but it does not remove execution ambiguity for a system that must decide what to do next.
Practitioner takeaway: If the runbook can change systems, the instruction format must be precise enough to validate before execution, not just understandable after the fact.
Related resources from NHI Mgmt Group
- What breaks when legacy systems are exposed to agents without schema governance?
- What breaks when an AI assistant is connected to enterprise email and cloud systems without tight scope limits?
- What breaks when reactive AI systems can take identity actions without approval?
- What breaks when AI systems can access data without context-aware controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
