❌

Vue normale

Reçu avant avant-hierInfra

Vulnerability alert fatigue nearly swamped WHOOP. But its fix still keeps a human in charge.

23 septembre 2026 à 15:23
Abstract image of thin vertical ribs against a bright orange background. In the center, a blurred rectangular glow shifts from green on the left, through dark red, to pink on the right, as if seen through ribbed glass.

With often hundreds of thousands of alerts a day, many tech organizations are buried in vulnerabilities and worn down by alert fatigue. The rise of AI has only made it harder to cut through the noise and to find actionable alerts. Manual security and site reliability engineering is not an option. 

The engineering team behind WHOOP‘s health and fitness tracker felt this pain, relying on multi-day, all-hands triage sessions to stay on top of the alert deluge. But, as a high-growth consumer health company handling sensitive user data, it couldn’t afford to miss anything. Which is why the team at WHOOP built an automated vulnerability-response workflow based on the company’s specific technical, operational, and trust considerations.

Join The New Stack on Wednesday, October 7 to learn from WHOOP staff engineer Vinay Raghu and Datadog senior product engineer Amber Tunnell how WHOOP built and implemented this workflow using Datadog Bits AI and Workflow Automation for faster, at-scale response. 

Join us on October 7, 2026, for a live Datadog x TNS event

REGISTER NOW FOR THIS WEBINAR
By registering, you consent to The New Stack’s Privacy Policy, Terms of Use and to receiving email communication from The New Stack and our event partner. You may opt out at any time.

DevSecOps, security, and cloud/platform engineers should bring their questions to this live demo-slash-case study to learn how to reduce friction between developer velocity and security requirements without increasing headcount. 

What you’ll take away from our live webinar

Raghu and Tunnell engineers will share how they were able to:

  1. Focus on real exposure vs. scanner noise. Not everything is critical. You’ll learn how WHOOP used Datadog’s Software Composition Analysis (SCA) to analyze runtime code execution and prioritize active threats.
  2. Route the right vulnerability to the right engineer. WHOOP automated vulnerability mapping to microservice owners, so developers received tickets with full context attached.
  3. Build automated guardrails for devs to self-resolve. This let security engineers pivot from frustrating gatekeeping and ticket-pushing to more proactive, systemic work that adds value. 
  4. Maintain a human in the loop. With such sensitive data and a demand to be always-on, WHOOP isn’t ready to automate the engineer out. Learn how they decided their team’s response had to change.

And then, of course, we will end the live discussion with how to measure it all. Don’t miss out and register to attend on October 7.

The post Vulnerability alert fatigue nearly swamped WHOOP. But its fix still keeps a human in charge. appeared first on The New Stack.

47,000 job listings reveal the engineering roles that AI is creating

10 septembre 2026 à 15:09
Abstract overlapping circles in black, green, orange, and pale yellow on a cream background.

Every major transformation in tech has led to roles merging, then new ones emerging. Friction between developers and operations drove the creation of the DevOps engineer. Then, when security needed to be considered throughout the delivery pipeline, DevSecOps emerged.

The team beyond the AI-native talent and services platform Andela analyzed 47,000 recent engineering job postings from Fortune 500 companies. This research, released on Thursday, uncovered more than 2,000 skills that pour into 23 emerging job titles. None of these are coming out of nowhere; they strategically merge existing skill sets to create new roles. 

Among 1,832 postings titled primarily for AI or ML engineers, 53% contained at least two skills drawn from different established roles, Andela finds.

In today’s tighter economy and amid AI, companies seem to be going one of three ways. They are lumping too much work and required experience into now-nebulous AI engineer or machine learning (ML) engineer job titles. They might be looking to replace tech workers with AI. But more forward-thinking organizations are reworking job titles and descriptions to reflect the demands of getting AI safely and efficiently through the software delivery lifecycle. 

Cory Hymel, head of research at Andela, tells The New Stack, “If you’re going to look to deploy AI within your organization, the way to look at it is that an AI has a certain set of skills, and then a human has a certain set of skills.

