Automating app security for modern dev teams

A penetration test describes an application on the day it was tested. Most software teams ship again the next week. Rejah Rehim spent the early part of his career on the testing side of that gap, and he built a company to close it.

“they are released on a daily basis or on a weekly basis. But they have to wait for another three months or a quarter, even if the test is on a quarterly basis.”

Rejah Rehim, at 6:19

Listen · Rejah on episode 82, from 6:12

Rejah is the co-founder and chief executive of Beagle Security, which automates penetration testing for web applications and APIs. The company’s site says he and his co-founder Prathap started it in 2020 to “identify software security issues as early as possible,” on a continuous cycle with the help of artificial intelligence (Beagle Security). On this episode he tells Sasha and me where that automation reaches, where it stops, and why the stopping point matters more than the reach.

Where we sit, so you can weigh what follows: YSecurity runs penetration tests too, scoped with founders and led by people, so Beagle and YSecurity work on the same problem from two ends. Beagle automates the repeatable part of an application pentest, and a lot of our time goes to the part Rejah says still needs a person. Sasha and I hosted. The episode aired on November 18, 2025, and the video version went up on our YouTube channel on October 18, 2026. The tape dates itself to 2025: Rejah talks about developers “moving forward with vibe coding,” a term that took off that year.

A pentester who kept seeing the same problem

I asked Rejah what started it. He answered as a tester: early in his career, “I did penetration testing, red teaming, and then saw the same problems repeated across organizations.”

“Security was often treated as an afterthought. It came in too late, and the results were rarely actionable.”

Rejah Rehim, at 2:17

The rest of his answer is the whole company in four sentences. Development teams were moving fast and security wasn’t keeping pace. The traditional approach “couldn’t scale in fast-paced environments.” So he wanted to build a platform “that makes application security proactive, developer friendly, and scalable across the platforms.” And then the line I’d put on Beagle’s wall if it isn’t there already: “It wasn’t about starting a company for the sake of it. It was about fixing something that clearly needed to change.”

His record is a long run of exactly that kind of work. His LinkedIn starts in December 2011 as a web security analyst at QBurst Technologies in Trivandrum, building an internal security testing portal and testing web and mobile applications, then security architect at Digital Brand Group from 2013 and at FAYA from 2016. He has led the OWASP chapter in Kerala since August 2014, has been an OWASP project leader since September 2018 (the SecureTea tool and a risk rating assessment framework), and since January 2020 has been a core maintainer of the OWASP Web Security Testing Guide, the open guide many testers work from (LinkedIn). He has written three books on Python for penetration testing: Effective Python Penetration Testing in 2016, Python Penetration Testing Cookbook in 2017, which BookAuthority put on its list of the best cybersecurity books of all time, and Offensive Security Using Python in 2024. Beagle’s about page adds that he is “the creator of 9 Mozilla add-ons” and holds an honorary commander’s rank at the Kerala Police (Beagle Security). His LinkedIn headline calls it Commander (Hon.) at Kerala Police Cyberdome, the force’s cyber center.

What shifting left means

When Sasha asked what needed to change, Rejah said “shifting penetration testing or application security in the early stages of development,” and Sasha stopped to translate it for everyone listening.

“And so shifting left for those who are maybe not as technical, it means getting closer to the problem itself.”

Sasha Sinkevich, at 3:13

Rejah’s version is about cost. When the test comes after development, “when we give a report, or when we provide with the report, the time to fix it or the cost for fixing those issues will be huge in the waterfall model.” Testing in the early stages, “integrating with the development life cycle easily, that will reduce the cost of fixing, also the time to fix issues.”

That’s the textbook argument, and it’s right as far as it goes. Where shift-left usually breaks is the handoff: a scanner moves findings earlier, and a developer who can’t tell which of them matter gets a longer queue instead of a safer product. We wrote about that failure in why shift-left security keeps failing. What makes Rejah’s version interesting is that he didn’t stop at moving the test earlier. The rest of the conversation is about what comes out of the test, who reads it, and who helps them fix it.

Building since 2018

I asked how long they’d been at it.

Listen · Rejah on episode 82, from 4:02

The timeline he gave: building since 2018, a private beta in 2020, when they also registered the company, “In 2021, we ran a lifetime deal to accommodate maximum users,” and “in 2022, we made it a SaaS platform, a recurring subscription-based platform as of now.” The lifetime deal had a purpose beyond revenue, he said, “because ours is a supervised learning system in the back end.” The platform needed tests to learn from, and a lifetime deal brings in a crowd of people running tests.

