Mon, 04/05/2026 - 16:04
When it comes to securing enterprise supply chains, now heavily infused with AI applications and agents, a software bill of materials (SBOM) no longer provides a complete inventory of all the components in the environment. Enter AI-BOMs. While a traditional SBOM includes all of the software packages and dependencies in the organization, an AI-BOM aims to cover the gaps introduced by AI assets by providing visibility across all of the models, datasets, SDK libraries, MCP servers, ML frameworks, agents, agentic skills, prompts, and other AI tools - plus how these AI components interact with each other and connect to workflows. "Imagine if AI is a birthday cake in the middle of this room, but you don't know how it got there," Ian Swanson, VP of AI security at Palo Alto Networks said in an interview with The Register. "You don't know the recipe, you don't know the ingredients, you don't know the baker. Would you eat a slice of that cake?" A lot of organizations are eating the cake anyway. In addition to the company-sanctioned models and AI used in the tech stack, there's also the problem of "shadow AI" - we used to call this "shadow IT" - and these unsanctioned tools also need to be brought out of the shadows so they can be accounted for. This includes all the vibe coding platforms and agents that individual employees spin up, along with any external chatbots they interact with on work computers and potentially input sensitive corporate data into. To secure all of these AI ingredients baked into the cake, companies first need to know what they are, what they connect to, and how they are being used. "In general, organizations that are trying to wrap their head around AI security," Amy Chang, Cisco's head of AI threat intelligence and security research told The Register. "They want a way to be able to identify what AI assets exist in their environment. A tool like the AI bill of materials is one of those first places that you can start to get a better understanding of what exists." Up next: model provenance Cisco previously open sourced its AI-BOM, making it free for anyone to scan codebases, container images, and cloud environments to produce this bill of materials. On Friday, it also made available its Model Provenance Kit as an open source tool to track model provenance. In a blog announcing the new repository, Chang and other AI researchers describe it as a DNA test for AI models, and it determines provenance using one of two modes: compare or scan. Compare mode takes any two models and shows their similarity across metadata, tokenizer structure, weight-level signals along with a final composite score. Scam mode starts with a single model and matches it against a database to determine the closest lineage candidates - and to help with this mode, Cisco also released a model fingerprint database covering about 150 base models across more than 45 families and over 20 publishers. Chang told us that the new AI tool performs two gate checks. "First, at the metadata level, it compares the information from the base model with the fine-tuned version of the model to delineate some sort of provenance-linked relationship - like this was derived from Meta Llama 4, or derived from Alibaba Qwen3," she said. "Then, what we do is look at weight-based signifiers. So now we're providing a sort of verifiable, repeatable and provable way to attest that the models that you use and deploy, that are customer facing, that are ingesting all this data, are truly the models that that you're supposed to be using, or that that are within the confines of your risk tolerance." During our interview, Chang pointed to Cursor's Composer 2, which is partly built on Kimi 2.5, a Chinese open source model. "They were very quick to admit that, yes, we used the Chinese model to build this," she said. "But that could have regulatory or compliance risk." Case in point: The European Union's AI Act mandates organizations document training data, characteristics of training methodology, and risk assessments for "high-risk systems." Google's Wiz, in its AI-BOMs, also accounts for all of the tools in the developers' workstation, such as a laptop or integrated development environment, that went into building the AI application. "Many people define visibility or BOMs by what's actually in the final artifact, but we also extend the definition of BOMs in general and AI-BOMs in particular to include the AI tools that went into building that application," Ziad Ghalleb, Wiz technical product marketing manager, told us. "And then another important aspect is the identities that are attached to these AI workloads, because all these agents or models, tools, etc., are tied to a specific identity inside your environment," Ghalleb added. "So you need to be looking at these non-human identities that are related to these systems. It's not just the resources. It's also the identities and the permission sets that are tied to them." All of this boils down to visibility and security. "If you don't have visibility of these workloads, then you can't really understand what it is to protect," Swanson said. Protection against poisonings Enterprises aren't the only ones madly rushing to incorporate AI tools into their workloads and processes, as everyone who reads The Reg likely knows. Criminals are also using these same tools to move faster and make their attacks more efficient. As Sherrod DeGrippo, Microsoft's GM of global threat intelligence, told The Register in a previous interview: This includes tasks such as performing reconnaissance on compromised computers, and standing up and managing attack infrastructure. "Agentic, automated reconnaissance against systems is something that is worth taking a look at," DeGrippo said. "Go find out about XYZ, and come back to me with everything you've seen. Go scan the net blocks owned by this particular entity." According to Swanson, this is also a case where having an AI-BOM can help defenders respond faster. He says he can't name the company, but in one incident that Palo Alto Networks responded to, a criminal group used AI to scout out the victim organization and locate exposed endpoints. "One of the things that they did is get access to system prompts, the instructions to an AI workload that tells it what it can do, and what it can't do," Swanson said. And once the attacker gained access to the company's internal AI's system prompts, they modified them to force the AI to do things that it shouldn't - like steal data, and send it to an external email account. An AI-BOM would provide an understanding of the AI system's configurations and dependencies at a specific state in time - and also indicate any changes. "If you had understanding of state and understanding of state changes, then you would be able to go back to an AI bill of materials and say: 'What system prompt was used within the ingredients to create the AI application?' And then see it's changed from a prior state to a new state. So we should probably check this and see if there's anything bad that's happening here," Swanson said. "And in that case, you'd be able to catch it." Other supply chain attacks such as model and skills poisoning underscore the risks of not knowing what AI tools are in an IT environment. "Skills that people use in coordination with a lot of these coding assistants are pretty easy to tamper with, and so it's important to be able to scan them to make sure that somebody is not manipulating the capabilities," Swanson said. If a skill is supposed to provide a weather forecast, it shouldn't also steal credentials or leak secrets, he explained. "Understand state changes, constantly scan these artifacts for supply chain risks, and then at the point of runtime, when your AI application is live, also look at all communications to make sure that nothing bad is happening," Swanson said. AI-BOMs (and their software counterparts) can also help organizations quickly identify compromised open source code running on corporate systems. For example: the recent rash of poisoned npm and PyPI packages and earlier Shai-Hulud worm credential stealer attacks. Both of these campaigns targeted code commonly integrated into AI applications. Even in the absence of a CVE identifier, an AI-BOM lets users query "related libraries or packages," and then identify any malicious versions in their environment, Ghalleb said. "There's no CVE attached to them, but at least you know how to remove these to contain an evolving threat." ®
Mon, 04/05/2026 - 10:06
Your voter data could be used against you. A foreign intelligence service that wished to identify the family members of deployed military personnel could do so by cross-referencing public voter record data and social media posts. An employer who only wanted to hire employees with a specific political affiliation could do so by analyzing the primary ballot history of job applicants. An identity fraud ring seeking to open credit accounts in the names of other people could identify voters whose mail has been returned (via voter file suspense indicators) to take over those addresses using bogus change-of-address requests. These scenarios are possible thanks to the ability to link publicly available voter data to other data sets, according to Noah M. Kenney, founder of consultancy Digital 520. "I picked two different counties that kind of represented opposite ends of the spectrum," Kenney told The Register in a phone interview. "In Texas, they hide a lot of information and then North Carolina makes a lot of it public in terms of the specific records. And what I was looking at specifically is if you go and merge this data set or link this data set with other data sets, how likely are you to be able to re-identify a person?" More than 25 years ago, research by Latanya Sweeney, currently a professor at Harvard, demonstrated that most of the US population (87 percent) could be identified with just three anonymous data points – a five-digit ZIP code, gender, and date of birth. Those results can be improved when combined with other data sets. And recent research has shown that the process of identifying people from seemingly anonymous data points becomes even easier with AI tools. In a research paper titled "Public Voting Records: A Record, or an Attack Surface?", Kenney describes how he analyzed public records from Travis County, Texas, and Robeson County, North Carolina to show that the adversarial scenarios cited above are practical with public data. The Texas file provides fewer data points than the North Carolina file, but the research suggests redaction doesn't make much of a difference in the re-identification scenarios evaluated. Table 1 — Disclosure regime comparison With the less detailed Texas info, Kenney was able to use a Python script to link the voter records to other public records like the Federal Election Commission's individual-contribution data. "We pulled 500 contribution records for ZIP 78704 (an Austin-core ZIP including South Congress and Travis Heights neighborhoods) from the 2024 cycle via the FEC OpenAPI on May 1, 2026," he explains in his paper. "We de-duplicated to 181 unique contributors by exact match on (last name, first name, ZIP), and inner-joined to the voter file on the same key, no fuzzy matching, no nickname normalization, no suffix handling. Of the 181 contributors, 105 (58.01 percent) matched any voter record and 95 (52.49 percent) matched a uniquely-identifiable voter. Of the 105 matches, 74.3 percent had a non-trivial employer field in FEC." That 52 percent individual match rate for identifying individuals from voter rolls and FEC data, Kenney said, would be more like 90–95 percent using the kinds of tools commercial data brokers employ. The North Carolina voter dataset includes a phone number for the majority of voters. According to the paper, 88.53 percent of voters who have a phone number listed have a number that is unique within the county. As a result, external datasets containing phone numbers can be joined at a similar rate using this field as a key to narrow down and identify likely individuals. Among the report's other findings: Name and ZIP code uniquely identify 95.81 percent of Texas voters and 87.79 percent of North Carolina voters. Among Travis County voters who have voted in 20 or more elections, 98.4 percent have a turnout pattern that is unique to them, making that data point a fingerprint. Texas' redaction of date of birth as a privacy measure is undermined by the publication of the voter registration data, which allows 28 percent of voters to be uniquely identified when combined with ZIP and gender. The Travis County voter file currently exposes 320 deployed military families through the publication of APO/FPO codes for military mailings. There's currently no comprehensive federal privacy law. While many states have privacy rules, there's a lot of variation. "Even within a specific state, most of the counties are individually handling these public records requests, so they all handle them differently across the country," said Kenney. "Some of them, you can't get them. Some of them, you need an ID to get them. Some of them you have to go through a request process for public records or you have to pay for them. The two counties I used are both freely available. You can go and download zip files of them without even putting in an email address or your name from anywhere in the world." Kenney said that he believes that access controls represent a better answer than redacting certain data fields, pointing to his findings that show redaction doesn't necessarily protect against privacy harms. He recommends measures like rate limits on bulk file requests, identity verification, requiring state ID, maintaining audit logs of requests, and prohibiting commercial resale of these records – because they're often used by data brokers. Beyond specific fixes based on his findings – Texas should generalize voter registration dates to a year rather than a day and armed forces mailing codes should be excluded from voter rolls – Kenney argues that people should be allowed to opt out of inclusion in public data sets and that general data privacy protections would be helpful. Last week, House Republicans introduced the Secure Data Act in an effort to create federal privacy rules. But Kenney says that it's significantly weaker than a lot of state regulations and he doesn't expect it will pass. "The industry consensus is that the likelihood of it passing is extremely low, at least in its current form," he said. "This represents the third attempt to pass comprehensive data privacy in recent years, most recent being the American Data Privacy and Protection Act, which failed to pass." ®
Mon, 04/05/2026 - 03:35
Information security agencies from the nations of the Five Eyes security alliance have co-authored guidance on the use of agentic AI that warns the technology will likely misbehave and amplifies organizations’ existing frailties, and therefore recommend slow and careful adoption of the tech. The agencies delivered that position last Friday in a guide titled Careful adoption of agentic AI services [PDF] that opens with the observation that “Agentic artificial intelligence (AI) systems increasingly operate across critical infrastructure and defense sectors and support mission-critical capabilities,” making it “crucial for defenders to implement security controls to protect national security and critical infrastructure from agentic AI-specific risks.” The thrust of the document is that implementing agentic AI will require use of many components, tools, and external data sources, creating an “interconnected attack surface that malicious actors can exploit.” “Consequently, every individual component in an agentic AI system widens the attack surface, exposing the system to additional avenues of exploitation,” the document warns. To illustrate the risks agentic AI poses, the document offers the example of an AI agent empowered to install software patches that is thoughtlessly given broad write access permissions, with the following unpleasant results: Here’s another nasty agentic mess the document uses as a warning: An organization deploys agentic AI to autonomously manage procurement approvals and vendor communications, and gives the agent access to financial systems, email and contract repositories; This user only considers permissions for the agent when deploying it; Over time, other agents rely on the procurement agent’s outputs and implicitly trust its actions; A malicious actor compromises a low-risk tool integrated into the agent’s workflow and inherits the agent’s over-generous privileges; The attacker uses that privileged access to modify contracts and approve unauthorized payments, and evades detection by creating faked audit logs that don’t trip alerts. Australia’s Signals Directorate and Cyber Security Centre (ASD’s ACSC) contributed to the document, working with the USA’s Cybersecurity and Infrastructure Security Agency (CISA) and National Security Agency (NSA), the Canadian Centre for Cyber Security (Cyber Centre), the New Zealand National Cyber Security Centre (NCSC-NZ) and the United Kingdom National Cyber Security Centre (NCSC-UK). The document contains more scary stories, then lists 23 different risks and over 100 individual best practices to address them. Much of the advice targets developers who deploy AI, but the authors also urge vendors to ensure they test their wares thoroughly and ensure their products “fail-safe by default requiring agents to stop and escalate issues to human reviewers in uncertain scenarios.” The document also urges security practitioners and researchers to spend more time contemplating AI. “Threat intelligence for agentic AI systems is still evolving, which can introduce significant security gaps,” the document warns, because resources like the Open Web Application Security Project and MITRE ATLAS currently focus on LLMs. “As a result, some attack vectors unique to agentic AI may not be fully captured or addressed.” Given the huge to-do list for anyone creating agentic AI, or contemplating its use, the document argues for very cautious adoption. “Organisations should therefore approach adoption with security in mind, recognizing that increased autonomy amplifies the impact of design flaws, misconfigurations and incomplete oversight,” the document concludes. “Deploy agentic AI incrementally, beginning with clearly defined low-risk tasks and continuously assess it against evolving threat models.” “Strong governance, explicit accountability, rigorous monitoring and human oversight are not optional safeguards but essential prerequisites. Until security practices, evaluation methods and standards mature, organisations should assume that agentic AI systems may behave unexpectedly and plan deployments accordingly, prioritizing resilience, reversibility and risk containment over efficiency gains.” ®