They should ask whether the system can choose actions, choose tools, and choose timing without human approval. If the answer is yes, the workflow is closer to an autonomous actor and needs a different governance model. If decisions are fixed in advance, it remains an automated NHI pattern.
Why This Matters for Security Teams
The distinction between automation and autonomy is not academic. It determines whether a workflow can be governed like a fixed pipeline or whether it must be treated as a goal-driven actor with live decision rights. Once an AI-connected workflow can choose actions, tools, or timing, static role mappings stop describing the real risk. That is where conventional IAM, change approval, and boundary-based controls begin to miss how the system actually behaves.
Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points in the same direction: the governance model must match the system’s decision latitude, not just its software label. NHIMG research on LLMjacking shows how quickly exposed credentials can be abused once attackers find an AI-connected workload. When the workflow is autonomous, secrets, tool access, and execution timing become part of the attack surface.
In practice, many security teams discover the workflow was autonomous only after an unexpected tool call, data pull, or side effect has already occurred.
How It Works in Practice
The practical test is whether the workflow has discretion. If every action is predefined, approved in advance, and executed in a fixed order, it is automation. If the system can select among tools, vary the sequence, or delay execution based on context, it is autonomy and should be governed as such. That means the identity model shifts from “who can log in” to “what this workload is allowed to do right now.”
For autonomous workflows, current best practice is evolving toward runtime authorisation, short-lived credentials, and workload identity. The goal is to issue permissions only when the agent has a specific task, then revoke them immediately after completion. That is closer to just-in-time control than to standing access. When possible, use cryptographic workload identity, such as OIDC-based tokens or SPIFFE/SPIRE-style identity, so policy decisions are tied to what the agent is, not merely to a reusable secret. This aligns well with the control logic described in CSA MAESTRO agentic AI threat modeling framework and the runtime risk focus in the NIST AI Risk Management Framework.
NHIMG’s OWASP NHI Top 10 and AI LLM hijack breach coverage both reinforce the same operational lesson: once a workflow can chain tools, a single compromised credential can become lateral movement. A workable decision process usually includes:
- Can the system choose tools without human approval?
- Can it change timing or sequence based on context?
- Does it receive standing secrets or task-scoped credentials?
- Are policies evaluated at request time, not just at deployment time?
These controls tend to break down in environments with shared service accounts, broad API scopes, or legacy orchestration that cannot evaluate policy per action.
Common Variations and Edge Cases
Tighter control often increases latency and operational overhead, so organisations have to balance safety against delivery speed. Not every AI-connected workflow should be reclassified as autonomy, and best practice is still evolving for borderline cases such as human-in-the-loop agents, approval-gated copilots, and batch jobs that only appear intelligent.
A useful rule is to look for decision latitude, not model sophistication. A simple script that calls an API on a fixed schedule is automation, even if it uses an LLM for text generation. A low-code agent that can browse, select tools, and retry actions until it reaches a goal is autonomy, even if it sits inside a familiar workflow platform. The same distinction matters for incident response, because autonomous systems may amplify a small secret leak into rapid tool chaining. That is consistent with NHIMG coverage of the AI LLM hijack breach and the broader risk patterns in the Ultimate Guide to NHIs.
Where guidance becomes less settled is around semi-autonomous copilots inside business processes. There is no universal standard for this yet, so organisations should classify them by the highest-risk decision they can make, then apply the stricter governance model when the boundary is unclear. That approach is most reliable when the environment already uses strong policy-as-code and short-lived secrets.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic systems need runtime guardrails when they can choose actions and tools. |
| CSA MAESTRO | MAESTRO models the threat surface of autonomous, tool-using AI workflows. | |
| NIST AI RMF | AI RMF frames governance around context, risk, and accountable oversight. |
Classify any workflow with tool choice or timing discretion as agentic and apply runtime controls.