Sasha asked whether “supervised” meant red team members leading the tests remotely. No, Rejah said: “It’s like a system that learns by itself about the new vulnerabilities.” An R&D team feeds it newly found vulnerabilities and business logic test cases, and the engine then chooses test cases and payloads on the go. Sasha put it in the language of machine learning, an approach where “you can dynamically adjust the pattern or the methodology,” and Rejah gave the working version: the engine reads the tech stack an application is built with, picks the test cases that stack needs, and “Based on the response from the system, it adjusts the payloads, everything on the go.”

Shipping weekly, testing quarterly

Sasha asked the question every founder should ask about their own product: of everything customers say, what’s the biggest pain point it addresses? Rejah’s answer is the clip at the top of this page. Teams with a rigorous development flow release daily or weekly and test quarterly, if that. In between, “there is a huge gap in between the tests.”

Then he put numbers on it, from his own experience as a tester and his own product, so they’re his estimates rather than a survey. A manual end-to-end penetration test “will take around 20 to 25 days.” Beagle’s aim is “automating that to happen within two to three days, so that it can be [integrated] within the time period of the functional testing itself.” The test can be triggered from the CI/CD pipeline, and the findings go “directly onto the bug tracking systems,” so developers “can use it in their workflow to get the things fixed early in the development lifecycle.”

Two things in that answer are worth holding onto. The first is that a 20-day test of a weekly-release product is testing a moving target, so even a perfect report describes an app that no longer exists by the time it lands. The second is the destination of the findings. A PDF a security team reads once a quarter is a different object from a ticket that lands in the tracker a developer already lives in. Beagle’s own video shows the second one, pushing results into Jira.

For a Series A company, the quarter-long gap has a second cost that has nothing to do with attackers. An enterprise buyer’s security review asks for the date of your last pentest and what happened to the findings, and a report from most of a year ago, on an app that has shipped every week since, is a hard thing to defend on that call. We wrote about the cadence buyers now expect in Pentest once a year?, where Rejah’s line on this episode already makes the case.

Rejah has since written about the same calendar from the scoping side. His point is that a compliance-driven pentest gets scoped around the pages an auditor reads, so whatever shipped after the statement of work was copied from last year’s never gets tested at all.

Ask a pentest vendor what they're testing and the answer usually traces back to your auditor. The scope gets built backwards. SOC 2 wants evidence that an annual test happened. PCI wants the cardholder environment covered.

Rejah Rehim · July 28, 2026

Load the post from LinkedIn

The running app, not the source code

Sasha then asked the question that decides what kind of tool this is: was Beagle replacing the human pentest or red team, or augmenting it, and was it working on every layer of the product or only the source code? Rejah corrected the frame before anything else.

“No, no, we are not working on the source code side. It’s a DAST side of it, like dynamic application security testing.”

Rejah Rehim, at 7:45

The distinction matters. Static testing, SAST, reads source code without running it. Dynamic testing, DAST, attacks the running application from the outside, the way an attacker would, and sees what the code actually does once it’s deployed with its configuration, its framework and its dependencies. Beagle has its own explainer, DAST vs SAST, and the two are complements rather than rivals. Rejah’s next sentence is the claim Beagle is built on: “But it’s not just scanning. We’ll be doing in-depth penetration testing.”

Where automation stops

This is the part of the episode I’d send to anyone shopping for automated pentesting, because the founder of an automated pentesting company says plainly what automation can’t do yet.

“So we are trying to automate that part, but universal automation for all applications with its business logic is too complex. We are trying to achieve that, but there will be some gap.”

Rejah Rehim, at 8:10

Listen · Rejah on episode 82, from 7:45

Business logic is the rules an application is supposed to enforce that no framework knows about: a user at one customer shouldn’t see another customer’s invoices, a discount code shouldn’t stack with itself, an approval step shouldn’t be skippable by calling the next API directly. Beagle’s own guide to the subject says these vulnerabilities “are inherently application-specific,” which is why a general-purpose engine struggles with them (Beagle Security, May 2026). Rejah’s answer is a division of labor. Where a team has a penetration tester, “he can focus more on the complex side or the business logic side of it, and all the other things we’ll be able to automate by the platform itself.” Then the advantage a machine has over a person: “Unlike the human, we will not skip any test cases.”

From where we sit, that division is the right one, and it’s worth saying why it matters to a startup selling to enterprises. The questions an enterprise buyer’s security team asks first are business logic questions. Can a user at one tenant reach another tenant’s data? What happens when a session token from a deleted account is replayed? Those depend on how your application is supposed to work, which is the part Rejah says still needs a person, so a good program runs the automation on every release and points the human hours at exactly those flows. Our penetration testing work starts from that split, and our AI penetration testing guide covers where machines earn their keep and where people still do.

