Show to run Pen Testing on Harness : A contained, pipeline-native way to prove releases fail closed under named conditions. Evidence-first, not an exploit — audited on every run.
TL;DR
A "contained pen test" isn't broad production access — it's a narrow, security-authored failure condition (like an identity-provider outage or a revoked credential) that runs automatically inside the pipeline. Each of the eight example experiments checks the same underlying question — does the control fail closed or quietly fail open — and produces an immutable, audit-ready record on every run. That turns the security conversation from "can we grant this access" into "which conditions do we want proven," which is the direct answer to the permission blocker you hit twice before.
Security teams are increasingly being asked to sign off on a new kind of request: run a penetration-style test against a production workload, but do it inside the build or release pipeline, not as a separate, calendared engagement. The instinct in most security organisations is to slow this down, because the assumption is that any pen test needs broad access — new permissions, a new attack surface, a new thing to govern.
That assumption is the actual problem, and it is worth being precise about it. The opportunity isn't to grant a testing tool wide access to production, it's to define, in advance, exactly what failure or intrusion condition you want proven, and let the pipeline run only that.
What "contained" actually means
A contained experiment is scoped to one service, one condition, and one pipeline stage, and it is authored — not discovered. Instead of asking security to open the door to an open-ended scan, the platform lets the team write a custom fault: a precise, single-purpose experiment (a dependency timing out, a credential being rejected, a node behaving as if compromised) that runs only where it is placed and produces only the evidence it was built to produce. There is no ambient permission being granted. There is a specific test, approved once, that is now repeatable on every release.
This is the same principle that governs resilience risk detection more broadly: predict the risk first, generate the smallest experiment that proves or disproves it, and produce evidence rather than an opinion. Applied to security-adjacent failure conditions, it means a bank's platform team can demonstrate — with a timestamped, immutable record — that a given release does or does not tolerate a specific adverse condition, without that demonstration ever touching data or systems outside the boundary the security team drew.
It is worth being explicit about what this is not. None of the following is an exploit. None involves a scanning tool, an injection payload, or lateral-movement tooling, and none requires granting the kind of access a red-team engagement normally asks for. What it does instead is take a small number of conditions a security review already cares about, and turn each one into a named, repeatable experiment that runs inside the pipeline rather than as a separate, calendared exercise.
What a few contained experiments could actually look like with Harness Resilience Testing
Identity-provider outage. The authentication service an application depends on is made briefly unreachable. The interesting question isn't whether the call fails — it's whether the application then fails closed, or falls back to some default that lets the request through anyway. That fail-open pattern is a genuine, recurring vulnerability, and it is rarely caught by any other kind of test, because most tests assume the identity layer is available.
Credential and token revocation. A service's role or token is revoked, or allowed to expire, mid-request. This confirms the service re-checks authorization on each call rather than trusting a token it already validated once — the difference between a system that re-verifies and one that merely remembers.
Certificate and secret expiry. A TLS certificate or a rotated secret is made to look stale. The experiment checks that the connection is refused, not silently accepted with a warning nobody reads.
Tampered or corrupted tokens. Packet-level corruption or latency is introduced on the link carrying a signed request, to confirm a partially altered token is rejected outright rather than partially trusted.
Unexpected egress. Outbound DNS is redirected to a decoy destination, approximating the shape of a data-exfiltration path, to confirm allow-lists and egress controls actually stop traffic rather than merely logging it.
Privilege drift. A workload is deployed with elevated privileges it should not have. The experiment checks that the policy engine blocks and alerts on it, rather than recording it after the fact.
Load consistent with abuse. An endpoint is driven at a rate that resembles brute-force or credential-stuffing traffic, to confirm rate limiting and circuit breakers hold rather than the identity layer degrading into a more permissive state under load.
Node-level disruption. A node is killed or drained without warning, to confirm the failover path does not leak a secret into a log, or reuse a session token in a way that was never meant to survive the handoff.
Each of these is authored once, as a custom, narrowly-scoped experiment — not pulled from an open-ended library of attacks — and approved once by the team that owns the risk. After that, it runs automatically on every release, and answers the same question every time: under this specific, named condition, does the control hold.
Why the evidence matters more than the test
For a regulated environment, the artefact that comes out the other end is often more valuable than the test itself. Every run, every suppression, and every justification for skipping a check is logged immutably — the same standard SOX and SOC 2 audits already expect. Resilience risk is tracked as its own category alongside availability, performance, dependency, and configuration risk, so a coverage gap in security-relevant failure handling shows up as a gap, not as silence. That turns "did we test this" from a question asked after an incident into a line item that gates promotion before one.
This is also why the sequencing matters. The temptation is to start with "prove it broke" — run the disruptive test and see what happens. The more defensible order of operations is to predict where the risk sits, rank and explain it against the service's actual criticality, generate the narrowest experiment that proves it, and only then gate the release on the result. Security teams tend to trust that order, because it is the same order they already use for risk review — evidence and reasoning first, disruption second, and only as much disruption as the question requires.
The practical shift
None of this requires a security team to grant a chaos or pen-testing tool the kind of access it would associate with a red-team engagement. It requires agreeing, once, on the shape of a small number of experiments, and letting those run automatically as part of the pipeline that already ships the code. That is a governance conversation, not an access-grant conversation — and it is usually a much shorter one.
The harness Resilience Testing Free Plan
Harness offers a free plan for Resilience Testing, where you can get all the capabilities, for free, for a limited number of monthly runs. Signup Now. Sign up for free
