A multi-step workflow is an agent run that unfolds through a sequence of plan, act, observe, and re-plan decisions. Each step can change the next one, which makes failures harder to diagnose from logs alone. Observability exposes the order of steps, the branching logic, and where execution drifted from the original goal.
Expanded Definition
A multi-step workflow is not just a long-running agent task. It is a sequence of dependent decisions where plan, act, observe, and re-plan stages can branch based on tool output, policy checks, or environmental changes. In NHI security, the key issue is that each step may use a different credential, token, or delegated permission, which makes identity state part of the workflow itself rather than a background concern.
Definitions vary across vendors when they describe a workflow as “agentic,” “orchestrated,” or “automated,” but the operational distinction is whether intermediate state can alter the next action. That matters because observability must capture not only the final result, but also the path taken, the permissions used, and the reason a branch was chosen. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces logging, monitoring, and governance as ongoing control functions, not one-time setup.
The most common misapplication is treating a multi-step workflow like a single API call, which occurs when teams log only the final output and omit step-level identity and decision context.
Examples and Use Cases
Implementing multi-step workflows rigorously often introduces traceability overhead, requiring organisations to weigh richer diagnostics against more complex logging, policy enforcement, and credential handling.
- A code-analysis agent reviews a repository, flags a dependency risk, then re-checks a package lock file before opening a remediation ticket.
- A customer-support agent searches a knowledge base, escalates to an internal tool, and then drafts a response after policy validation.
- A CI/CD helper inspects pipeline status, detects failed tests, and invokes a deployment rollback with a short-lived token.
- A compliance workflow fetches audit evidence from several systems, re-plans when one system denies access, and retries through an approved path.
- A security agent correlates alerts, enriches them with identity data, and changes containment steps depending on whether the signal is a false positive.
These patterns are especially visible in supply chain events, where a workflow that appears simple on paper can fan out into many tool calls and hidden trust decisions. The GitHub Action tj-actions Supply Chain Attack shows how execution paths inside automation can expose secrets when step boundaries are not tightly controlled. For identity-oriented implementation guidance, NHI Management Group recommends treating each branch as a distinct privilege event, not as a continuation of the same session.
Why It Matters in NHI Security
Multi-step workflows matter because every additional step expands the attack surface for secrets, delegated tokens, and policy drift. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot reliably reconstruct what an agent or automation did across a branching workflow. That gap becomes dangerous when a workflow re-plans after an error and silently inherits broader access than the original step required.
Workflow-level observability also helps distinguish a normal branch from malicious manipulation. If a token is reused across multiple steps, or if a tool call changes the next action without an approval boundary, investigators may miss the exact point where execution drifted. NHI controls therefore need to include step correlation, credential scoping, and replayable audit trails alongside standard monitoring. The same logic applies to secrets exposure in automation: when steps are not isolated, one leaked credential can compromise the entire chain.
Organisations typically encounter the operational impact only after an agent has made an unintended tool call, at which point multi-step workflow analysis becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AGENT-04 | Multi-step agent execution increases branching, tool use, and failure propagation risk. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Workflow steps often depend on credential scope and secret handling across execution paths. |
| NIST CSF 2.0 | DE.CM-8 | Continuous monitoring and logging are needed to reconstruct multi-step execution paths. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust requires each workflow step to be separately authorized and re-evaluated. |
| NIST AI RMF | MAP 1.3 | AI risk management depends on understanding workflow decomposition and failure points. |
Bind each workflow step to least-privilege credentials and review secret exposure per branch.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