Jon hits the guardrails

I brought my own experience to this one. I’ve tried pointing the public AI models at systems and asking them to find the holes, and the answer usually comes back polite and useless.

“And oftentimes, like, I bump into these guardrails that come back with vanilla responses, like, oh, thank you so much, but we’re not allowed to use this for nefarious purposes or for breaking into systems.”

Jon McLachlan, at 9:29

So I asked whether Beagle had hit the same wall. Rejah’s answer was that the question didn’t apply: “Yeah, of course. Like, we are not using the public LLMs anyway.” Beagle isn’t one model answering one prompt. “It’s not like that. We do have multiple areas which we use AI modules.” Some of them are language models and some make decisions, and “what it does is like take the decision like a human in every stage of the testing.” The language models do the writing, in the report generation side, where the goal is a report that’s “highly tailored and actionable insights for the developers,” step by step and specific to the tech stack the application runs on.

The guardrails are only half of why. The other half is data.

Models trained in-house

“But for that itself, we are not using any public LLMs, because, as it’s a security product, we do have limitations to using the public LLMs because of the data leak.”

Rejah Rehim, at 10:38

Listen · Rejah on episode 82, from 10:38

A pentest report is a map of where an application is weak. Sending one customer’s findings through a third-party model to have them written up nicely is the kind of data flow a security vendor has to be able to explain to that customer, and Rejah’s answer is to not have the flow at all: “We do have our own models, which we trained internally with the data we have, with the recommendations we provide, with the test cases and payload generation engines we have.”

I asked where the training data came from, and the answer closed a loop from earlier. It was the 2021 lifetime deal. “We do run an LTD. In the initially, we do have around 1,700 plus users signed up for that, and they ran tests on their web applications. We use those details to train our platform in an anonymous way.” A lifetime deal is usually a way for a young company to raise cash and find users. Beagle used it to collect the test runs its engine learns from.

The same question is now standard on enterprise security reviews of any AI product, Beagle’s or yours: which models touch our data, where do they run, and is our data used to train them? We keep a list of the ones buyers ask most in the AI security questions your first enterprise buyer will ask. Rejah’s answer, models trained in-house on anonymized test data, is one clean way to answer all three.

Do it yourself, and the enterprise tier

I asked how many people were on the platform, and the numbers he gave were for that moment, so take them as a snapshot: “we do have 10,000 plus users, but we have around 1,700 plus customers who are paid at least once, and around 200 plus customers who are recurring as of now.” Beagle’s site today counts “1800+” customers served, more than 1.7 million vulnerabilities detected and more than 790,000 hours saved (Beagle Security).

Then I asked whether it was bottom-up, whether someone listening could go to beaglesecurity.com, sign up and start testing. Yes, Rejah said, “But it’s mostly B2B customers.” The model is “a do-it-yourself kind of security platform for web applications and APIs.” There’s one gate, and it’s a good one: “Only thing we need is you need to verify the domain ownership. We have to make sure that the owner of the domain is doing the testing.” That’s done with a file or a DNS record, the same proof a certificate authority asks for. An automated attack tool that anyone could aim at anyone’s domain would be a weapon, and the verification step is what keeps it a testing tool.

Sasha asked what an enterprise tier changes. Pricing, mostly. Smaller plans pay by the number of tests a month, “But for enterprise, the pricing is different from the number of tests, and it’s count only the number of tests that runs at a time, like five concurrent tests or ten concurrent tests at a time.” Enterprises also get “SAML integrations, kind of integrations for enterprises, and also some group reporting features as well.” Rejah said Beagle hadn’t done enterprise sales or marketing, and the enterprise customers came inbound.

Beagle holds itself to the standard its enterprise buyers ask about, too. In March 2025 it moved its ISO 27001 certification to the 2022 version of the standard.

Beagle Security just took security to the next level! We've upgraded from ISO 27001:2013 to ISO 27001:2022, reinforcing our commitment to the highest security standards. 🔒✅

Beagle Security (@beaglesecure) · March 27, 2025

Bootstrapped to break-even

I asked about the founding team. Rejah’s co-founder runs development, and when I guessed Rejah was the business half, he added the other half: “No, I’m into business and also into the security side of it.” The company’s site names the co-founder as Prathap, chief technology officer, with about 20 years on projects at companies including Hitachi, Toshiba, Schneider Electric, ABB and Panasonic (Beagle Security).

