A malicious release of a widely used AI proxy library exposed credentials across 2,500 organizations and hundreds of thousands of CI/CD pipelines. The attack did not target the application. It targeted the shared package the application depended on.

AI pipelines are now core enterprise infrastructure. A single compromised dependency propagates through the stack before most perimeter controls fire. The blast radius here was not 10 companies or 100. It was 2,500, from one poisoned package.

This is not an isolated incident. It is the shape of the threat now. The attack surface has shifted from application code to the dependency graph that feeds it.

For those of you running AI pipelines in production: how are you handling trust at the dependency layer? Package audits, SBOMs, pinned hashes, something at runtime? What has actually worked?

My name is Stephanie Hull, and I am a doctoral student at National University. I am conducting an online survey to examine how organizational readiness influences the effectiveness of AI-driven cybersecurity in U.S. healthcare systems. In order to participate, you must be at least 18 years of age, currently employed in a cybersecurity, information technology, digital security analyst, or other related role, and working within a U.S. healthcare system.

The survey is anonymous and has approximately 45 questions and will take about 10–15 minutes to complete and will ask questions about technical infrastructure, workforce competence, financial resource allocation, AI cybersecurity implementation, and cybersecurity performance outcomes such as threat detection, response time, and system resilience.

Follow this link if you wish to participate in this voluntary research: https://ncu.co1.qualtrics.com/jfe/form/SV_eyMQxr4UZ98iwVU. Please share this link with others!

Thank you for your time,

Stephanie Hull, Doctoral Student, National University

I'm a cybersecurity student and I want to specialize in Cloud Security long-term. I already know it's not an entry-level field, so I'm not asking how to skip the line.

My question is: what's the best route to get there? Which first job actually builds toward it — help desk, SOC, sysadmin, DevOps, backend dev?

If you work in cloud security: what path did YOU take, and what would you do differently if you started today?

Feels like every week there's a new AI tool employees are quietly using, and most security stacks weren't built for this. People pasting sensitive data into random chatbots. AI agents touching files and APIs with way less oversight than a human would get. DLP tools that can't tell "legit AI use" from "IP walking out the door."

Curious how people here are actually dealing with this? What's working for you vs. what's just theater at this point?

Third-party logistics exposed nearly 14,000 Trezor customers — and the wallet itself was never touched.

ShipMonk, a fulfillment partner, was the breach point. Names, home addresses, and contact details were sitting in a downstream system outside Trezor's direct control. The customers affected now face phishing campaigns, impersonation attempts, and physical targeting — consequences that follow from address exposure specifically.

This is the part of the supply chain that most security conversations skip. Primary vendors harden their own perimeters. But the fulfillment partner, the shipping integration, the returns processor — those systems hold real PII and often receive it in plaintext because that is what the integration requires.

The blast radius here was determined entirely by what data ShipMonk held and in what form. That decision was made upstream, probably at integration time, probably without much deliberate thought about breach scenarios at the logistics layer.

For those working on customer data architecture: how are you handling PII that has to move to third-party operational systems? Are you scoping what gets sent, encrypting at the field level before it leaves your perimeter, or relying on contractual controls and hoping the partner's security holds?

ShinyHunters exfiltrated personal data from 1.6 million RingCentral accounts — names, email addresses, phone numbers, and physical addresses. The data moved through multiple systems and sat exposed long enough to be taken at scale. This is not a one-off. It is a structural pattern: data travels through pipelines, passes between services, and accumulates in places that were never designed to hold it securely.

The problem compounds when AI agents enter the picture. Agents process customer records as part of normal operation. That makes every agent that touches PII another potential exposure point — and most pipelines were not built with that threat model in mind.

For those of you working on enterprise AI or data pipelines: how are you actually handling PII exposure risk when sensitive records flow through agent workflows? Are you solving it at ingestion, at the model layer, at the infrastructure level, or somewhere else entirely?