“If you Venn diagram those and see where they cross over, an AI should do the skills it can. But the human circle is still exponentially larger than that of AI.”

“When you’re looking to deploy AI, it’s not about trying to replace that human circle with an AI one. It’s about what certain skills you need to carve out and delegate to it.”

Read on for the top engineering jobs that are emerging because of AI, how to attract tech talent for them, and what you need to focus on to get a tech job in this tough market.

Click image to enlarge.

AI is not serving the generalist. Specialization is still key.

Citing the leading AI CEOs, Hymel remarks, “You’ve heard from the AI salespeople of the world that AI is going to push people to be more generalist, and the data that we found here doesn’t necessarily support it.”

“You’ve heard from the AI salespeople of the world that AI is going to push people to be more generalist, and the data that we found here doesn’t necessarily support it.”

Overall, they found that these emerging job titles aren’t generalist at all. These emerging roles bridge skill sets from several existing ones, but each addresses a specific operational or product need, some tied to AI adoption. 

The top five new engineering job roles discovered are:

  1. MLOps pipeline engineer, who builds and runs the automated infrastructure to deploy, version, and monitor machine-learning models in production, with 46% ML engineer, 23% DevOps engineer, 15% data engineer skills, and 8% each AI engineer and data scientist roles.
  2. LLM application engineer, who builds on and evaluates foundational models via large language model application and conversation systems, bringing 48% AI engineer and 34% ML engineer, with a touch of product designer, software architect, and embedded software engineer roles.
  3. FinOps reliability engineer runs cloud infrastructure for both reliability and cost, bridging 36% DevOps engineer, 27% site reliability engineer (SRE), 18% cloud engineer, and 9% each DevSecOps engineer and cloud solutions architect.
  4. Docs-as-Code engineer applies program management and DevOps engineering skills to the traditional technical writer’s role, pivoting from stagnant docs to specification-as-code.
  5. Product frontend engineer is about a third traditional frontend engineer and a third product manager, with a touch of full-stack engineer, UX researcher, and product designer.

“If you’re a DevOps engineer, historically, your skill bundle might have allocated 30 to 40% of pure DevOps-required skills that are rich and specific to that role, and you have a remaining bundle that is cross-role habitable, meaning that those skills would translate between DevOps or to an engineer or to a technical product manager,” Hymel explains. “Some of those skills can now be replaced with AI, which means that those skills that are more directly focused on your role become more important than ever.” 

So-called “soft” business skills are also increasingly crucial, he contends. However, he seriously doubts anyone will ever be able to slide between finance, marketing, engineering, and sales roles. 

Where enterprise engineering job descriptions falter

“Job descriptions and resumes right now are the best worst thing that we have. When you’re talking about large enterprises, and you’re having to deal with scale, your hiring process gets farther away from the work,” Hymel explains. 

Especially when the hiring process starts in HR, not engineering, “you’re needing to put language in place that will survive the chain of custody, with the naming of the job [coming from] the engineer that’s closest to the work.”

It’s not uncommon for an enterprise to have 50 different front-end developer job listings, each with very different skill requirements. It’s better for candidates and for fit to be as specific as possible, including embracing new job titles.

This habit of generic job titles used to be positive because it brought in more applicants, but nowadays, with so many engineers on the market, it further dilutes your hiring pool, leaving you with the 100 fastest applicants—who are often AI-generated anyway.

“Any company that has not taken a hard look at revising their job postings and job titles is at an extreme disadvantage because there’s a very high probability that you’re going to end up hiring the wrong person simply because you didn’t take the time to describe the role well enough,” Hymel remarks, which leads to dire consequences. 

“There’s potential churn, so you just spend all this time and cost to go headhunt and find someone. Two, if they do get in there, you have to pay for their ramp time to get up to speed because they were sold a different bill of goods than what was in the description. And then three, it impacts overall roadmaps and timelines because now you might have to replace, and, again, you have to wait for people to get up to speed.”

On top of this, HR and engineering hiring managers alike are using AI to generate job descriptions. It still isn’t recommended to have AI generate something so human and essential to your core success.

