Production AI with real authority
We assess production AI workflows that read sensitive information or perform consequential actions, following retrieval, identity, tools, memory, and tenant boundaries.
Explore AI security assessments →
The people behind DevBrows
Founder-led security for
Founder-led security for
SaaS & production AI.
We help B2B SaaS teams meet defined pentest requirements and assess production AI that can access sensitive data or take action. Our founder-led work makes the tested boundaries, findings, buyer evidence, and next steps clear. We confirm the system, reviewer, scope, and required expertise before an engagement begins.
Our focus
A specialist team with a defined remit.
SaaS teams selling to enterprise
We help founders, CTOs, and engineering leaders meet defined buyer pentest requirements with manual web, API, authorization, business-logic, and tenant-boundary testing.
Explore SaaS pentests →Partners delivering to SaaS clients
We support qualified GRC, vCISO, and product partners with defined SaaS and AI testing, report requirements, scheduling, and client ownership.
Explore partner delivery →
The team
Direct access to the people doing the work.
Jaymeet (Jimmy) Patel
CEO and Founder
Jimmy leads security scoping, assessment, and client discussions. His work focuses on identity, authorization, cloud exposure, and the trust boundaries around AI applications. He is ISC2 Certified in Cybersecurity and is pursuing graduate cybersecurity studies at DePaul University, building on his computer science and business administration background at the University of Illinois Chicago. His published working papers examine cloud identity drift and AI-driven cloud security for smaller organizations.
LinkedIn →Dev Shah
Director of Engineering and Founding Partner
Dev leads engineering and delivery tooling, bringing a builder’s view of web applications, APIs, and AI integrations. His public work includes LLM Arena, a multi-model application with parallel streaming, authentication, provider-error handling, and usage measurement. He has a computer science background from the University of Illinois Chicago and coursework in Model Context Protocol and Google Cloud AI application development. His security practice includes reverse engineering and team CTF challenges.
LinkedIn →
How we work
Scope, evidence, and clear next steps.
Agree the work first
We define the product, requirements, access, deliverables, exclusions, timing, and commercial terms before delivery.
Make the output useful
Testing findings include evidence and remediation guidance. Review engagements produce prioritized gaps and an action plan.
Show the limits
Reports describe what was examined and what remains outside scope. Buyer acceptance and audit decisions stay with the relevant reviewer.
Keep the next step practical
Work concludes with an engineering walkthrough and one scoped retest for SaaS and AI assessments. We propose recurring work when the baseline results and expected system changes justify it.
See the illustrative coverage matrix and report structure → These examples show the format of the work; they are not client results.
Research, engineering, and technical practice
Review the work behind the team.
Cloud identity and authorization
Jimmy’s Identity Drift in Growing Cloud Teams working paper models intended and effective permissions, access relationships, and governance changes using synthetic evaluation.
AI and cloud security research
AI-Driven Cloud Security Frameworks for SMEs examines cloud exposure, identity, AI-assisted security, and governance constraints for smaller teams. It is published as a preprint.
AI application engineering
Dev’s public LLM Arena project connects multiple model providers with streamed responses, application authentication, and per-call metrics. The source makes the implementation available to inspect.
Hands-on security practice
The team’s public activity includes US Cyber Open, Hack The Box Cyber Apocalypse, OmniCTF, and BroncoCTF. Dev’s BroncoCTF write-up describes ARM64 reverse engineering.
Research, public projects, and competition practice show how the team approaches technical problems. The linked papers are preprints or working papers; these materials are not client assessment results. Review the deliverables for your engagement →
Delivery ownership and assessment independence
Founder-led delivery. Independent assessment.
Work with the people responsible
Jimmy leads security work and client scoping; Dev leads engineering and delivery tooling. The proposal names assessment, report-review, and communication responsibilities so your team knows who owns the work.
Know who built, fixed, and reviewed
An independent assessment is separate from the client’s implementation work. Any DevBrows implementation role is disclosed, with appropriate independent review before those fixes are described as independently validated. See how we handle independence →
Start with a scoped conversationBring the requirement.
Bring the requirement.
We’ll define the right scope.
Share your product, buyer requirement, and target date. We’ll confirm the engagement, deliverables, and commercial terms before work begins.