Then the question that surprised me most, given how long they’d been at it. Did they raise money? “No, we haven’t. We are bootstrapped.” That’s rare in security, and I said so: “Wow, that’s unheard of. Well, that means like you’re doing something right because you’re able to sustain the business and sustain salaries and give it the love that it deserves.” Rejah explained how. “We are break-even, in the sense we are, as our development team is in India.” The plan he described for the next stage was to raise, “as most of our customers are from US region. So we plan to move the major part to US and improve their sales and marketing in that side as well.”

That was the plan at the time of recording. Beagle’s about page today lists two offices, San Francisco and Kerala (Beagle Security). Five years in, in June 2025, the company inaugurated a new office and celebrated its fifth anniversary.

From a dream to reality, from a small team to a growing family. Five years of innovation, growth, and dedication culminated in this incredible day - our office inauguration and 5th anniversary celebration! Thank you to everyone who's been part of this amazing journey!

Beagle Security (@beaglesecure) · June 10, 2025

Two years to the first customer

I asked about the proudest day. “Getting the first customer itself.” Both founders came from the technical side, he said, “So at the beginning, we were not aware of the marketing side of the platform.” They built from 2018, ran a private beta, then the lifetime deal, and then a first customer paid. I asked how long that took.

Listen · Jon and Rejah on episode 82, from 15:42

“Two years.” The hardest part, he said, wasn’t the engineering. It was being believed. Beagle does a lot in the back end, with AI, machine learning and algorithms, but a customer only sees the two ends of it.

“They just provide the URL and we provide the report. It’s just like another scanner when they compare.”

Rejah Rehim, at 16:04

What changed it was the wave of attention on AI. “But what made us proud is like when the AI hype is in place, and all at once everybody’s ready to believe that AI system can provide proper reports, proper PT reports, kind of things.” I told him he’d been in the right place at the right time, and I think that’s half of it. The other half is that they’d spent the years before building the thing people were suddenly ready to believe in, which is why they had something to sell when the moment came.

Not replacing the security team

Sasha asked who buys. “Mostly a VP of tech, or CTOs for the small and medium customers, and CISOs when it comes to the big companies.” Then he asked the question I’d want answered before buying any automated security tool: is it for teams that have a security function, or does it replace one that doesn’t exist in-house?

“No, no, like, uh, we are not trying to replace the complete security team.”

Rejah Rehim, at 17:36

Listen · Rejah on episode 82, from 17:36

That “No, no” is the most credible minute on the tape. He’s handed the bigger claim about his own product and turns it down first, then explains the arithmetic. A big company has a lot of applications in development every day, “So testing them on a regular basis without any delays with a small security team, that won’t be possible.” Automation takes “a huge chunk of the testing,” so the people “can focus more on the complex business logic or complex vulnerabilities that only can be identified by the human penetration tester.”

Then a detail I hadn’t heard from other vendors. When a customer believes a flow in their application is too complex for any automated system, “they can record that area and upload to our system, and our system learns it on the go during the testing.” Beagle’s login recorder is a public example of the idea: a browser extension records a sequence once, and the engine replays it to get into the parts of an app a scanner never reaches. “We are not replacing the entire security team, but we can co-work together.”

Someone has to ask for it

Sasha added a point from the buyer’s side, and it’s the one that decides whether a tool like this ever gets used.

“But there has to be someone in the organization who recognizes that, hey, we can introduce a DAST system that will automate a lot of the [pain] points that we have to go through manually today.”

Sasha Sinkevich, at 18:58

Listen · Sasha on episode 82, from 18:51

At a Series A company there usually isn’t a security team to notice. What there is instead is the vendor security questionnaire, which asks for the date of your last third-party pentest and what happened to the findings. That’s often the first moment anyone inside the company looks at how testing gets triggered. Rejah has since put the same idea as four questions, and he says the trigger is the one to fix first.

Ask any security team four things:
↳ who runs your AppSec testing
↳ what triggers it
↳ what does it cover
↳ what comes out of it
Most answers land in the left column. The trigger is the one to fix first.

Rejah Rehim · September 2, 2026

Load the post from LinkedIn

His reasoning in that post is the same as Sasha’s on the tape: if testing only starts when someone outside your company asks for it, the other answers are already decided for you. The scorecard further down asks the same questions of your own program.

A person behind the report

Rejah’s answer to Sasha had a second half, for teams with no security function at all. “So the thing is, even if they don’t have any security team, they can use our platform.” Beagle does “a bit of hand-holding after releasing the report as well.” If a developer needs a finding explained, “One of our security engineers will be helping them to understand that report and fix that in the application.”

“Why we do that is if we do have any glitches in the report, we could identify, and we could improve that in our system by adjusting the system by itself.”

Rejah Rehim, at 19:44

Listen · Rejah on episode 82, from 19:21

