Security Practices

How the public site is served

The public site is served over HTTPS through Cloudflare. It is built and deployed from GitHub. That statement covers transport and delivery for the public site. Detail on the dated scan result is below, and detail on client material is in Privacy and Data Handling.

Public site architecture, in plain terms

The public site is a static site, built with Astro. Its source is held in GitHub, in the movahedi-ca repo, and it is built and deployed from GitHub, so a change to the live site can be traced to its source. It is delivered over HTTPS through Cloudflare, served by the Cloudflare Worker movahedi-ca, which serves site assets and API and MCP routes. The Privacy API is REST at /api/v1, live and read-only; the MCP server offers 11 read-only tools at /mcp; the Personal Agent Protocol (Poppy) version 0.2 uses the same read-only API and MCP with no sign-in sessions; a free API key is issued via a Cloudflare Turnstile challenge plus API terms acceptance, shown once, never stored on the site side, with no account or email needed. Full stack table, with scope limits beside each claim: Infrastructure: public site stack. In plain terms: GitHub holds the source and produces the site; Cloudflare delivers the site to a visitor over an encrypted connection. Site features, verified on the live site and in the site source, are: search with Pagefind; Privacy API and MCP at /api/v1; and site tools built as client-side tools, where that is true, with most tools running in the visitor browser and free tools running entirely in the browser with no account. Those features are public-site features. They are not a client data platform, a database, a tenant system, or an encryption and key management system, and no such claim is made here. Engagement services are advisory work agreed per engagement, with tools agreed per engagement, not a single product stack. Detail: Infrastructure, Secure Software Development Lifecycle, and Website Accessibility and Privacy Self-Check.

Security contact file

A security contact file is published at movahedi.ca/.well-known/security.txt, with contact mohammad@movahedi.ca and a policy link to the Responsible Disclosure page. The formal policy is the Vulnerability Disclosure Policy. The Encryption Statement states, for the public site, HTTPS through Cloudflare and Strict-Transport-Security with preload from the dated scan, and, for engagement data, provisions confirmed in writing per engagement.

Header scan result

A third-party header scan of the public site returned grade A+ on October 28, 2026, at 00:59 UTC. Headers passed in that scan: Strict-Transport-Security with preload, Content-Security-Policy, Permissions-Policy, Referrer-Policy, X-Content-Type-Options, and X-Frame-Options. Scan link: Security Headers: movahedi.ca. If the site changes, the result can change, and a later scan may differ. This page does not present the grade as permanent.

What the header scan is, and what it is not

This result is a third-party header scan. It is not a penetration test. A header scan checks the security headers a site returns. It does not test the site for vulnerabilities in code, test authentication, test client systems, or review internal controls. Readers who need a different kind of assurance should ask directly at mohammad@movahedi.ca, rather than reading it into the scan grade.

How the company works with client information

The company provides advisory services. It does not operate client systems, and it does not present itself as a processor or host for client data unless a specific engagement says so in writing, in terms agreed for that engagement. Working rules followed in advisory work:

1. Ask only for the information needed for the engagement.
2. Use information received only for the purpose of that engagement.
3. Do not share engagement information with another party without a reason tied to the engagement and, where applicable, the client's agreement.
4. Do not include client confidential material in a public security report. See Responsible Disclosure for the rule that applies to reports sent to the company.
5. When an engagement ends, handling of material received follows the terms agreed for that engagement, including return or delete on the client's instruction.

How this works. A client provides material for a named engagement. That material is used only for that engagement, access is limited to what the engagement requires, and at engagement end it is returned or deleted on the client's instruction.

Accounts and access

The company keeps access to its own accounts and tools limited to the people who need it for the work at hand. When a person no longer needs access for an engagement, that access is removed as part of closing the engagement. A prospective client who needs detail for a specific engagement should raise it during scoping, so it can be answered for that engagement rather than guessed here. Specific security, screening, or insurance requirements are confirmed in writing before work starts, as set out in the Terms of Engagement.

Founder background

The founder's credentials are personal credentials, not company certifications. Detail: Certificates.

Report a security issue

If you find a security issue on the public site, use Responsible Disclosure and the Security Issue Report form. Do not test client systems, other parties' systems, or any system outside movahedi.ca. Do not include client confidential material in a report.

Related pages

• Trust Center
• Privacy and Data Handling
• Responsible Disclosure
• Security Issue Report form
• Security Questionnaire Answers
• Vendor Security Questionnaire

Scope and limits, stated briefly

Where a matter is to be confirmed per engagement, it is stated as such, and it is confirmed in writing for that engagement before work starts. Contact: mohammad@movahedi.ca.