Security

Where your data actually lives

The infrastructure as built, in specifics you can check from outside: where each record is stored, who can reach it, and how long it is kept.

What’s yours and what’s ours

Yours: the phone number, the ad account, the CRM, your customer data, every lead record and every call log. These are created in your name, stay in your name, and you can export them at any time. They stay yours if you ever leave.

Ours: the automation layer that connects them — the workflows, prompts, and tooling. That is Moonstaff’s platform, licensed to you while you are a client, in the same way a CRM licenses you its software without handing over its source code.

What happens on the way out

The system plugs into the tools you already run, so cancelling means we disconnect it. We unhook the integrations, the automations stop, and your phone, CRM, calendar and ad account keep working as they did before, with every contact and call record added while we were live.

Everything of yours stays with you, and there is nothing to untangle. The automation layer is Moonstaff’s, so it stops when the subscription does. We say that here, up front, so nothing about leaving is a surprise.

The governing terms are in the MSA, not on this page.

Where things are stored

• Leads — Amazon DynamoDB in us-east-1, encrypted at rest, with point-in-time recovery enabled. Kept as business records.
• AI-model requests — stored data sits in us-east-1, but a request to the AI model may be processed in another US AWS region: Amazon Bedrock routes inference across US regions.
• Site assistant conversations — Amazon DynamoDB in us-east-1, encrypted at rest. Conversations expire automatically after 90 days: each message expires 90 days after it was sent. A chat transcript has no value after a few weeks and holding visitor conversations indefinitely is a liability, not an asset. Contact details a visitor chooses to give the assistant are kept with their lead, like a form submission.
• Alert email — Amazon SES on a dedicated sending subdomain, so it cannot interfere with your existing mail records.

How access is limited

• Each function runs under its own IAM role, limited to this system’s own tables, configuration, models, mail, timers and logs; the website chat’s role cannot reach the queue the other channels use. Each conversation is reachable only by its own random thread id; the API never lets a visitor name a contact.
• The AI permission is scoped to the two models it uses: one writes the replies, a faster one checks whether a message is an opt-out. A blanket permission would let a compromised function invoke every model in the account.
• The assistant answers only on the websites registered to it, so another site cannot embed it and speak as your business. Its running cost is capped in code — a per-visitor rate limit and a hard limit on the length of each conversation — because a website check on its own does not stop a determined script.
• Deployments from CI authenticate with short-lived OIDC tokens, so no cloud access key is stored in the build system to leak.

What the assistant will not do

It answers only from content approved in writing, refuses to quote prices or terms it was not given, and is instructed to say it does not know rather than guess. On any site whose visitors may discuss minors, contact capture is switched off in that site’s configuration, so the assistant has no tool to save contact details whatever it is told — because a prompt is guidance, not a control.

How we treat your data

• We do not sell, rent or share your customer data, and we never combine it with another client’s. In the lead pipeline described above, no third party gets a copy, except the calendar service (Cal.com) when the assistant books a call for a visitor. Phone calls are different: when the system answers a call, the audio and transcript pass through the phone and voice providers that carry and run it, including Vapi, Deepgram, Anthropic, Google and ElevenLabs — each named in our Data Processing Addendum.
• We do not ask for card numbers, health records, or government identifiers. If your business handles regulated data, that is a scoping conversation before any build, not an afterthought.
• There is no SOC 2 report for this business, and we will not claim one. Ask about any control on this page on the call, or check the ones you can see for yourself below.

Verify some of this yourself

Response headers on this domain show HSTS, a content security policy, frame denial and MIME-type protection. Open your browser’s developer tools on any page here, look at the response headers, and you can check that without taking our word for anything.

Reporting a security problem

If you find a vulnerability in moonstaff.ai or the client portal (portal.moonstaff.ai and portal-api.moonstaff.ai), email hello@moonstaff.ai with what you found, how to reproduce it, and the URLs involved. We reply within three business days, keep you told what we are doing about it, and tell you when it is fixed.

While you test:

• No denial of service, load testing or automated scanning that slows the sites for anyone else.
• No real orders. Do not complete an order, accept terms or sign a document on /start or in the portal: each one creates a real contract and a real login. If a test needs an account, email us first.
• No social engineering, phishing or physical testing of anyone at Moonstaff AI or our clients.
• Use only your own account and data. If you reach someone else’s data, stop, do not keep or share it, and tell us.
• Give us a reasonable time to fix the problem before you publish it.

Services we use but do not run (Stripe, SignWell, Cloudflare, AWS, Google, Microsoft) are out of scope here: report to them under their own programs.

Safe harbor. If you make a good-faith effort to follow this policy, Moonstaff AI LLC will treat your research as authorized, work with you to understand and fix the issue, and will not pursue or recommend legal action over it. There is no paid bounty.