Especially in this time of flux, when no one may have the required experience, companies should start job descriptions with what they want the future hire to achieve.

“The cost of code is going nearer to zero.”

“The cost of code is going nearer to zero.” Hymel explains organizations should think more like, “Here are the outcomes that we’re looking for. If you have the soft skills and additional skills around it to get there, whether that is backlog prioritization, being able to be collaborative, having worked on project deployments before, and we don’t necessarily care that you can score a 10 out of 10 on Python anymore.”

Which emerging roles engineers should pursue

The familiar claim that women apply only when they meet every qualification is not well supported; recent research finds that application behavior is more complicated. Still, clearly separating essential qualifications from preferences can reduce ambiguity and unnecessary barriers.

Focusing on outcomes and clearly distinguishing required from preferred skills may broaden the applicant pool, although it does not guarantee greater diversity.

For example, if you’re an engineer who enjoys having a product focus, collaboration, and strategy, Hymel recommends looking toward the new product front-end engineer role, which owns the full user-facing feature lifecycle, from definition to shipping.

“You are required to have more mindshare towards prioritization of features,” he says, shifting away from a ticket person, because “now you have more control because AI allows you to span out a little bit deeper.”

Similarly, AI has the back-end engineer thinking beyond the back-end stack to deployments, scalability, and the reliability of underlying infrastructure systems, giving rise to roles like the polyglot back-end integration engineer. 

Technical writers — reasonably worried about their jobs in the face of AI-generated documentation — should look toward new docs-as-code engineer positions, which add technical program management and DevOps engineering skills.

“If you’re writing the docs, you’re essentially writing the specs that enable spec-driven development. You now have the capability to actually contribute software,” Hymel observes. “And it starts all the way at the top too. If you’re a product manager, you can now start building and contributing code, like a product experience designer.”

Read the full Emergent Role Research. If any of these AI engineering job descriptions ring truer than what you were hired for, we hope it empowers your next conversation with HR or for you to apply for a different job title. 

The post 47,000 job listings reveal the engineering roles that AI is creating appeared first on The New Stack.

Why authority is the attack surface AI security keeps missing

31 août 2026 à 12:00
Cyan and orange neon tubes form nested chevrons on a dark wall.

Michael Loewy, co-founder of the Tide Foundation, says the security industry was already losing ground to hackers before AI. Everything from a typo to a state actor could create a breach.

“Before AI even came into the developer consciousness, a developer or a platform owner needed to be perfect all the time — perfectly patched, free of errors, free of bugs — and an attacker only needed to be right once to get in,” Loewy tells The New Stack. “It’s virtually impossible, which is why we’re seeing breaches in the news every day, and the biggest companies in the world getting breached. It could be one poorly written line of code, one misconfiguration, and then you’re done.”

AI has, of course, compounded the risks.

Loewy warns that vast amounts of inadequately reviewed, error-prone code are being produced just as advanced AI models are becoming highly skilled at discovering and exploiting vulnerabilities. Meanwhile, AI agents are creating software and performing sensitive, privileged actions.

Attackers gain access by getting past authentication and authorization. But what Loewy and co-founder Ben Waters are most worried about is the authority agents gain once inside.

Authority, as they define it, is the power to decide who or what can get into which system, who can access and decrypt which data, and who can authenticate, authorize and assign permissions. It lives in the systems we’re forced to unquestioningly trust in the form of admin credentials, root keys, identity providers, and service accounts. As Loewy says, “the problem is that it always lives somewhere, and someone always has access to it.”

Tide’s answer is a model it calls “emergent authority.” Under it, authority isn’t permanently held by any person, system, administrator, or AI. Instead, it is generated only when identity, policy, context, and intent align — before it disappears again. Loewy and Waters spoke exclusively with The New Stack about what that means for developers.

The flaws of the all-eggs, one-basket approach

Most systems at most organizations keep application secrets, user credentials, and permissions in one place, then build more and more defenses around that central location, such as firewalls, key vaults, multi-factor authentication, and endpoint detection and response.

“That root paradigm is flawed. Tide seeks to overcome that by using cryptography to compute authority in pieces so that it can’t be reassembled.”