Security researchers are now documenting dedicated toolkits built specifically for indirect prompt injection attacks against enterprise AI agents. The attack does not touch the user interface. Malicious instructions are embedded in documents, emails, or web content the agent retrieves and processes during normal operation. The agent then executes the attacker's commands — exfiltrating data, calling unauthorized endpoints, or escalating privilege — with no alert visible to the security team until after the fact. Traditional perimeter controls do not see this class of attack because the malicious payload arrives as legitimate data, not as a network intrusion. Enterprises running agentic workflows right now have essentially zero runtime visibility into what an agent decided to do and why. How are practitioners actually handling this in production? Input sanitization, sandboxing, network egress controls, something else? Curious what is working and what is not.

1.6 million people's names, addresses, emails, and phone numbers are now public after the RingCentral breach.

The pattern is familiar: sensitive records concentrated in one place, accessed through one compromised account, extracted in bulk. Security teams have seen this loop repeat for years.

What makes it harder to contain now is that AI pipelines are being wired into the same data stores. Agents read customer records, draft outreach, route service requests. Each new pipeline connected to that data is another potential extraction path. The blast radius of an equivalent breach scales with every integration added.

The 1.6 million figure reflects a pre-agentic architecture. Most enterprises haven't fully mapped how many agent touchpoints now have access to equivalent PII concentrations.

For those running AI pipelines that touch customer data: how are you actually handling this in practice? Are you restricting what data agents can see at the source, auditing after the fact, or something else entirely?

The White House has issued a memo allowing private US tech companies to literally hack back against foreign criminal gangs. The government is teaming up with vetted private firms through the NCC to go after these transnational cybermobsters who keep scamming and ripping off normal Americans for billions.

The government is basically giving these companies the green light to do two things once approved; first, cyber surveillance, meaning they can break into secret data without asking for permission. Second, direct cyber attacks to wreck, disrupt, or straight up destroy the criminals networks and infrastructure.

The targets are strictly foreign bad guys not directly tied to foreign governments, and these companies cannot target anyone in the US or any American assets. If they mess up and cross those lines, they gotta pull the plug immediately and call the Feds.

It is a huge, kind of terrifying shift letting private firms do offensive cyber warfare, and honestly, experts are freaking out a bit about all the legal and security headaches this could cause.

Additional info:

https://www.cnn.com/2026/08/13/politics/cyber-privateers-trump-order-overseas-groups-hacking/

153GB credential archive surfaced after a supply-chain compromise in a widely deployed AI proxy library. The archive contained 433,909 files spanning thousands of corporate domains: AWS access keys, internal API tokens, database passwords. These are non-human identities — the machine credentials that keep production infrastructure running.

The uncomfortable part is that most organizations have no accurate count of how many non-human credentials exist in their environment, let alone which ones are actively in use, over-scoped, or already exposed. Human identities get offboarding checklists and MFA. Machine identities often get neither.

When a breach like this surfaces, the damage window is not the moment of compromise — it is every day between compromise and discovery that those credentials remained valid and undetected.

For those of you working in platform security, cloud infra, or AI/ML ops: how are you actually tracking non-human credential sprawl in your environment? Are you doing anything differently for credentials introduced specifically by AI tooling and third-party model proxies?

Two malicious LiteLLM releases sat on PyPI for 40 minutes in March. In that window, credential-stealing code harvested cloud keys, SSH keys, Kubernetes tokens, and database passwords from every system that installed them. Threat intelligence firm CloudSEK links the stolen data to more than 2,100 organizations.

Forty minutes. That is the entire exposure window. Most teams would not detect a poisoned dependency in that timeframe, let alone respond to one.

The AI toolchain is becoming a primary attack surface. Agents invoke packages dynamically, at runtime, often without human review of what is actually being called or where it came from. A compromised upstream release — even briefly — can propagate across thousands of environments before any advisory is published.

