What is a Toolchain?

By Jon Schipp · for security teams and AI teams alike

I've been thinking a lot about the words we use for our tools. We say "stack" for the tools we use, and that made sense when they sat side by side and each one did its own job, back when being ahead of the curve meant you had bi-directional API integrations between at least two tools in a stack of forty. If that's still you, you're behind what the technology can offer your organization, because a coding agent now sends a request through a model router that picks the appropriate model, traces record it, CI runs, and someone may or may not review the code before it ships, and that's still an oversimplification.

Each of those tools hands its work to another, and not only is the number of tools getting larger but they're changing more rapidly too. A stack can't describe that, because it tells you what you have and not necessarily how the work moves, so I've started saying "toolchain" when the context calls for it, since the word implies intention. The same is true on the security side, where a scanner finds a flaw, an agent prioritizes it, an owner fixes it, and a rescan checks the result, and I've written about it for cyber and for AI separately. This is the combined version, because the idea turns out to be the same one wearing two different outfits.

A stack is the tools you use. A toolchain is how they cooperate to solve a core problem.

Plan by job, implement by toolchain

A toolchain isn't something you plan around, because you plan by the job, whether that's remediating a known-exploited flaw or shipping a code change, and the toolchain is how you implement it. Teams that plan by stack find a gap, buy a point solution to fill it, and move on to the next gap without asking what ecosystem the new tool has to live in, which is a lot like a relay team that never practiced the handoff; every runner is fast, the baton still hits the track, and they'll finish the race but not nearly as well as they could have.

The word changes the questions you ask. You stop asking "do we have a tool for this?" and start asking "does this job make it from start to finish?", and answering that means knowing which tools play well with others, which ones add real value to the chain, and which jobs break when a vendor or a model ships a change.

The same chain, in two jobs

The easiest way to see it is to follow one piece of work through some real tools. In cyber the job is turning a finding into a verified fix, and in AI the job is turning a coding request into a tested change that you can trace back to the model that wrote it. Both use open-source tools, both include steps that belong to a human, and both are simplified on purpose.

Dashed boxes are the human steps, and I left them in deliberately because they're usually the handoffs that decide whether the chain works.

On the cyber side, nuclei writes what it finds to a JSON file and DefectDojo imports it and removes the duplicates, and then it gets interesting because pushing findings into a tracker depends on your plan and your tool, so assigning the fix and doing the fix are yours. Once the fix is deployed nuclei scans the same targets again, and DefectDojo reimports the new report into the same test and closes whatever is no longer there.

On the AI side, OpenCode sends your prompt and the files it read to LiteLLM, which you've added as a custom provider, and LiteLLM routes it to whichever model its config names, in this case one running locally in Ollama. Langfuse sits alongside the whole thing collecting a trace of every call so you can see what was asked and what came back, and you review the change and run your tests before you accept any of it.

Five great tools in your stack can create fifty chains, one for each problem they solve together.

Four things that make it a toolchain

A pile of tools doesn't become a toolchain just because someone drew arrows between them, and these are the four tests I use before I call something one.

• It's what you operationalized. A scanner that's deployed but sits idle, or a model you pulled that nothing calls, isn't part of it.
• It's meaningfully connected. The tools feed each other to solve a real problem, and a chain that isn't designed around your most pressing problem might as well be a stack.
• It moves. Work flows through it under the direction of a team, and it needs care and feeding to keep up with a changing environment.
• It's as strong as its weakest link. Service degradations, unplanned tool updates, and low-quality data can all break the chain.

What a toolchain isn't

It isn't just a CI/CD pipeline or an MLOps pipeline, although both are good examples, in the same way an assembly line is one kind of factory. The same thinking applies to any job that crosses tools and teams, whether that's a vulnerability, an incident, or a model getting retired. It also isn't a platform, because a platform can supply several links in a chain but most jobs still cross tools from other vendors.

Why yours won't sit still

The toolchain you built last year was built for last year's attacks, and the one you set up six months ago for AI was built around six-month-old agent technology. Attackers change their techniques every month, new models and agents ship every week, and a chain that never changes slowly loses ground even when nothing in it technically breaks.

The breakage, when it comes, travels along the handoffs. If nuclei changes its JSON output, DefectDojo's importer is the next thing to notice, and if Ollama renames a model tag, LiteLLM's config is the next thing to fail. The same pattern shows up in both worlds, which is why I think of the upside and the risk as one thing, and why every release, which in AI means every month or less, deserves one question: does it make your chain stronger or weaker?

Conclusion

In a toolchain, one tool's change is everyone's change.

That sentence is the whole argument, and it asks a lot of organizations, because you have to be much more in tune with your tools, your ecosystem, and how both change. The useful question stops being which tools you own and becomes how your most important jobs move between them and who owns the result, and the teams that do well are the ones who see each change coming rather than finding it in an outage.

I'll be upfront that I run The Cyber Toolchain and AI Toolchain, which follow what roughly 1,100 cyber tools and 1,200 AI tools, models, and hardware ship every day, so I obviously have a point of view here. The examples above are simplified and I haven't tested every combination of products that could fill each role, but the shape of the problem holds up in every team I've watched deal with it.