The Hacker News | Expert Insights

As organizations deploy AI coding agents across large monorepos and microservices environments, a fundamental problem emerges: the model may be capable of making the change, yet still lack the organizational context required to make the right change safely. A developer can ask an AI coding agent to deprecate an API field, update an authentication flow, or modify a service interface. The agent can inspect the code available on the developer's machine and search for references. What it may not know is that the field is consumed by four other services across separate repositories, that one of those services belongs to another team, or that the same field eventually carries sensitive data into a third party integration. This is not simply a context window problem. It is a code context problem: providing AI agents with accurate, current, organization wide evidence about how software actually behaves. One emerging approach is to generate that evidence directly from source code us...

AI coding agents are already inside engineering organizations. The problem security teams need to solve is not only that AI-generated code might be vulnerable. You already have ways to catch that: code review, CI, SAST, dependency scanning, and production monitoring. The real problem is that tools such as Claude Code, OpenAI Codex, Claude Cowork, and GitHub Copilot are becoming extensible agent runtimes. Skills, plugins, hooks, repository instructions, and MCP servers can influence what the agent reads, which tools it selects, what commands it runs, and where enterprise data is sent. Most AI governance programs stop at approving the application. Very few can tell you everything that has been installed inside it. That is the supply-chain gap. What changed: Third-party components are no longer participating only at build or deploy. They are participating in the agent’s decision loop. From coding assistant to agent runtime The first generation of coding assistants mainly...

In eleven days, on September 11, manufacturers of products with digital elements sold into the European Union have to tell a regulator within 24 hours of learning that a vulnerability in one of their products is being actively exploited, with a fuller account due at 72 hours. I have a decent idea what the next eleven days look like inside most of those companies, having spent close to thirty years watching software organizations get ready for a date on a calendar. There will be a spreadsheet of products and owners that somebody builds over a weekend, a notification template that goes to legal for review, probably a consultant on a two-week engagement. It will mostly work. By September 10, the majority of them will be able to file inside 24 hours, and they will be right to feel relieved about it, because filing on time is exactly what the regulation asks, and it is not a trivial thing to arrange. What I would gently point out is that almost none of them will come out of the exercise ...

Cybersecurity teams have no shortage of threat data: New vulnerabilities are disclosed, malware is discovered, attack campaigns are analyzed, and manufacturers, CERTs, and security agencies continuously publish indicators of compromise (IoCs), security advisories, and other technical information. For operators of critical infrastructure, however, collecting this information is not even the most challenging part. Security teams still need to determine whether a threat is relevant to their environment, which assets may be affected, and what the observed activity actually means in the context of an operational network. In the energy sector, that requires knowledge extending beyond enterprise security and into the protocols, equipment, and processes that keep power systems operating. A suspicious packet in an office network is one thing. Understanding whether communication between an engineering workstation and a protection device using IEC 61850 represents expected maintenance activi...

Many AI systems depend on input signals that teams cannot fully inspect or explain. These opaque sources reduce visibility into the data paths that influence model behavior. Engineers lose provenance records, limiting the diagnosis of abnormal outputs. This complicates the work of security teams that need clear records of what influenced a model at any point in time. Verifiable search data offers a stable alternative. It gives teams an input they can examine, store, and reproduce in controlled conditions. Engineers can compare model behavior against information that was publicly accessible at the time a result was produced, rather than depend on hidden internal signals. This article outlines why verifiable search data gives AI and security teams the clarity required to maintain operational control. Why Traceability Matters in AI Systems Traceability lets teams follow an input from its origin through each processing step. When every stage can be inspected, engineers can review...

Artificial intelligence is everywhere now. From automated code completion to autonomous infrastructure management, AI tools and AI agents help DevOps speed up deployment cycles and change how development teams operate in general. At the same time, this rapid adoption of AI has created a reality that is hard for security teams to ignore: as with the growth of AI capability within the software development life cycle, the attack surface also grows. In 2025, there were 68 AI-related incidents recorded across major DevOps platforms according to the 2026 DevOps Threats Unwrapped Report . In the first half of 2026, the number of AI-related incidents visibly grew — research from GitProtect Lab tracked 84 AI-related incidents in six months alone. Thus, comparing the first half of 2026 to the same period in 2025 shows that AI-related incidents in development environments have nearly tripled. What do DevOps and DevSecOps say about AI incidents in general? According to GitProtect Lab ’s surve...