What is the difference between a workflow that proposes action and one that can execute it?

How proposing workflows differ from executing workflows

A proposing workflow is advisory: it can gather evidence, correlate signals, draft a recommendation, or prepare a remediation plan, but it cannot change production state by itself. An executing workflow is operational: it can invoke the action, such as restarting a service, changing a record, revoking access, or deploying a fix. The practical difference is authority, not just output.

That difference matters because a proposal can be reviewed, amended, or rejected before impact occurs, while execution turns the workflow into a control that can directly affect availability, integrity, and access. Once a workflow can act, you must treat it like any other privileged automation path and define where approval, logging, rollback, and exception handling live.

The same pattern shows up in systems like GitHub and GitHub Actions Security Guide, where a workflow may only propose changes until permissions, token scope, and runner trust are explicitly set to allow it to execute safely. The decisive question is whether the workflow is only generating intent or is also being trusted to carry out the intent.

What changes when the workflow can actually execute

Execution expands the blast radius. A proposing workflow can still be wrong, but an executing workflow can be wrong in a way that creates outages, overwrites data, or propagates unsafe changes at machine speed. That is why the control burden rises from content review to state-change governance: who can trigger execution, what inputs are trusted, what conditions must be met, and how the action is bounded.

In practice, execution requires stronger safeguards around approval gates, least privilege, and recovery. If the workflow can touch production systems, its credentials, service account, or token must be constrained to the smallest viable action set, and its behavior must be observable enough to reconstruct what it changed. Without those controls, the workflow becomes an unattended operator rather than a recommendation engine.

For identity and access design, the important distinction is whether the workflow is merely producing a recommendation or is being granted delegated authority to act. The latter creates a governance obligation to review entitlements, session scope, and revocation paths before the workflow is allowed to move from draft to action.

How to tell whether a workflow should be kept in proposal mode

If the workflow is intended to diagnose, summarize, or suggest, keep it in proposal mode until a human or policy engine approves the next step. If it is intended to remediate automatically, then treat the design as an execution system from the outset and document the exact preconditions under which action is permitted. The transition point should be explicit, not implied by implementation convenience.

A useful test is whether the workflow can cause an irreversible or externally visible change without another control making the decision first. If yes, you need approval criteria, scoped authority, auditable records, and a clear rollback path. If no, the workflow remains advisory, and the main risk is poor advice rather than uncontrolled change.

Risk and Threat Considerations

The risk is not just that an executing workflow might make a mistake, but that an attacker or misuse case can turn a trusted automation path into a high-speed change mechanism. Once a workflow can alter state, compromised credentials, poisoned inputs, or overbroad permissions can translate into production impact faster than a human review loop can react.

Failure mechanism: A proposal-to-execution boundary is missing, weak, or bypassed, so a workflow with delegated authority can change state based on untrusted input, excessive privilege, or an unsafe trigger condition.

Impact: The result can be unauthorized changes, outage, data corruption, access revocation errors, or accelerated incident spread because the workflow is both trusted and operationally capable.

Practitioner Guidance

What to verify: Confirm that the workflow’s permitted actions match its intended role. If it is supposed to propose, it should not have credentials or API scopes that can directly modify production systems; if it is supposed to execute, the approval and logging path must be explicit.

Decision rule: If the workflow can change state, treat it as privileged automation and require an approval gate, a bounded action scope, and an auditable execution record. If those are not in place, keep the workflow advisory only.

Common mistake: Teams often focus on whether the workflow output is accurate and overlook whether the workflow itself is allowed to act. A correct recommendation is still unsafe if the system can execute it without governance.

Practitioner takeaway: The key control question is not whether the workflow is intelligent, but whether it has authority. Once it can execute, the design must assume production impact and govern it like any other privileged change path.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?