Every security leader wants the same three things out of a penetration test. Lower cost, faster turnaround, findings that are actually real. And almost everyone has been told you can only get two of the three.
I have been on both sides of this. Years as a bug bounty hunter breaking into things, and the last several years building a platform that has to deliver pentests at scale for enterprise customers. The tradeoff is not real. It exists because of how pentests are structured today, not because of anything fundamental about security testing.
The reason a pentest is expensive, slow and noisy is almost always the same. The person or the tool doing the testing starts with no idea what your organization actually looks like. Everything else follows from that.
Think about how a typical engagement runs.
You sign a statement of work. You send over a scope document, usually a list of URLs and maybe an IP range. Somebody schedules a kickoff call. The testers spend the first two or three days of a ten day engagement on reconnaissance. They run subdomain enumeration on assets your cloud team could have listed in thirty seconds. They fingerprint technology stacks that are already documented in your SBOM. They click through the application trying to work out where the authentication boundary sits, which your own developers could point at instantly.
Then a few days of actual testing. Then the last stretch writing the report.
Out of ten days you are paying for, maybe four are real testing. The rest is the tester climbing a learning curve your organization already climbed years ago. You are paying senior offensive security talent to rediscover facts you already own.
It never shows up as a line item, but it is easily forty to sixty percent of the engagement, and it repeats on every single one. New quarter, new tester, same climb. The knowledge from the last pentest disappeared the moment the PDF was delivered.
That lost time does not just cost money. It costs accuracy. A tester who spends four days learning your app instead of six days attacking it will miss things. Not because they are bad, but because depth of understanding is what produces the interesting findings. Surface understanding produces surface findings. That is where your reflected XSS reports come from.
The obvious answer over the last couple of years has been to throw agents at it. Autonomous pentesting, AI red teaming, pick the term. I build these systems, so I am not going to pretend they do not work. They do.
But most of them repeat the same mistake, faster and with a bigger bill.
You point an agent at a URL. The agent has no idea what that URL is. It does not know what codebase serves it. It does not know whether that endpoint sits behind an authentication middleware or in front of it. It does not know that the same service runs in three environments and only one is internet facing. So it does recon. It crawls, it fuzzes, it guesses, it burns tokens on discovery.
An agent doing blind reconnaissance is the most expensive form of reconnaissance there is. A human tester doing recon costs you their hourly rate. An agent doing recon costs you tokens on every page it fetches, every response it reasons over, every dead end it explores, and it will explore ten thousand dead ends without complaining. I have watched agentic loops accumulate context until the model is reasoning over a hundred thousand tokens of noise trying to remember what it was doing.
That context pollution is where hallucinations come from. When an agent has been wandering blind for forty turns, it starts reporting vulnerabilities in file paths that do not exist and quoting code snippets it invented. We hit this in our own pipeline and had to build grounding into the harness to stop it. An ungrounded agent does not just waste money. It generates convincing garbage, which is worse than generating nothing, because now a human has to spend time disproving it.
The answer is not to add AI to pentesting. The answer is to stop making anyone, human or machine, start from zero.
Your organization already knows everything a pentester needs to know. It is scattered across fifteen systems that do not talk to each other.
Your cloud provider knows every workload you run, what its security groups look like, what IAM role it assumes and whether it is exposed to the internet. Your source control knows every repository, every service, every dependency and every recent change. Your SCA tool knows your dependency tree and which components have known issues. Your DAST tool knows which endpoints respond and what they return. Your CMDB knows ownership. Your ticketing system knows what got fixed and what got accepted as risk.
Every one of those facts is something a tester would otherwise spend hours rediscovering.
The problem is that none of these systems share a common language. Your cloud inventory calls something an instance ID. Your code scanner calls it a repository. Your DAST tool calls it a hostname. Your SBOM calls it a package. Nobody is stitching those together, so the intelligence stays fragmented and useless for offensive work.
That stitching is the actual product. Not the scanner, not the agent. The graph.
The first thing Strobes does is stop being precious about where data comes from.
You can connect anything. SCA, SAST, DAST, secret scanners, cloud posture tools, container scanners, API security tools, whatever you already bought and are already paying for. You connect GitHub or GitLab or Bitbucket. You connect AWS, Azure, GCP, wherever your workloads run. You connect ticketing and your CMDB.
None of that data gets thrown away or flattened into a summary. It gets normalized into two primitives everything else is built on: assets and findings.
That normalization step sounds boring. It is the most important engineering work in the platform. Once every tool speaks the same language you can start correlating, and correlation is where the intelligence comes from.
Most platforms treat an asset as a row with a hostname and a criticality rating. That is a label, not an asset.
An asset in Strobes carries the full picture of what the thing actually is.
Network and exposure. Open ports, listening services, protocol details, TLS configuration, whether it is reachable from the internet or only internally, what sits in front of it. A WAF, a load balancer, an API gateway.
Technology fingerprint. Web server, framework, runtime version, CMS, reverse proxy, auth provider. Not guessed from banner grabbing, but pulled from the systems that already know.
Software composition. The full SBOM. Direct dependencies, transitive dependencies, versions, licenses, provenance. When a new CVE drops on a package four levels deep in a dependency tree, you know exactly which running workloads are affected without asking anyone.
Cloud context. Account, region, VPC, subnet, security groups, IAM roles and policies attached, storage buckets it touches, secrets it can read. What a workload is allowed to do matters enormously for exploitability. Remote code execution on a container with a scoped read only role is a different problem than the same bug on a container with an over permissive role that can read your entire secrets store.
Ownership and business context. Which team owns it, which business unit, which environment, what the change velocity looks like.
Relationships. This asset serves that application. That application is built from this repository. This repository deploys to that cluster. That cluster sits in this account. This service calls that internal API. This database backs those three services.
The relationship graph is what turns an inventory into intelligence. An inventory tells you what you have. A graph tells you what happens when one thing breaks.
Same discipline on the findings side.
A finding is not a title and a severity. Every finding that lands in Strobes carries where it is, what file and line if it came from code, what endpoint and parameter if it came from a scanner, what request and response proved it, the root cause, the exploitability conditions, the fixed version that resolves it, who owns the fix, and its history across previous scans and previous engagements.
Findings also get deduplicated and correlated across sources. Your SAST tool, your SCA tool and your DAST tool will all report versions of the same underlying weakness in completely different language. In most organizations those become three tickets that three people close independently. Correlated, they collapse into one finding with three pieces of corroborating evidence, which is a cleaner workflow and a much stronger signal about what is actually real.
That correlation history is also a calibration signal. Over time the platform learns which classes of findings on your stack turn out to be genuine and which get closed as false positives. You cannot buy that off the shelf. It is specific to your environment.
Integrations get you inventory. Code indexing is what makes the testing intelligent.
Strobes does not just store your repositories. It reads them and builds a structured, searchable representation of what the code does.
Route and endpoint extraction. Every route the application exposes, extracted from the framework definitions. Not crawled and guessed at from the outside, but read directly from where they are declared. That includes endpoints a crawler will never find because they are not linked from anywhere. Admin routes, internal APIs, debug handlers somebody left in, webhook receivers, legacy versioned endpoints nobody remembers.
That alone changes the picture. A crawler finds what is reachable by clicking. Code indexing finds what exists.
Authentication and authorization mapping. Where the auth middlewares are. Which routes sit behind them and which do not. Where the role checks, permission decorators and tenant scoping filters are. This is how you find broken access control properly, which is consistently the highest impact bug class in real applications and consistently the one automated scanners are worst at. A scanner cannot tell that an endpoint should have required an ownership check. Code indexing shows you which routes are missing the check that every sibling route has.
URL and sink extraction. Every place the application makes an outbound HTTP call, builds a URL from input, shells out, deserializes, renders a template, constructs a query or writes to a file. These are the sinks. This is where the bugs live.
Data flow and taint traces. Connecting sources of untrusted input to those sinks, with the transformations in between. This tells you whether a sink is actually reachable with attacker controlled data or safely fenced.
Chunking and indexing. All of it gets chunked, embedded and indexed so it is retrievable on demand. That matters more than it sounds. An agent working on a specific endpoint pulls exactly the twelve relevant chunks instead of trying to hold your entire monorepo in a context window. Precision retrieval instead of context stuffing.
Now stitch it together. This is where it stops being a data platform and becomes useful for offensive work.
Take a single endpoint. Something ordinary, like an invoice download route.
In a normal engagement that is a URL. In Strobes that URL resolves to the exact handler function in the exact file in the exact repository. The middleware chain that does or does not run in front of it. The database query it builds and whether that query is parameterized. The internal service it calls to fetch the file. The S3 bucket that service reads from, and that bucket policy. The IAM role of the container that runs the service. The ECS cluster it runs in. The account and region. The three other applications sharing the same bucket. The team that owns it. The commit that introduced the handler and the two open findings against its dependencies.
That is not a scope document. That is everything a tester would have spent two days assembling.
It works in both directions. Find something in code and trace it forward to the exact running workload where it is exploitable. Find something at runtime and trace it back to the line that caused it and the person who should fix it.
That bidirectional traceability has been missing from security testing forever. Code teams and cloud teams have been looking at the same problems through different windows without realizing it.
Start a pentest or a red team engagement on the platform. The agents do not start at zero. They start with the graph.
They already know every endpoint that exists, including the ones no crawler would find. They know which endpoints are behind authentication and which are not, and more importantly which ones look like they should be and are not. They know what technology is running, so no fingerprinting phase. They know the dependency tree, so they can go straight to proving whether a known issue is actually reachable and exploitable in your configuration. They know the cloud posture, so they can reason about what an initial foothold actually gets you.
The recon phase does not get faster. It disappears, because the answers were already in the graph.
The agents spend their time on exploitation, chaining and testing hypotheses instead. And the hypotheses are better because they are informed. An agent that can see the code does not fuzz an endpoint hoping something interesting comes back. It reads the handler, sees the object identifier going straight into a lookup with no ownership check while every comparable handler in the codebase has one, and goes to prove that specific thing. One targeted request instead of two thousand blind ones.
Same test, completely different economics.
Cost in a modern pentest, human or agentic, is a function of wasted work. Cut the waste and the cost follows.
Reconnaissance goes to near zero. The largest block of both human hours and agent tokens is gone because the data already exists.
Retrieval beats context stuffing. Pulling twelve relevant chunks costs a fraction of reasoning over an entire repository, and produces better output because the signal to noise ratio is higher.
Targeted testing beats brute force. A thousand blind requests to find one insecure direct object reference versus five informed ones. In agent tokens and in load on your own infrastructure, informed testing is an order of magnitude cheaper.
Caching works when context is stable. When your organizational context is a structured, persistent graph rather than a fresh crawl every time, large parts of the prompt context repeat across runs and across engagements. In our own pipeline, getting prompt caching right took cost down by roughly two thirds. That only works because the context is stable and reusable, which is only true when it comes from a graph rather than live discovery.
Model routing becomes viable. Not every step of an engagement needs a frontier reasoning model. Classification, extraction, normalization and routine validation run fine on smaller, cheaper models. Expensive reasoning gets reserved for the parts that need it. You can only route intelligently if the pipeline is structured into discrete steps, and it can only be structured if the context is structured.
Knowledge compounds instead of disappearing. This is the one that changes the multi year math. Every engagement enriches the graph. The next one starts further ahead than the last. Traditional pentesting has zero knowledge retention between engagements, so every quarter you pay full price to rebuild understanding that existed three months ago.
No discovery phase. Days one through three collapse into minutes.
Parallel by default. When you know the full endpoint inventory upfront you can fan out across the entire surface simultaneously rather than working through it sequentially as you discover it. Discovery is inherently serial. Testing a known list is not.
Fewer dead ends. Most of a tester's time goes into paths that turn out to be nothing. Code visibility kills most of those before any request is sent. If the taint trace shows the input never reaches the sink, you do not spend an hour proving it.
Reporting is a rendering step. The evidence, location, root cause, ownership and remediation guidance are already structured in the platform. The report is generated from data that already exists rather than written from scratch over a week.
Continuous instead of episodic. Once context is maintained continuously, testing does not have to be a scheduled event. A new service deploys, the graph updates, the relevant tests run against it. You find the problem in the sprint that introduced it rather than in next quarter's engagement.
This is the part I care about most, because accuracy is where credibility lives. A report full of noise trains your engineering team to ignore security, and that damage outlasts the engagement.
Grounding prevents hallucination. When the agent has to reference real indexed code with real file paths, it cannot invent a vulnerable function that does not exist. The harness enforces that every claim resolves to something real. Every reference is a handle into actual indexed content, not a string the model generated. That is the difference between an agent reporting what it found and an agent reporting what sounds plausible.
Reachability filters out the noise. A known vulnerability in a dependency is only interesting if the vulnerable code path is reachable in your application and exposed in your deployment. With the code index and cloud context together you can answer that, instead of shipping a CVE list and calling it a finding. Most of what SCA tools report is theoretically true and practically irrelevant. Correlation separates the two.
Evidence is kept separate from reasoning. In our pipeline, agents record what they observed separately from what they concluded from it. Observation is evidence. Conclusion is testimony. A finding only gets promoted when the evidence supports it independently of the narrative the agent built around it. That single architectural decision cut false positives more than any prompt engineering did.
Severity becomes contextual. The same technical bug on an internet facing production service with a broad IAM role and on an internal staging box with a scoped role are not the same risk. Without context you either inflate everything or flatten everything. With context you can rate actual risk, and engineering starts trusting your severities again.
Cross validation across sources. When code analysis, runtime testing and cloud posture independently point at the same weakness, confidence is high. When only one does, it gets flagged for validation rather than shipped as fact.
Chains become findable. The serious findings are almost never single bugs. They are chains. A low severity information disclosure gives you an internal hostname, that host runs an unauthenticated internal API, that API's container holds a role that reads a secrets bucket, those secrets unlock production. No individual step is above medium severity. The chain is critical. You cannot find chains without a relationship graph, which is why traditional scanning never finds them and why chained findings are where the real value in an engagement sits.
All of this runs as one product. Autonomous agents execute real, end to end penetration tests across web, API, network, cloud and code, and every finding ships with a working proof of concept attached.
An engagement is orchestrated, not improvised. A coordinator scopes the target, allocates phases and sequences the agents. Discovery, session management, attack and internal network agents each work the part of the surface they are built for. Attack and validation tools do the execution: headless browsers, exploit validators, a credential engine, an out of band collaborator service. A man in the middle proxy records every request and response, so evidence and replay are captured rather than reconstructed. Memory persists across phases, runs, assets and engagements, which is the same compounding-context argument, implemented.
The harness is what makes it safe to point at production. Every agent runs in an isolated, disposable sandbox. Scope rules, rate limits and destructive action policies are enforced at the harness level, and high impact steps pause for a human approval gate. Every command, decision and result is logged for replay, and secrets live in an encrypted vault the agents can use but never read in the clear. For internal work a lightweight on premise agent runs inside VPCs, Kubernetes clusters and Active Directory domains, so no data leaves the perimeter.
One engine covers the range of engagements a security programme actually needs: web, API and mobile application testing, LLM and agentic app testing, external and internal network, Active Directory, cloud review, code review with reachability verification, red team, supply chain and threat modelling. A human stays in the loop throughout, approving sensitive actions and taking handoff mid engagement.
The results are measured rather than asserted. Strobes ran a fully autonomous pentest against a live target, the open source Fider app, and Doyensec independently assessed the same application to give every number a shared third party reference.
And it does not stop when the report lands. Every patch triggers an exploit replay, so a closed ticket is confirmed by a blocked exploit rather than by someone's word. See how agentic pentesting works.
The order matters. Do not try to connect everything on day one.
Source control first. Code indexing is the highest leverage single integration. It gives you the endpoint inventory, the auth map and the sink map, which is most of what makes testing intelligent.
Cloud accounts next. This gives you exposure reality and blast radius, which is what turns findings into risk.
Then your existing scanners. SCA, SAST, DAST, secrets, containers. You already own these. The value is not the individual findings, it is what happens when they get correlated against each other and against the graph.
Then ownership. Half the delay in remediation is not technical, it is working out who is supposed to fix it. Get ownership into the graph.
Then run the engagement. With that foundation the first engagement is meaningfully better, and every one after it compounds.
Cheaper, faster and accurate was never a real tradeoff. It was a consequence of running every pentest as if your organization were a stranger.
Reconnaissance is not testing. It is the cost of not knowing your own environment. Remove that and you remove the cost and the delay, and accuracy improves as a side effect, because informed testing is simply better testing than blind testing.
The organizations getting this right are not the ones with the best scanners or the biggest budgets. They are the ones who stopped leaving their security intelligence fragmented across fifteen disconnected tools and started treating it as one connected graph that every engagement reads from and writes back to.
