Security | Blog MONKEE

=== PAGE 42 security ===

Security

Last updated: June 20, 2026

Blog MONKEE stores your WordPress credentials, WP Engine API keys, and the content you generate. We treat that responsibility seriously. This page documents our security posture — in the same honest tone we use everywhere else on this site.

Infrastructure

  • Hosting: Render.com (US region: Oregon (us-west-2)). Render runs on AWS and Google Cloud underneath, providing infrastructure-level DDoS protection and regional redundancy.
  • Database: PostgreSQL 16 hosted on Render, automatic daily backups, 7-day point-in-time recovery.
  • Cache / queues: Redis hosted on Render with persistence enabled (allkeys-lru eviction policy).
  • Static storage: Amazon S3 with versioning enabled on content-generation artifact buckets.

Encryption

  • In transit: TLS 1.2+ enforced on all endpoints. HSTS enabled on all public domains.
  • At rest: PostgreSQL disk encryption (AES-256). S3 server-side encryption (AES-256). Integration credentials stored in additional encrypted columns using application-level encryption.
  • Passwords: bcrypt with cost factor 10. We never store or transmit plaintext passwords.

Authentication

  • User auth: JWT tokens with 24-hour expiry, stored in localStorage with a single session cookie.
  • API authentication: every backend endpoint (except public health/RSS/signup) requires Authorization: Bearer <JWT>. 401 responses trigger automatic client logout.
  • Admin access: internal admin endpoints require a separate HEALER_API_KEY shared secret, scoped to monitoring cron and explicit admin operations only.
  • SuperAdmin role: production dashboard reserves SuperAdmin-gated routes; access requires both role assignment AND a rotating unlock code.

Secrets management

  • No secrets in source code, commit history, or configuration files tracked in Git.
  • All API keys, database URLs, and third-party credentials are injected via Render’s environment variable system at runtime.
  • Credential rotation: quarterly for AI provider keys; immediate on any suspected compromise.

Application security practices

  • Dependency scanning: automated via GitLab’s built-in scanners on every commit.
  • Regex safety: all content-cleaning regexes bounded with explicit quantifiers (e.g. {0,5}) to prevent catastrophic backtracking.
  • Credential leak prevention: WordPress Multisite credential-in-URL auth retry paths redact //user:pass@ patterns from error logs before they ship to Render’s log aggregation.
  • AI output validation: every JSON response from Gemini/OpenAI is schema-validated before use.
  • Rate limiting: per-user rate limits on all AI-generation endpoints prevent runaway cost and abuse.
  • CORS: explicit origin allowlist, no wildcard origins.

Self-healing monitoring — six runbooks, AI escalation, audit log

Blog MONKEE runs a dedicated self-healer service every 15 minutes, completely independent of the main web process. Six automated runbooks cover every common failure scenario:

  • RB-01 — Redis offline → restart backend via Render API
  • RB-02 — Campaign stuck 15 min–48 h → auto-resume via admin endpoint
  • RB-03 — Failed job pile → retry-all via admin endpoint
  • RB-04 — Both AI providers down → engineering email only, no auto-restart
  • RB-05 — Backend unreachable → engineering email only, no auto-restart
  • RB-06 — Ghost campaign (>48 h stuck) → engineering email only, never auto-resumes

For complex incidents, the healer can escalate to Claude Sonnet 4.6 with hard spend limits: $0.50 per incident, 15 tool calls maximum, 10-minute wall-clock timeout. Every incident is recorded in the HealerIncident audit log with timestamps, actions taken, AI summary, and resolution status. Set HEALER_ENABLED=false to halt all runbook actions without removing the monitoring service.

Incident response

  • Detection: self-healer + Render uptime monitoring + external Better Uptime monitoring.
  • Containment: documented runbooks for the 10 most common failure modes.
  • Notification: if user data is materially affected, we notify you within 72 hours by email.
  • Post-mortem: every hard incident produces an AI-drafted post-mortem, reviewed by a human before closure.

What we don’t claim

Blog MONKEE is not yet SOC 2 certified. We are not HIPAA-compliant. We are not FedRAMP-authorized. If you need any of those attestations, Network plans can be architected on dedicated infrastructure — contact sales@monkee.ai.

Responsible disclosure

If you find a security vulnerability, please email security@monkee.ai. Please do not publicly disclose until we’ve had 90 days to investigate and remediate.

Contact

Security inquiries: security@monkee.ai
Data requests: privacy@monkee.ai