Web application & API testing
Authentication, session handling, authorization and tenant isolation, input handling, business-logic abuse, and exposed data, mapped against the OWASP Top 10 and OWASP API Security Top 10.
Security Testing & Hardening / Moon Sherpa LabsMOON SHERPA / LABS
Find it first.
Fix it for good.
Every application we build is tested and hardened before it ships, and again as it changes. We offer the same practice to clients: authorized security testing of the systems you own, followed by the remediation work and a retest to prove the fix holds.
The opportunity
Security is part of the build, not a final checkbox.
Most of the systems we work on hold sensitive information: client records, legal intake, CRM pipelines, and the credentials that connect them. An AI agent or MCP server adds new paths into those systems, so the boundary around each one has to be tested as deliberately as it was designed.
We test our own applications and our clients' applications the same way: start from what an attacker could reach, confirm what they could actually do, and close the gap in the code and configuration rather than in a report alone.
What we test
What an engagement covers.
AI agent & MCP server testing
Prompt injection through documents, email, and tool results; tool-permission and scope abuse; data exfiltration paths; and unsafe actions an agent can be talked into, assessed against the OWASP Top 10 for LLM Applications.
Secure code & configuration review
Review of source, dependencies, secrets handling, cloud and hosting configuration, security headers, and CI/CD access, with fixes made where the issue lives.
Hardening & remediation
We do not stop at the finding. We implement or pair on the fix (least-privilege access, input validation, rate limits, logging), then retest to confirm it is closed.
Rules of engagement
Every engagement is defined before it starts.
| Rule of engagement | What it answers | Example |
|---|---|---|
| Authorization | Who owns the system and approves the test? | Signed letter from the system owner, not only the requester |
| Scope | What is in, and what is explicitly out? | Production API and staging app in; third-party SaaS and payment processor out |
| Methods & windows | What is permitted, and when? | No denial-of-service or social engineering; testing on weekdays 9–5 CT |
| Data handling | What happens to anything we access? | Minimum necessary access, encrypted storage, deletion at engagement close |
| Escalation | What if we find something critical? | Immediate notice to a named contact rather than waiting for the report |
A good starting point
You own or operate a web application, API, AI agent, or MCP integration, especially one that handles client data, and you want it tested by people who also build and fix these systems.
A boundary we keep
We only test systems the client owns or is authorized to have tested, within a written scope. We do not perform denial-of-service testing, testing of third-party platforms without their permission, or any work aimed at systems outside the agreement.
Working together
From authorization to a verified fix.
Scope and authorize
Agree on targets, exclusions, methods, test windows, contacts, and data handling. Collect written authorization from the system owner before any testing begins.
Test
Map the attack surface, then combine manual testing with automated and AI-assisted analysis. Every candidate finding is validated by hand before it is reported.
Report
Deliver reproducible findings with severity, business impact, evidence, and a specific fix. Critical issues are escalated immediately, not held for the report.
Harden and retest
Implement or support the remediation, retest each finding, and record what changed so the next release does not reintroduce it.
Our own practice
We hold our own systems to the same standard.
Security testing is part of how we ship every internal and client application: CRM integrations, legal intake systems, MCP servers, and the AI agents that use them.
Before release and after significant changes, we review access boundaries, run dependency and secret scanning, and test the paths an attacker or a manipulated AI agent could take. Findings are fixed and retested before the change goes live.
How we protect our systems and client dataBefore we begin
The useful questions.
What does application security testing include?
It is an authorized, scoped assessment of a web application, API, or AI system to find vulnerabilities an attacker could exploit: weak authentication, broken authorization, injection, exposed data, insecure configuration, and abuse of business logic. Our engagements include validated findings, a specific fix for each, and a retest.
Do you need permission to test our systems?
Yes, always. Before any testing we require written authorization from the owner of each in-scope system, a defined scope with explicit exclusions, agreed test windows, and named contacts. If a system is hosted or operated by a third party, its permission is required too, or the system stays out of scope.
Can you test AI agents and MCP servers?
Yes. This is a growing share of our work because we build these systems. We test for prompt injection through content the agent reads, tool calls that exceed the user's permissions, cross-tenant data access, data exfiltration through tool results, and unsafe actions that lack a review step.
Do you use AI in security testing?
Yes, as an assistant to experienced people, not a replacement for them. We use AI models to help analyze code, map attack surface, and triage results, only against systems within an authorized scope. Every finding is manually validated before it is reported, and client data is handled under the engagement's data-handling terms.
Do you fix the issues or only report them?
Both. Because we are also an engineering studio, we can implement the remediation, pair with your developers, or review your team's fix. Each finding is retested so the report reflects what is actually closed.
How long does a security assessment take?
A focused assessment of a single web application or API typically runs one to three weeks, including reporting. Larger scopes, multiple environments, or AI-agent and MCP testing take longer. Remediation and retest timing depends on the findings.
What happens to our data during testing?
We access the minimum necessary, store any engagement data encrypted with access limited to the people on the engagement, and delete it at the close of the engagement unless the agreement says otherwise. Credentials you provide for testing should be dedicated test accounts that can be revoked afterward.
Let’s make it concrete
What should we test first?
Tell us about the application, who owns it, and what worries you most. We’ll propose a scope and the authorization it needs.
Scope a security assessment