Security
How we protect the applications we build and the client data we handle, how our authorized security testing works, and how to report a vulnerability to us.
Questions about this page? Get in touch or email austin@moonsherpa.com.
Our Approach
Moon Sherpa Labs builds software that connects to sensitive systems: legal intake, CRM records, internal business data, and the AI agents and MCP servers that act on them. Security is part of how we design, build, and ship that work.
We also provide security testing and hardening as a client service. Every internal and client application we deliver is security reviewed before release and again after significant changes, and we publish a case study of recent findings. The same practice is available to clients for systems they own.
How We Secure the Applications We Build
- Design review: Access boundaries, data flows, and the actions an AI agent or integration can take are defined before they are built. Consequential actions get explicit permission checks and, where appropriate, a human review step.
- Least privilege: Integrations, API keys, and service accounts are scoped to the minimum access a workflow needs.
- Secrets management: Credentials belong in managed secret stores or environment configuration, not source code. When review finds one in code, we remove it and rotate it.
- Dependency and secret scanning: Committed-secret scanning gates CI on our largest codebases, and we are extending secret and dependency scanning to every repository.
- Pre-release testing: Authentication, authorization, input handling, and AI-specific risks such as prompt injection and tool misuse are tested before a release goes live. Findings are fixed and retested.
- Secure defaults: Applications are served over HTTPS with HSTS and standard security headers.
Access and Account Security
- Multi-factor authentication is required on business, source-control, and infrastructure accounts.
- Access to client systems and data is limited to the people working on that engagement and removed when the engagement ends.
- Production and client environments are accessed only for an authorized purpose.
Client Data Handling
- We access the minimum data necessary to perform the work.
- Client data is stored only in approved, encrypted services and is not copied to personal devices or unapproved tools.
- At the end of an engagement, client data we hold is returned or deleted unless the agreement requires otherwise.
- Client data is never used to train AI models.
Responsible Use of AI in Security Work
We use AI models, including advanced models from Anthropic, to assist with code review, attack-surface analysis, and triage. That use follows the same rules as the rest of our work:
- Authorized targets only: AI-assisted testing is performed only against systems we own or that a client has authorized in writing, within the agreed scope.
- Human validation: Every finding is validated by a person before it is reported or acted on.
- No offensive work outside an engagement: We do not develop or deploy malware or ransomware, perform denial-of-service attacks, or test systems without authorization.
- Provider safeguards: We operate within our AI providers' usage policies and accept the data-retention and monitoring terms they require for security use cases.
Client Security Testing Engagements
Before any client testing begins we require:
- Written authorization from the owner of each in-scope system, and from any third-party host or operator where required.
- A defined scope listing in-scope targets and explicit exclusions.
- Rules of engagement covering permitted methods, test windows, and named emergency contacts.
- Data-handling terms for anything accessed during testing.
Critical findings are reported to the client's named contact immediately rather than held for the final report. See Security Testing & Hardening for more about the service.
Incident Response
If we identify a security incident affecting a client system or client data, we contain it, investigate, and notify the affected client without undue delay, along with what happened, what data may be involved, and the steps taken. We cooperate with the client's own incident-response and notification obligations.
Reporting a Vulnerability
If you believe you have found a security vulnerability in moonsherpa.com or in an application operated by Moon Sherpa Labs, please email austin@moonsherpa.com with "Security" in the subject line. Include a description of the issue, the steps to reproduce it, and the potential impact.
- We aim to acknowledge reports within three business days and will keep you updated as we investigate.
- Please give us reasonable time to fix the issue before disclosing it publicly.
- Do not access, modify, or delete data that is not yours; do not degrade service availability; and stop testing and report as soon as you confirm an issue.
- Social engineering, physical attacks, and denial-of-service testing are out of scope.
We will not pursue legal action against researchers who act in good faith and follow these guidelines. Our machine-readable contact details are published at /.well-known/security.txt.