That’s a smart loop. Every question a developer asks about a report is either a glitch in the report or a gap in the developer’s understanding, and either way Beagle learns something: the system gets adjusted, or the developer gets the fix explained. It’s also an answer to the most common disappointment with security tools, which Rejah described in his newsletter this summer.

There's a specific kind of disappointment that hits about three months after you buy a security platform. The onboarding went fine. The scans are running. The dashboard is full of findings. But your application isn't any more secure than it was before you signed the contract.

Rejah Rehim · August 14, 2026

Load the post from LinkedIn

His diagnosis in that post is the program around the tool, and I agree. The findings need an owner, a deadline and someone who checks that the fix held. A tool can’t supply those three, and they’re most of what an auditor or an enterprise buyer is really asking about when they ask for your last pentest.

Red teaming in ten years

Sasha asked about the long view: “How do you think the future of red team will look like in 10 years? It’s kind of far from now, but still.” Rejah’s answer starts with the people writing the code. Testing “should be more automated, or it should be more independent of manual work, because the development team is moving forward with vibe coding, with AI-driven development, and a lot of integrations and intelligence in the platform.” Attackers are doing the same, “They are using, like you mentioned, a lot of LLMs to generate payloads, to do the attacks.”

His forecast is AI on both ends of the pipeline, “like in the SAST, to identify the security issues in the code level,” and in automated application testing. “Currently, in the vibe coding, that’s where the developers struggle.” What he expects is “more AI-enabled system in the coming years to, uh, attend or bridge the gap between the development and security.”

Listen · Rejah on episode 82, from 20:12

A year on, the attack surface he was describing has grown a new layer. Rejah’s own map of it this fall puts agents, retrieval pipelines and prompts on the list of things an application test now has to cover.

AI is being added to almost every application right now, and each feature widens the application attack surface.

Rejah Rehim · October 6, 2026

Load the post from LinkedIn

We see the same thing from the code side. AI coding assistants write a growing share of startup code, and the controls that catch their mistakes have to run at the speed they write, which is the argument in our vibe coding security guide. Rejah made the long version of his case in 2023, in a webinar with Pradeep Soundararajan, founder of the bug tracker Bugasura, on the trends shaping application security that year.

The attackers’ models have no guardrails

Sasha picked up the thread Rejah had just laid down, that attackers use AI-empowered systems too, and asked the hard question: “Do you feel the scale is skewed towards favoring attackers versus the blue teams that are trying to defend the systems from being exploited?”

“The creativity in the attacker side is always exceptional. That’s why they are attackers, or in the adversary side.”

Rejah Rehim, at 22:08

Every innovation has a darker side, he said, and AI is no exception. Attackers use the models available today to generate attacks and convert payloads, and then he came back to my guardrail story from earlier.

“Like Jon mentioned, some of the LLMs won’t provide enough details, but they can run their own in the local and do the same thing, and do generate complex attack scenarios.”

Rejah Rehim, at 22:48

Listen · Rejah on episode 82, from 22:37

That’s the asymmetry in one sentence. The refusal I kept hitting lands on the people asking a public model for help, and an attacker running a model locally never sees it. His conclusion follows from it: “So, most cases, the blue teams that’s funded by the company, if they are not using the innovation in that level, it will be a problem, and attackers will win always.”

I’d add one thing from where we sit. Guardrails are worth having, and they were never a control you could rely on, which is why we wrote why AI guardrails won’t stop offensive AI. The controls that hold are the ones you own: scope, authorization in your own code, logging, and a test cadence that finds the hole before an attacker’s local model does. Rejah’s company is one answer to the last of those, and his point is that defenders get the same speed only if they use the same class of tools.

From Mozilla add-ons to OWASP

Near the end I told him I could feel the passion for security and asked where it started. The answer surprised me: he started on the other side.

Listen · Rejah on episode 82, from 23:35

“I was a developer first, and I used to contribute a lot to the open source community, was with the Mozilla Foundation and add-on developer.” Beagle’s about page counts nine Mozilla add-ons to his name. Then the instinct that turned a developer into a tester:

“Always breaking something, or, uh, finding a way to break something, is, uh, always curious, or it’s very interesting for me.”

Rejah Rehim, at 23:48

“That’s why I started contributing to Open Web Application Security Project, OWASP.” His first open source project was “a browser bundle to do the complete penetration testing from inside a browser.” He moved from development into penetration testing full-time, and as a tester he kept writing code “to automate, uh, some parts of the development, or some parts of the testing.” Using those scripts on other websites too is where the platform came from. “That’s how we thought of building a platform for penetration testing automation.” AI wasn’t popular yet, so they started with machine learning and decision-making algorithms, and later “that moved to a complete, [full-fledged] system that can automate anything in the security side.”

