Subho Halder’s family learned about his startup after he had already left his job. By then, Appknox had been selected for an accelerator in Singapore, with support to move there. It was a convenient moment to mention that the dependable corporate career had acquired a small geographical complication.
Years later, answering developers’ questions, he recalled the anxiety behind the decision: whether the company would work, whether he could support himself, and whether he would regret staying put. The joke in the sequence is gentle. He had spent his time investigating what computers concealed. At home, he had kept one fairly significant change to himself.
Appknox, founded in 2014, became the long chapter: mobile application security, technical leadership, then the chief executive’s job. In March 2026 he announced another departure. This time the question pulling him away concerned the AI systems being invited into security teams. How could those teams tell whether an answer deserved their confidence?
The question suits a researcher whose career has involved looking beneath an apparently satisfactory surface. An app opens. A browser pastes some text. A scanner produces a report. Each can appear to have done its job. Halder has made a living inspecting the assumptions that allow everyone else to move on.
A small business before the security business
His first commercial experiments belonged to a less imposing internet. Growing up in Kolkata, he made wedding websites using Yahoo GeoCities. His father, an aircraft maintenance engineer at Air India, brought home a PC; a TV tuner card later gave the schoolboy another service to sell, converting videotapes to discs. There were customers before there was a cybersecurity company.
He went on to study Electronics and Telecommunication at KIIT in Bhubaneswar. Robotics drew him into C and assembly programming. These were ways of finding out how a machine responded when somebody gave it instructions, an interest that eventually extended to instructions its designers had not intended.
By 2012, Halder was presenting Android security research with Aditya Gupta at Black Hat Abu Dhabi. Their session, Droid Exploitation Saga, demonstrated the Android Framework for Exploitation, or AFE. The programme described live attacks, access to phone information, and weaknesses in applications. The work put him in front of an audience whose professional habit was to distrust a successful demonstration until it could be repeated.
A year later, his name appeared with Gupta’s and Dev Kar’s in browser security credits for CVE-2013-0926. The issue concerned active content in copied-and-pasted material; Apple described the possibility of a cross-site scripting attack. Even a familiar gesture, copy and paste, had a boundary worth examining. The browser’s ordinary courtesy could carry something less courteous inside it.
What crosses the boundary when the software says yes?
The family heard about Singapore second
Halder left Tata Consultancy Services and joined Harshit Agarwal and Prateek Panda to build Appknox. Its early work concentrated on finding weaknesses in Android applications. Singapore’s JFDI accelerator gave the young company a setting in which to develop the business, and gave Halder a useful opening for that delayed family announcement.
“My family was not aware that I left my job to do a startup,” he recalled. The sentence is more revealing than a polished account of entrepreneurial courage. He understood the appeal of a stable job. He also wanted to build something, and recognised that postponing the decision would leave a question hanging over him.
Finding a vulnerability and running a company require different kinds of persistence. A researcher can establish a failure with a demonstration. A customer then needs to understand the result, assign the repair, and fit the work around the next release. A company has to make that sequence useful often enough that people keep paying for it.
That practical stretch of Halder’s career is visible in the subjects he returned to: testing during development, making a SaaS product ready for enterprise customers, and explaining security to the people building applications. The technical problem kept arriving with a human timetable attached. Someone, somewhere, still wanted to ship on Friday.
Give the developer something useful
At Black Hat Asia in 2017, Halder presented a tool with a surprisingly domestic promise: autocorrect. Devknox highlighted security issues inside Android Studio and suggested fixes. Its conference description explained that it analysed source code within the editor. The intervention happened while the developer was working, close enough to the decision to make a correction practical.
Set that beside the Android exploitation demonstration five years earlier. The two tools addressed different moments in an application’s life. AFE helped expose how a system could be abused. Devknox offered the person writing the code a chance to change course. Read together, the projects suggest a growing interest in what happens after a weakness becomes understandable.
Halder was direct about the organisational difficulty. During his October 2024 Reddit conversation, a developer asked how to persuade engineering teams to care about security. He acknowledged the pressure to favour features and performance. Training could become another checkbox. Putting secure coding practices into the development pipeline gave the subject a place in the work itself.
He also explained Appknox’s use of physical phones for dynamic testing, hosted in a data centre, with users able to interact with the application’s screen while tests ran. Dynamic testing examines software as it operates. The detail matters because Halder’s answer concerned the conditions of the experiment, rather than merely the existence of a scan.
“In cybersecurity, knowing how apps are built helps you understand how to secure them.”
Subho Halder, October 2024
His advice to programmers considering security careers followed the same logic. Learn how applications are built. Understand operating systems and networking. Practise in labs. To an experienced developer returning after a career gap, he stressed understanding why a tool had flagged an issue and how to recognise the problem independently. The tool could help; the explanation still belonged to the practitioner.
There is room for humour in his public self-description, too. His GitHub profile lists street food, drone flying and occasional poetry. Asked what motivated his security work, he said he enjoyed breaking things and understanding how systems worked. The pleasure was in the investigation. A job title could grow quite formal without making the puzzle less entertaining.
An A and a D for the same model
Halder became Appknox CEO in late 2024. On March 5, 2026, he announced that he was stepping down to pursue a new problem in AI security. The work soon included SecLens, a preprint he co-authored with Siddharth Saxena, Kashinath Kadaba Shrish and Thiyagarajan M, submitted to arXiv on April 2.
Its starting point was a disagreement concealed by a single score. A security chief may care intensely about missing a serious vulnerability. An engineering leader may put greater weight on avoiding false alarms that consume developers’ time. Evaluating an AI system for both people requires making those priorities visible.
The study evaluated twelve models on 406 tasks from 93 open-source projects. Its framework used 35 dimensions and five role-specific weighting profiles. One reported result gives the argument a memorable shape: Qwen3-Coder scored 76.3 under the Head of Engineering profile and 45.2 under the CISO profile. In the paper’s grading system, that meant an A and a D.
Whose score is it?
The discrepancy is useful precisely because it makes the purchaser uncomfortable. A leaderboard position can spare a buyer a conversation about tradeoffs. Here, the conversation returns. Which failures matter? Who investigates the alerts? Who carries the consequences of a missed finding? A score becomes more informative when its owner’s priorities are attached.
The next check belongs before the action
Halder was also using AI to write software himself. In April, he published a walkthrough of an approximately 800-line open-source authorship scanner. It read git history to estimate AI’s contribution. He said he had built it because he could not answer the authorship questions for his own codebase. The researcher had found an uncertainty on his own desk.
In May, his essay on supervisor agents proposed a separate process that examines an agent’s intended action before execution. It could allow the action, ask for a correction, flag it for review, or block it. He presented this as a thesis about what the supervision layer needed to become. The proposal moved scrutiny to the moment before software changes something.
His new company, Mattersec Labs, brings that concern into a product called MATT. Halder is co-founder and CEO; Aishwarya Jain is co-founder and chief business officer. The company describes a practice it calls ExploitOps, connecting observed changes to demonstrated weaknesses, repairs, and checks that catch a recurrence. Appknox remains connected as a distribution partner.
Outside that work, his account of everyday life includes cooking from YouTube recipes, long drives, sunsets, and agent experiments on two Mac minis at home. The machines have changed considerably since the TV tuner card. The inclination to see what else they might do has survived.
The family eventually heard about Singapore. Developers got tools that worked nearer their editors and release pipelines. Now AI security teams are being asked to examine the answers they receive, and the actions those answers authorise. Halder’s next business begins with that pause: the small interval in which a reassuring result still has to earn permission to proceed.