Web, API, mobile, and AI security testing.
Source-assisted where available, with every reportable issue reproduced against the running system. Findings include enough code and workflow context for engineers to fix them directly.
// What we test
- Web applicationAuthenticated and unauthenticated paths, tenancy, access control, session and SSO flows, client-side logic, business logic, and third-party integrations.
- API & web servicesREST, GraphQL, gRPC, partner and internal APIs, gateways, service-mesh boundaries, object and function authorisation, schema exposure, SSRF, and abuse controls.
- MobileiOS and Android applications, local storage, key handling, runtime protections, inter-app communication, deep links, transport security, and backend alignment.
- Endpoint & thick clientElectron, .NET, Java, and native clients, privilege boundaries, update mechanisms, local data, IPC and plugins, unsafe file handling, and credential exposure.
- Secure code reviewThreat-model and design review, critical paths such as auth, payments, tenancy and crypto, pre-release control validation, and post-incident recurrence review.
- AI / LLM applicationsPrompt and tool boundaries, agent workflows, RAG pipelines and data exposure, system-policy enforcement, unsafe rendering, and model supply-chain risk.
// Method and evidence
Source-assisted where it improves the test.
- Testing methodManual exploration is paired with targeted automation, schema-aware fuzzing, runtime instrumentation, and code review on the paths most likely to affect users or data.
- AI-assisted triageLocal or private tooling can support variant search, unfamiliar-framework review, and draft reproducers. Every finding is reproduced by a human against the running system.
- Data boundariesSource, secrets, and customer data stay in agreed client, local, or hardened environments. Public AI services are not used without explicit approval.
- Developer outputReproduction steps, code context, affected workflows, severity tied to business and data sensitivity, and a specific fix path.
- Working sessionThe operator who found the issue walks engineers through the evidence, answers implementation questions, and helps validate the proposed fix.
// Delivery
01Discover & scopeComponents, environments, accounts, boundaries, and a clear done condition.
02Threat-led planLikely attacker paths mapped against architecture and prior incidents.
03TestManual work plus targeted automation, source-assisted where available.
04Report & clinicDeveloper-ready findings and a working fix session with the engineering team.
05Retest & closeUsually within 60–90 days. Confirm fixes and look for related variants.
Relevant standards
OWASP ASVS/
API Security Top 10/
OWASP MASVS/
OWASP LLM Top 10/
CWE Top 25/
NIST AI RMF
// Next step
Send what you are shipping.
A repository, architecture sketch, application description, available test accounts, deployment model, and the release or assurance deadline are enough to start.