It’s a familiar path for the best security founders: a person who automates their own job, then notices everyone else has the same job.

A dog bred for sniffing

The question I’d been holding the whole episode: where did the name come from? “It’s just a dog name.” The founders wanted a name with nothing to do with security, “putting some name that’s not related to security and making it a success.”

“But surprisingly, when we named Beagle, the name was a sniffing dog, which was highly curious and used in hunting.”

Rejah Rehim, at 25:26

Listen · Jon and Rejah on episode 82, from 25:11

I took it from there, which is to say I went straight to airports: “Ah, so it could find, like, bombs [in] luggage or, like, drugs being transported.” Beagles are famous for exactly that kind of work. A name chosen to sound like nothing in the industry ended up describing the product better than most security names do: a curious nose that goes through everything, looking for the thing that shouldn’t be there.

Ship before it feels perfect

My last question was the one I ask every founder: if you could take your younger self out for coffee, what would you say? Rejah went straight to the mistake. “First thing, as I found out, what we did wrong in the first time is spending too much to make the perfect product before it released.”

“Don’t wait long enough to make the perfect product in our mind. That may not be the perfect one in the customer side.”

Rejah Rehim, at 26:16

Listen · Rejah on episode 82, from 25:57

His version of the cure is “fail fast, or release fast as much we could, and get the feedback from the customers, and iterate.” I told him it was spectacular advice, and that sometimes it’s a very hard lesson to learn. It’s also the same lesson as his product. A pentest that waits for a quarter tests the app you had, and a product that waits until it feels perfect is built for the customer you imagined. Both get better by shipping something real, often, and listening to what comes back.

What happened after the tape

The episode aired on November 18, 2025. Since then Beagle has leaned into the word that took over the industry. Its homepage now calls it “The agentic AI pentesting platform for your web apps, APIs & GraphQL,” with a 14-day free trial and a line that it’s “Loved by over 1800+ dev & security teams” (Beagle Security). Rejah’s LinkedIn describes it as used by more than 1,800 customers across 144 countries.

Beagle’s own guides read like the tape, written down. In May 2026 it published what agentic pentesting is, which credits human testers with the creativity Rejah credited attackers with and says plainly that “adversarial creativity is hard to replicate.” The same month came the business logic testing guide, on exactly the gap he described, and in January a guide to SOC 2 penetration testing for the buyers who need a report for an auditor.

Rejah has been writing, too. Beyond the posts above, he writes a newsletter, All Things AppSec, and in September he launched HelixID on Product Hunt, an open-source identity and trust layer for AI agents.

We're live on Product Hunt! 🚀 HelixID is an open-source identity and trust layer for AI agents. Every agent gets a real, verifiable identity (not just a session token), scoped permissions enforced at the point of execution, and a tamper-evident audit trail that holds up across organizations and even offline.

Rejah Rehim · September 10, 2026

Load the post from LinkedIn

The community work kept going as well. Beagle has been the technology partner of HAC’KP, the Kerala Police Cyberdome’s hackathon, for four years running, and this year’s theme was agentic AI for investigations. And in October, Beagle put the company’s whole argument in a sentence.

Security scans can find real vulnerabilities or just fill dashboards no one acts on. That’s the AppSec measurement gap. Our CEO, @RejahRehim , explains why “secure by default” is a direction, not a finish line, and why security must be built into how teams work.

Beagle Security (@beaglesecure) · October 20, 2026

The episode’s video version went up on our YouTube channel on October 18, 2026, and the question it asks is the same one we hear from founders every week. Your next enterprise buyer will want to know when you last tested what you shipped. Rejah’s answer is to test every release and keep people on the business logic, and ours is to make sure the program around the test holds up when the buyer reads it.

Did you catch it? A six-question quiz

Interactive · six questions

Did you catch it?

Six questions on what Rejah, Sasha and I actually said, with the timestamp for each answer. The answers are under each question for anyone reading without JavaScript.

1. How long does Rejah say a manual, end-to-end penetration test takes?

   1. A day or two
   2. About a week
   3. Around 20 to 25 days

   c. "The main thing they can't automate is that it happens in a manual way, and it will take around 20 to 25 days to complete an end-to-end penetration testing in the platform." Transcript, 6:11.

2. What kind of testing does Beagle Security do?

   1. Static analysis of the source code
   2. Dynamic testing of the running application
   3. Network scanning

   b. "No, no, we are not working on the source code side. It's a DAST side of it, like dynamic application security testing." Transcript, 7:45.

