The policies that survive a security review. Reviewed annually, written to be auditable, mirrored on the security page.

Scope

This page is the public summary of how Moonage approaches compliance. The full controls live in our internal security handbook and in the Security Policy and DPA that customers sign as part of the platform agreement.

The customer-facing version of this story is on the security page. This page is the operational view — written for procurement and security reviewers.

Posture

Moonage is early. We build to recognized frameworks from day one and validate them externally as we grow. The status of each is published. Nothing here is aspirational without saying so.

Framework	Status
SOC 2 Type II	In progress; controls implemented, audit window underway
ISO 27001	Roadmap; ISMS in build; targeting external certification within twelve months of GA
GDPR	Aligned; DPA, subprocessor list, and EU-resident processing available
CCPA	Aligned; rights honored, DPA available for California-resident data

Where data lives

Moonage runs on Cloudflare. Workers handle compute at the edge; Durable Objects and D1 hold state.

Enterprise customers pin a dedicated D1 to a region of their choice — EU, US, UK, or APAC. Subprocessors honor the same boundary. The data does not cross it.

Model training

Customer data is never used to train models. We contractually prohibit model providers from training on inputs, outputs, or uploaded files, and we require Zero Data Retention by default. Your data is processed for your request. Then it stops being touched.

The customer-facing FAQ is on the security page.

AI governance

Moonage's product is AI. The governance is the product. We hold ourselves to a small, named set of principles drawn from the OECD AI Principles, the NIST AI Risk Management Framework, and the categorical posture in the EU AI Act. Each principle is paired with the concrete mechanism we use to enforce it, and every mechanism that is still on the roadmap is marked.

Human oversight

Humans stay in charge of the decisions that matter. Sensitive actions preview impact and require explicit approval before execution. Autonomy is granted in narrow scopes and earned over time. The system makes it easy to pause an agent, revert a run, or revoke a permission.

Mechanisms: approval gates on bounded actions; scope-locked agents on first deployment; per-run revert; a kill switch on every agent and integration.

Transparency

Every agent run leaves a record of who initiated it, what tools it called, what it produced, and what context it relied on. The audit trail is the product, not a feature. Outputs grounded in retrieved data cite the underlying sources.

Mechanisms: per-run trace UI; exportable audit log on every plan; source citations on retrieval-grounded outputs; agent decisions tagged as machine-generated, never as ground truth.

Accountability

Every action is tied to a named human initiator. There is no "the system did it" diffusion of responsibility. Workspace owners can scope, audit, suspend, or revoke any agent at any time, and we keep that path one click deep.

Mechanisms: identity on every run; role-based scoping; admin-level kill switches; quarterly access review.

Privacy and data protection

Customer data is encrypted in transit and at rest. It lives in regions the customer chooses, and subprocessors honor the same boundary. Models do not train on customer data. The full posture is in Where data lives and Model training.

Mechanisms: dedicated regional D1 for enterprise (EU, US, UK, APAC); contractual Zero Data Retention with model providers; per-workspace key isolation.

Fairness and non-discrimination

We do not deploy a new agent capability without a written fairness review. The review names who is helped, who could be harmed, and what evidence supports the answer. Customer reports of biased behavior are triaged with the same priority as a security incident.

Mechanisms: pre-release fairness review on every new capability; reported-bias triage path with a published response window; external review on annual cadence (roadmap; first cycle scheduled with our SOC 2 partner firm).

Safety and robustness

Code execution runs inside sandboxed boundaries. Tool calls are scoped to the minimum permissions required. Inputs and outputs flow through guardrails for known abuse patterns, and we red-team new capabilities before they reach production.

Mechanisms: Cloudflare Sandbox SDK for any code the agent runs; least-privilege OAuth scopes per integration; prompt-injection and data-exfiltration guardrails on every agent call; internal red-team review on new capabilities before launch.

Provenance and authenticity

We tag agent output as agent-generated. We do not pass machine-produced text off as human work. Where a claim is grounded in a source the agent retrieved, that source is cited inline.

Mechanisms: consistent agent-output labeling across surfaces; mandatory citations on retrieval-augmented responses; model and version recorded on every run.

Beneficial by design

Every product decision starts with one question: does this leave humans more powerful? If the answer is no, we don't ship it. This is a real veto, not a value statement. It applies to the roadmap, to individual features, and to the way we frame the product to customers.

Mechanisms: every roadmap item carries an explicit answer to the question; failures of the test are documented as such and surfaced in the quarterly review.

What we don't do

We do not deploy autonomous agents into domains the EU AI Act flags as high-risk (employment, education, biometric identification, critical infrastructure) without an enterprise contract that contains the required human-oversight provisions and conformity assessments.
We do not use customer data to train foundation models. Not by default, not by opt-in, not as an upgrade.
We do not surface model output as ground truth. Outputs are tagged, sources are cited, and the human in the loop is named.
We do not ship a capability that has not passed our pre-release safety and fairness review.

Annual AI review

The AI governance section is reviewed every six months by the founders together with the security lead. Findings update the principles, the mechanisms, and the public roadmap. Last review: 2026-05.

Policies

The public summaries of our compliance controls. Each is owned, dated, and reviewed at least annually.

Personnel

References checked before access is granted. Security awareness training at onboarding and annually. Annual performance review with a signed record. Background-screen scope is documented for regulated workflows.

Access control

Least-privilege by default. Admin and standard accounts are separated. Critical infrastructure privileges are distributed across multiple people — no single point of access. Departures: account disabled within one business day; role changes trigger a review.

Information classification

Three tiers — high, medium, low — with handling rules per tier and storage rules per tier. Reviewed quarterly by the security lead.

Vendor review

Any vendor that touches Moonage or customer data is reviewed before contract and annually thereafter. SOC 2 reports or VSAQ questionnaires required. Findings tracked in a risk register.

Change management

Code changes go through peer review with tests. GitHub branch protection enforces it. Infrastructure is codified, peer-approved, and deployed via pipeline. Manual changes outside the pipeline are reviewable and visible.

Incident response

Detection sources include automated monitoring, employee reports to #incidents, and customer reports to security@moonage.ai. The on-call engineer leads response. Mitigate first; prevent recurrence second. Every incident gets a postmortem, regardless of severity. Public disclosure follows the disclosure policy below.

Incident disclosure

Disclose once a fix is available — avoid noise from routine patching. Notify org admins directly when action on their part is required. Public bulletins go out for any incident with material customer impact. Channels: security advisories on the site, targeted email, and in-product banners when warranted.

Disaster recovery

Backups tested at a published cadence. DR plan reviewed annually with a live restoration exercise. Outage detection routes through the incident response policy. RTO and RPO targets are published in the internal runbook and disclosed to enterprise customers under NDA.

Data retention and deletion

Retention windows differ by data type and are documented in the DPA. Customer-initiated deletion is honored within published windows. Suspension for legal hold or forensic investigation is explicit. Destruction methods: cloud resource deletion, key destruction, device reset.

Overview