Security Leaders Prepare For Improvised Attacks By Changing Their Own Operating Speed

Security teams typically write their detection rules from attacks that have already happened, a method that works when attackers repeat themselves. In July, an OpenAI agent cheating on an internal test reached Hugging Face's production systems by chaining a zero-day with credentials exposed on other services, inventing how it moved as it went along. A rule covering one particular path is easy to add, but covering a path that gets assembled fresh depends on how fast a company can change its own practice between one incident and the next.

Shekhar Kachole is Founder and CTO of Turiya Digital, a technology advisory firm he started in 2025 to advise boards and executive teams on AI strategy, governance, and cybersecurity. He also serves as a non-executive director and takes fractional CTO and Chief AI Officer roles with AI-native startups. Kachole spent thirty years in engineering leadership across payments, telecom, and financial services before founding it, most recently as chief technology officer of Worldline's online payments platform.

"In the old era, there used to be enough lag between development of the technology and the tooling to create a process that people could follow. With AI, the pace of the development has increased so much that you need to completely change the mindset," says Kachole. The three pillars he works from are people, technology, and process. Kachole sees those three arriving out of order now, with tooling landing before there's a process to govern it or staff trained to run it.

Preparing for what comes next

Most security teams can handle the threats in front of them, though coverage of known attack techniques remains incomplete even there. Kachole counts that as the easier part of the job. "Most of the teams are prepared to take care of all the threats happening at the moment," he says. "What is really missing is they are not prepared for what happens next, especially when quantum computing is going to take over and the probability of the threats is going to go exponentially higher."

Kachole sees most companies starting from somebody else's breach, and the response often closes without reaching the root cause. Each new incident adds a guardrail against the specific thing that happened, and the exercise repeats when the next one surfaces. "The current approach of most of the companies is, we know something has happened, there are some incidents that happened with some other companies," he explains. "Let's learn from that and try to have guardrails to protect ourselves from that. They are not prepared to really think about how the cyber attackers are moving forward. They are moving forward at a much higher pace than the companies are able to."

Companies fall behind at different points, and Kachole singles out the ones carrying compliance requirements. A regulated business can sign a contract for new tooling well ahead of the approvals and training that have to follow it. "Many of the companies are not able to do that," he notes. "They are either able to bring in the tools very fast, but then their people are not ready. Especially in the companies where you have compliance and regulatory requirements, which slows you down, you're not able to adapt at the pace when the tools are being deployed."

Security inside the build

Agentic development is recent enough that most companies have no settled practice for building it securely. A development environment is where Kachole wants the security checks run, and he applies the same rule to performance. He counts both as part of what makes code finished, alongside a feature's main purpose. "Try to do things first in your development environments, and ensure that your security is not done at the production environment," he advises. "If you are really looking at DevSecOps, ensure that you are shifting left, meaning all your security practices should be applied as early as possible in your development time itself. When I'm writing a code, it's not just production ready, it is also security compliant, it is also performance compliant."

Kachole's test is whether those checks reach the teams writing code. He has led the same change inside engineering organizations before, and the hard part was getting developers to count security as their own work. "Get those earlier on and have your development copilots, whatever tools that you use, get your prompt engineering to really ensure that you have enough guardrails to already create the code which is going to be compliant," he notes. "The mindset needs to be at the developers level. If you have a security department acting separately, trying to bring in new practices that aren't applied in your downstream environments, then it's not going to work out."

Bringing the outside in

Kachole splits this work into two directions, starting with the one most companies already run. "There should be one inward focus where you are looking at everything happening internally, from the architectural practices to your security practices to your development practices," he says. "Just look at how things need to be developed from a holistic point of view on the core purpose of your business."

The second direction points outside the company walls. "The outward focus is what is happening in the industry," Kachole explains. "Some companies are propagating the ideas on what are the best practices, and there are many forums where they talk about it. Encourage your staff to start engaging themselves and bring that industry information from outward to in, and these days it is really important to have both. If you are only internally focused and you don't care what other companies are doing, then an OpenAI Hugging Face situation happens."

Tool selection is where Kachole puts the most weight, and he'd start with the duplicates left behind by acquisitions. A business that grew by buying others tends to run two tools for the same job in different environments, and extending the stronger license costs less than a new deployment. "The most critical part here is your tool selections," he notes. "You might have to relook at the current tools you're using for your security and threat mapping. I have been using X as one of the tools at the moment. When I see what's happening in the industry, maybe it is Y, and I need to bring that in, because they have all the capability to look at the outward threats and bring those practices into the tooling they provide."

Hiring for prediction

Asked where the money should go, Kachole puts people ahead of tooling, and he moves the retraining interval from every two years to every three or six months. "Less than ten years ago, we were dealing with all the security aspects manually," he says. "It is the human capital that has really adapted themselves to the level that we are now. I would invest much more on people, to make them aware, train them, get them really vigilant on what's happening around."

Security org charts are already being redrawn around outcomes. Kachole wants a company to finish acting on what it already knows before it starts hiring to predict. "When it comes to threat intelligence becoming predictive, especially in the era of AI, you really need to start thinking about how to build an AI-savvy team that can predict what is going to happen," he notes. "I would rather start bringing in real AI experts inside the team. The mindset of these new AI engineers is entirely different than a traditional developer or a traditional engineer."

Acting on a prediction is where Kachole pushes agent autonomy furthest, all the way to production. He keeps a review step in the loop, and leaves open whether a person or another system does the signing off. "I would really start ensuring that not only my people, but my systems are also able to predict what could happen and take necessary actions," he concludes. "My agentic AI implementation would also be flexible enough. The agent itself is able to detect that something could go wrong, go change the code, get through whatever your review process is, manual or automatic, and deploy that code on production quickly."