3. Why doesn't Beagle use public AI models in its product?

   1. As a security product, it has to avoid the data leak
   2. They're too slow for a pentest
   3. They cost too much to run

   a. "But for that itself, we are not using any public LLMs, because, as it's a security product, we do have limitations to using the public LLMs because of the data leak." Transcript, 9:47.

4. Where did Beagle's training data come from?

   1. Public breach data
   2. Tests run by about 1,700 users of an early lifetime deal, used anonymously
   3. Customers' source code

   b. "We do run an LTD. In the initially, we do have around 1,700 plus users signed up for that, and they ran tests on their web applications. We use those details to train our platform in an anonymous way." Transcript, 11:06.

5. How long did it take to land Beagle's first customer?

   1. Six months
   2. One year
   3. Two years

   c. "Two years." Transcript, 15:45.

6. When a flow is too complex for any automated system, what can a Beagle customer do?

   1. Record that area and upload it, so the system learns it during the test
   2. Nothing, it stays out of scope
   3. Wait for the next release of the product

   a. "they can record that area and upload to our system, and our system learns it on the go during the testing." Transcript, 17:36.

Does your testing keep up with your releases?

Rejah’s whole argument is a question about timing: does the test see the app you’re actually running? This scorecard asks eight questions about your own program. It takes about two minutes.

Scorecard · eight questions

Does your testing keep up with your releases?

Answer for your main product. If two answers fit, pick the lower one.

1. What starts a security test of your application?

   • An auditor or a customer asks for one
   • A date on the calendar, once or twice a year
   • Releases, through the pipeline, plus a deeper test on a schedule

   Rejah's four questions start with the trigger. See Someone has to ask for it.

2. How many releases ship between two tests?

   • We don't know
   • Dozens
   • A handful at most, and the big changes get their own test

   Releasing weekly and testing quarterly leaves "a huge gap in between the tests." See Shipping weekly, testing quarterly.

3. Who tests the business logic, like whether one customer can reach another's data?

   • Nobody in particular
   • Whatever the scanner finds
   • A person, against the flows we've written down, with automation covering the rest

   "Universal automation for all applications with its business logic is too complex." See Where automation stops.

4. Does the test reach the parts of the app behind a login?

   • It tests the login page and stops
   • Some of them, with a shared test account
   • Yes, with recorded or scripted flows for each role

   Beagle's customers record the flows automation would miss. See Not replacing the security team.

5. Where do the findings go?

   • A PDF in someone's inbox
   • A spreadsheet the security lead keeps
   • The bug tracker developers already use, with an owner on each one

   Findings "directly onto the bug tracking systems." See Shipping weekly, testing quarterly.

6. When a developer doesn't understand a finding, what happens?

   • They guess, or close it
   • They ask whoever is around
   • A security engineer explains it and helps with the fix

   Beagle puts a person behind the report. See A person behind the report.

7. How do you know a fix worked?

   • We assume it did
   • The developer marks it done
   • The next test retests it, and we track the date found, fixed and verified

   Buyers now ask how fast you go from finding to verified fix. See Fixing fast is the new cadence.

8. Who decided what your last pentest covered?

   • The auditor's checklist
   • Last year's statement of work
   • Us, from a current list of what we ship, including APIs and admin tools

   Rejah's warning about scope built backwards. See Shipping weekly, testing quarterly.

Testing on the auditor's calendar

Testing happens when someone outside the company asks for it, which is where most startups start. The first fix is the trigger: wire a test into the pipeline for every release, then write down the three or four business flows a person has to check, and who owns each finding.

Testing on one clock, shipping on another

You test regularly, but the releases outrun the tests. Close the gap from both ends: automate the repeatable testing on every release, point the human hours at the business logic, and make sure every finding has an owner and a retest date.

Testing at the speed you ship

Releases trigger tests, people cover the business logic, findings land with owners and get retested. That's the evidence an enterprise buyer is really asking for when they ask for your last pentest, so keep the dates, found, fixed and verified, ready to share.

How far behind is your last pentest?

A pentest is a photo of your app on the day it was taken. This calculator counts how much has shipped since, using Rejah’s estimate of a manual test against yours.

Calculator

How far behind is your last pentest?

How often you release, how many months pass between tests, and how many days a test takes from start to report.

Releases a month Months between pentests Days a manual test takes, start to report

–releases ship between two tests

–more ship while one manual test runs

–tests a year at this cadence

–releases a year that ship with no test of their own

–percent of releases a test ever sees

Between two tests, 24 releases ship, and about 6 more ship while one 22-day manual test runs. Testing 4x a year, 92 releases a year never get a test of their own, so a test sees about 4.2 percent of what you ship.

