threat_intelligence2328 wordsRead on Arc Codex

What are agentic workflows? A practical guide to building and securing them

What agentic workflows actually are An agentic workflow is a process where one or more AI agents plan, decide, and take actions toward a goal with limited human input. Instead of following a fixed script, the agents choose their next step at runtime based on context and results. An AI agent is a software system that uses an AI model to work toward a goal on its own. "Autonomous" means it can decide and act without a person approving each step. This matters because adoption is climbing fast. Gartner predicts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. That autonomy is powerful. It also expands what can go wrong, which is why security deserves as much attention as capability. We'll come back to that theme throughout this guide. Agentic workflows vs. traditional automation Traditional automation follows fixed, pre-written rules. An agentic workflow decides the next step at runtime based on context and the results it sees. DimensionTraditional automationAgentic workflowDecision-makingFixed rules written in advanceChosen at runtime by an AI modelAdaptabilityBreaks when inputs changeAdjusts to new contextInputsStructured and predictableUnstructured and open-endedFailure modeStops or throws an errorMay take an unexpected action Runtime decision-making is exactly what makes agentic workflows harder to govern. You cannot predict every action in advance, so guardrails matter more. Agentic workflows vs. AI agents These two terms are easy to mix up. An AI agent is the autonomous actor. An agentic workflow is the orchestrated process that may use one agent or many. A single-agent setup uses one agent to reach a goal. A multi-agent system splits the work across several agents that each handle a part and coordinate. Workflows are often more governable than a single free-roaming agent. Clear steps and handoffs give you natural places to add checks and approvals. How agentic workflows work: inside the agent harness Most agentic workflows share four building blocks. Together they form what engineers call an agent harness, the software scaffolding that turns a model into an agent. Understanding the parts shows both how the system works and where risk can enter. You do not need to build these from scratch to reason about them. The value is knowing what each part does, and what it can touch, before you hand an agent real work. - LLM (large language model) – the reasoning engine that interprets goals and plans steps. An LLM is an AI model trained to understand and generate text. - Tools and APIs – the connections an agent uses to act, such as querying a database or opening a pull request. - Memory – stored context that lets the agent recall earlier steps, facts, and results. - Orchestration layer – the coordinator that routes tasks, manages order, and decides when the work is done. Each block is also an entry point for risk. Tools can be misused, memory can be poisoned with bad data, and the LLM itself can be manipulated by crafted input. The perceive-decide-act loop Agentic workflows run in a loop. The agent perceives context and decides a next step. It acts through a tool, observes the result, and repeats until the goal is met or a stop condition triggers. This loop can run many actions before a human ever sees output. That is why stop conditions and guardrails belong in the design, not bolted on later. Common agentic workflow patterns A few standard patterns show up again and again. You can combine several within one workflow. - Planning – the agent breaks a big goal into smaller, ordered steps before acting. - Tool use – the agent calls external tools or APIs to gather data or make changes. - Reflection – the agent reviews its own output and revises it before moving on. - Multi-agent collaboration – several agents divide the work and share results toward one goal. Where teams use agentic workflows Agentic workflows already handle real work across many functions. The examples below are deliberately specific. - Customer support – an agent reads a ticket, checks account records, and drafts or sends a reply. - IT and operations – an agent triages an alert, runs a diagnostic script, and files a resolution. - Finance – an agent matches invoices to purchase orders and flags mismatches for review. - Software development – AI coding agents write code, run tests, and open pull requests. - Security – application security and product security teams use agents to triage findings, verify exploitability, and open fix pull requests. The last two cases are growing fastest and raise the hardest security questions. They are also where the rest of this guide focuses. The new attack surface: why autonomous agents change security Every action an agent can take is something new that can go wrong. When agents call APIs, run scripts, install packages, and modify records, the attack surface grows with each new capability. This is a governance problem, not only a coding one. Gartner also predicts that over 40% of agentic AI projects will be canceled by the end of 2027, driven by rising costs, unclear business value, and inadequate risk controls. Security experts are mapping these risks. The OWASP Top 10 for Agentic Applications (2026) comes from the Open Worldwide Application Security Project. It reflects input from more than 100 security researchers and practitioners, and it was reviewed by an expert review board including NIST, the European Commission, and the Alan Turing Institute. The list names threats like agent behavior hijacking, tool misuse, and identity and privilege abuse. The next three sections break down the biggest changes, with evidence and specific fixes. Agents take real actions (excessive agency) An agent that can only read data is low risk. An agent that can call APIs, run scripts, or change records can cause real damage if it is over-permissioned or manipulated. Security teams call this excessive agency. OWASP defines it as the vulnerability that lets damaging actions happen in response to unexpected, ambiguous, or manipulated LLM outputs. The fix starts with least privilege: give each agent only the permissions its task needs. We return to this in the checklist below. Agents write and run code Coding agents produce code fast, but speed is not the same as safety. In one controlled benchmark across 80 tasks and more than 100 LLMs, Veracode found that only 55% of AI-generated code was secure. The models also recommend outdated or vulnerable open source packages. In our research for the guide to AI and application security, we found that CWE-specific prompts cut LLM code vulnerabilities by more than half. CWE, the Common Weakness Enumeration, is a standard catalog of software weakness types. The practical control is to scan what the agent writes as it writes it. Endor Labs offers real-time AI code scanning that gives agents vulnerability context before code review, not after. Agents pull in open source dependencies To get work done, agents install open source packages. That pulls in code your team never chose and rarely reads. A transitive dependency is a package brought in indirectly by another package you installed. Two facts make this the dominant risk. Our research shows that 70% to 90% of a modern application's codebase is open source, and more than 95% of vulnerabilities stem from transitive dependencies. Malicious packages are rising too. Our open source malware research recorded 13.6x more malware advisories since January 2024. In the same research, 81% of teams say malicious open source is a top security priority for 2026. Fortunately, most of that risk is not exploitable. Reachability analysis checks whether a vulnerable function is actually called by your own code. Our research shows that 90.5% of open source vulnerabilities are unreachable. Full-stack reachability builds a call graph across code, dependencies, and containers to verify what is truly exploitable. Using function-level reachability analysis, teams cut roughly 92% of the noise on average and focus on the findings that matter. The full data behind the malware trend is in our open source malware research. For developers, that noise reduction is the point. Fewer findings means fewer interruptions and fewer alerts to research before a merge. Evidence-based remediation goes further by suggesting safe upgrade paths, so a fix is less likely to break the build. The flip side: agentic workflows that do security work So far this guide has treated agents as something to secure. The same pattern also works in your favor. Security is full of high-volume, judgment-heavy work that fits the perceive-decide-act loop well. A few examples show what that looks like in practice. - Vulnerability triage – an agent enriches a new finding with reachability, exploit, and fix data, then routes it to the right owner or closes it as unreachable. - Remediation – an agent selects a safe upgrade path, checks whether the change breaks anything downstream, and opens a pull request with the fix. - Malware response – an agent cross-references a newly flagged package against your dependency graph and reports whether any application actually uses it. - Policy enforcement – an agent reviews AI-generated code against your security policies inline, before the code ever reaches review. The pattern matters more than the examples. Most security backlogs are long because every finding requires research before action: is it reachable, is there a fix, will the fix break the build? That research is exactly what agents automate well, as long as they work from evidence rather than guesses. Evidence is also what makes security agents efficient. In our benchmarks, agents running inside the Endor Labs security harness used 12x fewer tokens and completed tasks 19x faster than agents reasoning through the same security work on their own. An agent that gets reachability and fix data handed to it does not burn tokens rediscovering what the harness already knows. A security harness is the same scaffolding described earlier, purpose-built with security tools, context, and guardrails. This is the model behind agentic remediation at Endor Labs. Instead of handing developers a list of alerts, agents investigate each finding, verify exploitability with reachability analysis, and propose fixes backed by upgrade impact analysis. That evidence-first approach cuts remediation time by 6x, because a fix that arrives with proof it works is a fix that actually gets merged. The same trust rules apply in both directions, though. A security agent needs least privilege, logged actions, and human approval for consequential changes, just like any other agent. The checklist below covers both cases. How to secure an agentic workflow: a practical checklist Good security here helps developers move faster, not slower. Fewer false alarms and inline fixes mean fewer interruptions and fewer blocked pull requests. These controls are practical and available today. IBM's 2025 CEO study found that 61% of CEOs are actively adopting AI agents and preparing to implement them at scale, so the time to build guardrails is now. - Scope tool access to least privilege. Give each agent only the permissions its task needs, and nothing more. - Protect secrets and credentials. Store them in a secrets manager so agents can use them without leaking them. - Scan generated code early. Check AI-written code for vulnerabilities before it is merged or run. - Prioritize by reachability. Focus remediation on findings that are actually exploitable, not every alert. - Keep a human in the loop. Require approval for high-risk actions like deleting data or shipping to production. - Audit every action. Log what each agent does so you can review, trace, and roll back when needed. Endor Labs' point of view is that security should live inside the workflow rather than sit as a gate after it. Our approach to securing AI workflows puts these controls where agents already work. AURI, the security intelligence layer for agentic software development, applies this model. AURI for Developers adds security for AI coding agents with Agent Governance hooks that allow or deny each consequential action. What's next Agentic workflows are scaling fast, and security cuts both ways: agents need guardrails, and agents make good guards. The teams getting value from them treat security as built-in intelligence that keeps agents moving safely and puts them to work clearing the backlog. You do not have to start from scratch. AURI ships with pre-built agentic workflows for triage, remediation, and malware response, and you can build your own on the same security harness, with reachability, fix data, and governance included. Book a demo to see both in action. Frequently asked questions What is the difference between agentic and traditional workflows? Traditional workflows follow fixed rules written in advance. An agentic workflow uses an AI model to decide its next step at runtime based on context. What is the difference between an AI agent and an agentic workflow? An AI agent is the autonomous actor that plans and acts. An agentic workflow is the orchestrated process that coordinates one or many agents toward a goal. What are examples of agentic workflows? Common examples include support agents that resolve tickets and IT agents that triage alerts. Others include finance agents that reconcile invoices and AI coding agents that open pull requests. Can agentic workflows improve security? Yes. Agents can triage vulnerabilities, verify exploitability with reachability analysis, and open pull requests with tested fixes. Agents running inside a security harness use 12x fewer tokens and complete tasks 19x faster than agents working alone. The same governance rules apply: least privilege, logged actions, and human approval for high-risk changes. How do you secure an agentic workflow? Give agents least-privilege access, protect secrets, scan AI-generated code, use reachability to focus on exploitable risk, require human approval for high-risk actions, and log everything. What permissions should an AI agent have? An AI agent should have only the scoped permissions its current task requires. High-risk actions should be gated behind human approval, with every action logged for audit. What's next? When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help:

How it works

Once you click Generate, Ollama reads this article and crafts 5 comprehension questions. Your answers are graded against the article content β€” general knowledge won't be enough. Score 70+ to count toward your certificate.

Questions are cached β€” you'll always get the same 5 for this article.