“Even if your code is perfectly free of bugs, it’s sitting in someone else’s cloud on someone else’s operating system. There’s this whole suite of dependencies where the code and everything needs to be perfectly patched all the time, everywhere, and configured correctly for your security to be perfect,” Waters explains in our interview. “That root paradigm is flawed. Tide seeks to overcome that by using cryptography to compute authority in pieces so that it can’t be reassembled.”

In reality, just about every system is porous. Tide’s goal is that if and when you are breached, and the attacker has root on your server, there is nothing there for them to inherit, because the authority has been architecturally distributed elsewhere.

From IoT middleware to distributed authority by default

Founded about a decade ago, Tide started as an Internet of Things analytics platform sitting between brands and consumers’ connected health devices, smart homes, and wearables. Its regulated customers demanded proof that no breach could leak highly sensitive information, trigger a GDPR fine, or destroy a reputation.

The infrastructure the team built to secure itself became the product, and, with it, a way out of the perpetual safety-speed tension between DevSecOps and product teams. At the pace of AI, this tension has only sharpened.

That infrastructure is now the developer product, TideCloak, which fits where your identity and access management system sits and handles authentication, authorization, end-to-end encryption, and governance on top of Tide’s Cybersecurity Fabric, so consequential authority remains out of everyone’s and everything’s reach.

The implementation is fully inspectable through Tide’s open-source public GitHub repositories. The accompanying white paper on emergent authority was published using a chatbot to explain the underlying concepts and cryptography.

Let your coding agent do the integration.

The part most likely to interest developers is how you’re meant to adopt it, not by reading those loads of documentation, but by handing the job to your coding agent.

“We needed this security apparatus or infrastructure that we’ve created to be something that can be seamlessly integrated into an existing project or best practice in a greenfield project, in a way where the developer doesn’t need to read loads of documentation,” Loewy says.

On Monday, Tide released Raziel, an MCP server named after the archangel of secrets, that gives AI assistants deep knowledge of Tide authentication, threshold cryptography, end-to-end encryption, and governance. Point your agent at it, and it can recommend self-hosted versus managed hosting and generate verified playbooks for the integration. A TideCloak quickstart covers the greenfield case for those who’d rather start from a clean project.

Where most security tooling begins by looking for ways an attacker might get in, one of Raziel’s prompts instead maps out your blast radius.

“We’ve said: they’re already in. Here’s what they’re going to find. Here’s where they can impersonate any user. Here’s where they can assign themselves access to whatever they want.”

“Where a typical cybersecurity scanner tries to find vulnerabilities- how someone’s going to get into your platform — we’ve started the opposite way,” Loewy explains. “We’ve said: they’re already in. Here’s what they’re going to find. Here’s where they can impersonate any user. Here’s where they can assign themselves access to whatever they want.”

Tide has also partnered with a Lloyd’s of London underwriter, enabling organizations integrating TideCloak to obtain preferential cyber insurance terms. He says that “It’s a rare case of a security claim being backed by capital.”

Coordination at scale, without custody at scale

The team likens their ambition to DNS. They hope that one day soon Tide will become infrastructure that nobody owns and everybody benefits from.

Tide is not just about breach prevention. To let an AI agent, a contractor, a partner, or a new vendor do anything consequential, you have to trust them with dangerous power. That trust requirement caps how far you can safely delegate or automate.

“The point isn’t just safer systems. Once nobody has to hold dangerous power to get something done, you can delegate real responsibility to an agent, a contractor, or a five-person startup without creating a dangerous insider.”

“The point isn’t just safer systems. Once nobody has to hold dangerous power to get something done, you can delegate real responsibility to an agent, a contractor, or a five-person startup without creating a dangerous insider,” Loewy says. “That’s what lets developers ship with AI at full speed. It’s coordination at scale without custody at scale.”

If that holds up in practice, Tide’s biggest effect may not be on cybersecurity at all, but on the cost of delegation, and on how much a small team, working with agents, can safely be trusted to build.

The post Why authority is the attack surface AI security keeps missing appeared first on The New Stack.

❌