The 22-day default is the middle of Rejah's "around 20 to 25 days" for a manual end-to-end test on the tape at 6:11, and the other defaults are placeholders. A month here is 30 days. The count treats every release as its own change, which overstates the risk of small releases and understates it for big ones, and a test that runs from the pipeline on every release takes the last number toward 100.

From QBurst to agentic pentesting

Everything on this page sits on one timeline, from Rejah’s first security job to Beagle’s agentic AI platform. Filter it by thread.

Timeline · 2011 to 2026

From QBurst to agentic pentesting

Filter by thread. Dates are from the public record except where marked as part of this show.

1. December 2011QBurst Technologies

   Rejah starts as a web security analyst in Trivandrum, building an internal security testing portal (LinkedIn).

2. August 2013Security architect

   At Digital Brand Group, then at FAYA from 2016 (LinkedIn).

3. August 2014OWASP Kerala

   Rejah becomes chapter lead (LinkedIn).

4. June 2016Effective Python Penetration Testing

   His first book (LinkedIn).

5. November 2017Python Penetration Testing Cookbook

   Later on BookAuthority's list of the best cybersecurity books of all time (LinkedIn).

6. 2018Building starts

   "Building the platform since 2018," on the tape at 4:03.

7. September 2018OWASP project leader

   The SecureTea tool and a risk rating assessment framework (LinkedIn).

8. January 2020OWASP Web Security Testing Guide

   Rejah becomes a core maintainer (LinkedIn).

9. May 2020Beagle Security

   Founded by Rejah and Prathap, with a private beta (Beagle Security).

10. 2021The lifetime deal

    About 1,700 users sign up, and their anonymized tests train the engine, on the tape at 11:06.

11. 2022SaaS

    "A recurring subscription-based platform," on the tape at 4:03.

12. November 30, 2022ChatGPT

    OpenAI releases it (Wikipedia).

13. February 2023AppSec trends webinar

    Rejah with Pradeep Soundararajan of Bugasura (YouTube).

14. September 2024Offensive Security Using Python

    His third book (LinkedIn).

15. February 2025Vibe coding

    Andrej Karpathy coins the term for writing software by prompting an AI (Wikipedia).

16. March 27, 2025ISO 27001:2022

    Beagle moves its certification to the 2022 revision (X).

17. June 10, 2025Five years

    A new office and a fifth-anniversary celebration (X).

18. 2025We record episode 82

    "No, no, like, uh, we are not trying to replace the complete security team."

19. November 18, 2025Episode 82 airs

    This conversation.

20. December 2025Episode 84

    Jack Cable of Corridor on what gets missed when nobody reviews the code (episode 84).

21. January 6, 2026SOC 2 penetration testing

    Beagle's guide for the teams who need a report for an auditor (Beagle Security).

22. February 2026Jira integration

    Findings straight into the tracker (YouTube).

23. May 5, 2026Business logic testing

    Beagle's guide to the flaws scanners miss (Beagle Security).

24. May 13, 2026Agentic pentesting

    Beagle's explainer on systems that reason about what they find (Beagle Security).

25. June 2026Episode 97

    Alexis Lingad on building an AI hacker (episode 97).

26. June 2026Login recorder

    Record a login once, and the engine tests behind it (YouTube).

27. July 28, 2026Scope built backwards

    Rejah on pentest scopes that follow the auditor (LinkedIn).

28. August 2026HAC'KP

    Technology partner of the Kerala Police Cyberdome's hackathon for the fourth year (LinkedIn).

29. September 10, 2026HelixID

    An open-source identity and trust layer for AI agents, on Product Hunt (LinkedIn).

30. October 6, 2026The AI attack surface

    Rejah's AppSec category map (LinkedIn).

31. October 18, 2026Episode 82 on YouTube

    The video version (YouTube).

32. October 20, 2026The AppSec measurement gap

    Scans that find real issues against dashboards nobody acts on (X).

What to do this week

Five things, in the order Rejah would probably do them.

1. Count what shipped since your last pentest. Pull the release history since the report date. If the number surprises you, that’s the gap Rejah built Beagle around.
2. Wire a test into the pipeline. Pick a dynamic test you can trigger from CI/CD on every release, and send its findings to the tracker your developers already use, with an owner on each one.
3. Write down the business logic a person must check. Three or four flows to start: tenant isolation, roles and permissions, payments or approvals. Record the ones behind a login so automation can reach them, and point the human hours at the rest.
4. Check your next pentest’s scope against what you ship. Start from a current list of applications, APIs and admin tools, not last year’s statement of work or the auditor’s checklist.
5. Track found, fixed and verified. Three dates per finding, and a median you can share. It’s the second question your next enterprise buyer will ask, right after the date of your last test.