Security model

mog distributes code that runs inside AI agent environments. We take package security seriously. This page describes every layer of protection.

Upload scan pipeline

Every uploaded release is processed asynchronously before it can be published. The scan runs in an isolated worker process. Releases are validated for required structure and manifest correctness, file types are checked against rules that depend on package type (see Package format), artifacts are fingerprinted for integrity, and text content is analyzed for accidental secret exposure and other policy violations. Scan outcomes are reflected in the release record and seller dashboard. We do not publish exact detection rules or thresholds publicly — doing so would make them easier to circumvent. If a problem is found, the seller is notified with an appropriate category (not the raw matched content).

SHA-256 integrity verification

Every package archive is SHA-256 hashed on upload and the hash is stored immutably in the release record. When a user installs a package, the CLI:

1. Requests a signed download URL from the API (requires an active entitlement)
2. Downloads the archive
3. Computes the SHA-256 of the downloaded bytes
4. Compares against the hash stored in the release record
5. Aborts with an error if they don't match

This prevents tampering in transit. Even if an attacker intercepted the download, the hash mismatch would be caught before any files are written to disk.

Signed download URLs

Package archives are stored in private cloud storage with no public access. Download URLs are cryptographically signed with a 5-minute expiry.

To get a download URL, a request must:

1. Present a valid Bearer token with the download scope
2. Have an active (non-revoked) entitlement for the listing

Path traversal protection

During installation, each file path from the zip archive is resolved against the install base directory. If the resolved path escapes the base directory (a "path traversal" attempt), the install fails immediately:

Path traversal detected: ../../etc/passwd

Atomic lockfile writes

If the lockfile write fails after extraction, the extracted files are removed to leave a clean state. This prevents a partially installed package from being treated as installed.

Authentication security

• Device code flow (RFC 8628): No passwords. Authentication happens in a browser with your OAuth provider (GitHub or Google). The CLI never sees your OAuth credentials.
• Tokens: API tokens are hashed (SHA-256) before storage. The plaintext token is only returned once, at issuance time.
• Spend policies: Enforced server-side, not just in the CLI. See Spend policies.
• OAuth state signing: The GitHub OAuth state parameter is HMAC-signed to prevent CSRF and state-fixation attacks during the OAuth callback flow.
• Hashed invitation tokens: Organization invitation tokens are hashed before storage, preventing token extraction from database access alone.

Backend-for-frontend (BFF) pattern

The web application uses a BFF architecture where API tokens are never exposed to the browser. When you sign in via the web, the server issues an internal token on your behalf and proxies all API requests server-side. This means:

• Your API token never appears in browser JavaScript, cookies, or local storage
• All authenticated web requests flow through server-side proxy routes
• Even if an XSS vulnerability were exploited, no API token would be exfiltrable from the client

Audit logging

Authentication events are logged server-side for security monitoring and incident response:

• Sign-in events (provider, user, timestamp)
• Token issuance and revocation
• Failed authentication attempts
• Device code flow approvals

Audit logs are retained for compliance and are not accessible via the public API.

Rate limiting

All API endpoints are rate-limited using a tiered system. Stricter tiers apply to authentication, financial operations, and uploads; public catalog endpoints use moderate limits; a global baseline applies per IP. When a limit is exceeded, the API returns HTTP 429 with a Retry-After header. Exact limits may be adjusted without notice and are not published per route.

Financial operation safety

• Idempotency keys: Wallet top-up and payment operations use idempotency keys to prevent duplicate charges from retried requests.
• Price range validation: Payment intents enforce minimum and maximum amount constraints server-side.
• Transfer tracking: Vendor payouts track transfer status with automatic retry for transient failures.

Transport security

All API and web traffic is served over TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enforced on all production domains, preventing downgrade attacks.

Web application security

The web application sets comprehensive security headers on all responses:

• Content Security Policy (CSP): Strict policy that blocks inline scripts and restricts resource origins. Only allowlisted domains (Stripe, analytics) can load external scripts.
• X-Content-Type-Options: nosniff — prevents MIME type sniffing
• X-Frame-Options: DENY — prevents clickjacking via iframe embedding
• Referrer-Policy: Restricts referrer information sent to external sites

State-changing API endpoints are protected against CSRF. All user-supplied content is escaped before rendering.

Account deletion and data privacy

Users can delete their account via DELETE /v1/users/me or from the dashboard. Account deletion:

• Soft-deletes the user record (preserving referential integrity for orders and reviews)
• Anonymizes all personally identifiable information (name, email, avatar)
• Revokes all active API tokens immediately
• Is irreversible — deleted accounts cannot be recovered

This complies with GDPR right-to-erasure requirements. Anonymized records are retained for financial audit trails.

Data retention

Expired and unused data is cleaned up automatically:

• Expired device authorization codes are purged
• Stale session data is rotated
• Anonymized records are retained only as long as required for financial compliance

Dependency management

Dependencies across the API, web app, and CLI are monitored for known vulnerabilities. Critical vulnerabilities in direct dependencies are patched within 7 days of disclosure.

Data at rest

The database and all package storage use encryption at rest. Sensitive fields (API token hashes, credentials) are never stored in plaintext.

Reporting security issues

If you discover a security vulnerability, please report it privately by emailing security@mog.md. Do not open a public GitHub issue for security vulnerabilities.