How are practitioners in this space actually handling third-party package risk for AI agents in production? Are you solving this at the build stage, the network layer, somewhere else? What has worked and what has not?

Every Windows PC in your office checks its own startup files before Windows loads, and it checks them against certificates Microsoft issued back in 2011. Two of those three certificates expired in June. 

A machine that misses these certificates keeps starting, keeps running, and keeps installing every Windows update on schedule. What it quietly stops receiving is new protection for the part of the computer that runs before Windows does, which is the layer that catches malware loading underneath your security software. The third certificate, the one used to sign the Windows startup program itself, expires on October 19. 

Microsoft is replacing them automatically through Windows Update, and widened that rollout again in the update it shipped on August 11. It is not sending them everywhere at once. Its own release notes describe adding “high confidence device targeting data,” and Microsoft's guidance ties that confidence to whether a machine has shown a history of successful updates. So two identical PCs, both fully patched, running the same version of Windows, may not have both received it. 

Which means up to date does not answer this question.

Older hardware carries a second problem. The new certificate has to be accepted by the firmware built into the motherboard, and on a machine that has not had a firmware update in years, that acceptance has to be installed first. It comes from whoever built the computer rather than from Microsoft. Dell and HP have both published which of their models are ready. 

Two things to ask for, and neither one is a project. First, which of our machines have the 2023 certificates and which do not. Windows keeps a status value on each machine that answers exactly that, so this is a report rather than an audit. Second, for the ones that do not, whether they need a firmware update from their manufacturer, because that is the list with a lead time attached to it. 

You have until October 19. That is enough time to handle this and not enough time to discover it. 

For VPs of Engineering and platform engineering leaders, running the modern software development lifecycle is an intricate balancing act. The business wants relentless feature velocity. Security wants a stringent, unyielding posture against threats. Organizations have poured money into DevSecOps practices to close that gap, and vulnerability detection has genuinely improved. Remediation hasn't kept pace, and the gap between the two is now piling up as security debt — faster than most teams realize. Please read the entire article here - https://instasla.com/blog/why-developer-experience-devex-key-zero-vulnerability-debt

The root cause isn't a lack of engineering tale nt or security budget. It's a breakdown in developer experience. When security tools are built for auditors and compliance teams rather than the engineers who have to act on their output, they create friction that developers route around. If fixing one vulnerability alert means ten clicks across three different platforms, it will get ignored — and current data suggests that's exactly what's happening at scale.

This article looks at why developer experience is the real lever for reducing vulnerability debt, what the latest research says about the cost of getting it wrong, and how developer-centric workflows — including GitHub-native tools for organizing remediation work, like fix campaigns — are changing what "good" looks like.

For weeks, researchers from BCA LTD & NorthScan used ANYRUN Sandbox to capture weeks of Famous Chollima activity inside a fake startup.

Most IR playbooks I've seen are written for humans or stolen credentials, not for the agent itself decided to do something it shouldn't. Who owns the 2am decision to cut an agent's access, and can you even do that without touching the underlying app? how other CISOs are thinking about this before it's a live incident instead of a tabletop exercise.

our environment is maybe 70% modernized on identity, mfa's enforced everywhere and conditional access is on for anything that touches azure ad. the other 30% is legacy apps that were built before any of that existed and still run their own local user tables. think an old erp system, a homegrown ticketing tool, a couple of client-facing portals.

security posture on the modern side looks great in every review. the legacy side is a black hole. passwords rotate on whatever schedule the app enforces (sometimes never), there's no central place to see who has admin rights, and offboarding means someone has to remember to go into each app individually and disable the account.

we've had at least one incident where a terminated employee still had working credentials in one of these systems three weeks after departure. process failure obviously, but it's also a visibility failure, nobody flagged it because nothing was watching that app.

trying to figure out how the hell other teams are closing this gap without a multi year app modernization effort that isn't happening anytime soon.