AI Agent Security & Compliance at Melaya: SOC 2, GDPR

Melaya is a governed agent execution platform paired with a trading engine: operators design multi-agent workflows, connect them to real systems, and route trading decisions through a normalized Rust execution layer. Because our agents take consequential actions, our security model rests on three commitments. Isolation is the default: every tenant is separated at the database row level and every pipeline runs in a hardened sandbox. External writes require human approval: an agent cannot send, post, or place an order until an operator authorizes the exact arguments. Everything is recorded: a hash-chained audit log and full run telemetry make every action reconstructable after the fact. We add a fourth commitment for reviewers: an honest posture. This document states plainly what is implemented, what is partial, and what is roadmap, and makes no certification claim we have not earned.

Contents: posture at a glance, tenant isolation, encryption, data residency, audit logging, backup and disaster recovery, penetration testing, SOC 2, ISO 27001, GDPR, shared responsibility, and how to work with our team.

Security posture at a glance

Tenant isolation, access control & sandboxing

Isolation is enforced at three independent layers: application-level permission checks, row-level security (RLS) in the database, and operating-system sandboxing around agent code. The database is the authoritative enforcement point. The application role runs NOBYPASSRLS, and RLS is forced (FORCE ROW LEVEL SECURITY) across 44 tables in the agents and cex schemas under 117 distinct policies, so a policy applies even to a table's owner. A per-request middleware sets melaya.user_id and melaya.role session GUCs before any query executes. Application procedures do not apply tenant filters themselves; the database policies do. The connection pool issues DISCARD ALL on release, so GUC values cannot carry over between tenants. Migrations run as the database superuser; the application service never does. The rls-verify.ts verifier exercises cross-tenant read and write scenarios per table plus a GUC-leak regression and must exit clean before any release; these figures were confirmed against the live production database on 2026-07-04.

Every session begins with a credential exchange against agents.users. Passwords are hashed with bcrypt at cost 12; on success the server issues a stateless JWT (seven-day expiry) verified before any procedure is reached. TOTP-based MFA (RFC 6238) is available to all users and required for sensitive operations such as exchange API key addition; the secret and recovery codes are stored in encrypted columns, and a short-lived challenge row (five-minute TTL, atomic consumed-at fence) gates JWT issuance after the password step. New accounts are provisioned with zero effective permissions and remain inactive until email verification; verification tokens are stored only as SHA-256 hashes, and no JWT is issued at registration. Rate limiting on authentication endpoints (login, registration, password reset, and MFA verification) is Redis-backed, distributed, and fails closed: 20 attempts per IP per 15 minutes, and if the rate-limit store is unavailable, authentication returns 503 rather than admitting unlimited attempts. This release fixed a mount-path defect that had prevented the limiter from firing on auth requests: the middleware is mounted under a route prefix that the framework strips from the request path before the handler runs, so the procedure-name extractor found nothing to match and skipped the auth limiter. The extractor now tolerates the full URL, the full path, and the mount-stripped form, and the caller passes the original request URL; a unit table covers the stripped, full, batched, and API-app forms. Batched requests cannot circumvent per-procedure limits. JWT signing keys support a rotation window via an ordered key list; expired tokens are always rejected regardless of key.

Agent pipelines execute as sandboxed subprocesses. Plaintext credentials never cross the browser boundary: the browser receives a single-use 256-bit opaque handle (60-second TTL), the agent service redeems it over a loopback-only call gated by an internal shared secret, passes the decrypted values to the subprocess as environment variables, and immediately invalidates the handle. The subprocess environment is a filtered copy built from a strict credential-prefix allowlist; PATH and PYTHONPATH injection are blocked.

One gap is acknowledged openly: all cloud subprocesses currently share a single OS service account, so a concurrent subprocess could in principle read another subprocess's environment. We accept this under the current trusted-tenant model (pipeline code is server-generated and customers are authenticated, paying tenants). UID namespace isolation per run is a documented roadmap item, contingent on the threat model expanding to adversarial users or user-supplied code.

Any tool performing an external write action can be placed under human-in-the-loop (HITL) gating; the middleware fails closed, so a gated tool never fires without approval. The full trail is described under Audit Logging & Observability.

Implemented today

• Two global roles (admin, user); non-admin access flows through a six-layer permission stack.
• Ten boolean capability flags on agents.users (including can_create_pipeline, can_trading, can_edit_pipeline_code); trading flags default to false. Enforcement reads the column live on every call, so a flag change takes effect without token rotation.
• Resource allow-lists (allowed_tools, allowed_agents, allowed_template_ids) on both user and project; effective access is the intersection.
• Per-pipeline permissions (view, edit, run) as a JSONB map, plus a project-owner-managed deny-list (agents.pipeline_team_visibility) that wins over admin grants.
• Project membership roles viewer, editor, owner; invite links can confer only viewer or editor, never owner.
• Forced RLS across 44 tables in the agents and cex schemas under 117 policies (live-verified 2026-07-04), covering agents.runs, agents.spans, agents.messages, agents.input_requests, agents.tool_approval_responses, agents.pipeline_templates, agents.email_tokens, agents.referrals, and the cex.* tables among others. BEFORE INSERT triggers attribute new rows to the owning run's user, so a subprocess cannot supply a false user_id. Template promotion to community visibility and validation flags are admin-only, enforced by the pipeline_templates_guard trigger in addition to the policy.
• Per-pipeline Docker containers with hardened flags: read-only root filesystem, full capability drop, per-tenant UID allocation in isolated numeric ranges, a 37-syscall seccomp deny-list, and memory, PID, and tmpfs limits. The service unit adds MemoryMax=12 GiB, CPUQuota=600%, TasksMax=4096, ProtectSystem=strict, RestrictNamespaces=yes, NoNewPrivileges=yes, and PrivateDevices=yes.
• Per-user state directories injected at spawn time, preventing tool-session leakage between tenants; a Redis-backed cluster concurrency cap (default 20 concurrent runs, auto-expiring) and a per-user rolling rate limit prevent pool exhaustion by a single tenant.
• Local execution authenticated with scoped runner tokens (agents.runner_tokens), distinct from user JWTs.

Roadmap

• UID namespace isolation per pipeline run (closes the shared service-account gap).
• Egress enforcement: outbound traffic is logged today (observation-only firewall rules); DROP enforcement is pending allowlist finalization.

Encryption in transit and at rest

All client-to-platform traffic terminates at the CDN edge over TLS 1.2 or 1.3 (1.0 and 1.1 disabled). Cipher selection follows the Mozilla Intermediate profile: TLS 1.3 restricts to the three standard AEAD suites; TLS 1.2 to ECDHE key exchange with GCM or ChaCha20-Poly1305 only. Static RSA, CBC-mode, RC4, 3DES, and export-grade ciphers are rejected; every accepted suite provides forward secrecy. HSTS is set to two years with includeSubDomains and preload, and OCSP stapling runs at the edge. Response headers X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy are live on the public site (confirmed 2026-07-04). Content Security Policy now ships on both surfaces: the API sends a restrictive default-src 'none' policy, and this release adds an enforcing CSP to the public web application. The application CSP is permissive on script and style (inline is required by the current front-end runtime) but tight on the exfiltration-critical directives: connect-src is allow-listed to our own backends plus the sign-in and payment providers, and object-src 'none', base-uri 'self', and form-action are locked. Connector endpoints are not listed because those calls are made server-side. A move to a nonce-based edge header is a hardening follow-up.

Internal service authentication does not use mutual TLS. Instead, every API request is verified against a signed JWT per call; the Node proxy authenticates to the Python strategy worker with a shared-secret header, and the worker binds to loopback only; internal API key resolution uses constant-time comparison to prevent timing attacks; and WebSocket API keys are cached in Redis keyed by their SHA-256 hash, so a Redis dump cannot be replayed directly. Administrative surfaces sit behind Cloudflare Access in addition to their own credential checks.

At rest, our model is application-layer field encryption. Every sensitive value written to Postgres or the secrets vault passes through an envelope encryption service using AES-256-GCM before it reaches storage. This means a compromise of the database alone, or of the vault alone, does not yield plaintext credentials; an attacker also needs the envelope key held by the server process. All credentials in the production database have been migrated to this format and verified.

We state the gap plainly: both block devices on the production instance are currently unencrypted at the disk layer. This is the open CC6.8.f item in our SOC 2 mapping, and it carries a real residual risk: runtime secrets, including the envelope master key, live in a root-only file on the unencrypted system disk, so a privileged snapshot of that disk would expose operational secrets in plaintext. Volume-level encryption (Roadmap below) directly closes this gap. Neither remediation option has executed as of this writing.

Implemented today

• Envelope format: AES-256-GCM, 256-bit key, 12-byte random IV per wrap, 16-byte authentication tag, versioned wire format with a 4-hex-character key ID supporting multiple concurrent keys.
• Envelope coverage: all per-user connector secrets (agents.credentials.encrypted_value), project-scoped shared secrets (agents.project_credentials.encrypted_value), TOTP secrets and recovery codes on agents.users, and exchange trading credentials (API key, secret, passphrase), which are envelope-wrapped by the server before being handed to the vault. Exchange keys additionally carry a SHA-256 hash in the lookup column; plaintext is never returned after storage.
• Password hashes: bcrypt, 12 rounds. Email verification and password-reset tokens stored only as SHA-256 hashes; the raw token appears once in a transactional email and is never persisted.
• Secrets management: a self-hosted Infisical vault, behind Cloudflare Access, storing envelope ciphertext rather than plaintext credentials. Connector and OAuth secrets live only in Postgres and do not flow through the vault.
• Zero-downtime key rotation: a new key is prepended to the key list, existing rows are re-wrapped by a migration script, and the old key is dropped.
• Credential injection into pipelines uses the single-use opaque-handle flow described under Tenant Isolation; plaintext never crosses the browser boundary.

Roadmap

• Data-disk encryption (operator-chosen path, not yet executed): LUKS2 with AES-XTS-Plain64 and an Argon2id KDF on the data disk, migrating all sensitive volumes (database data, vault, CI, source control, runtime secrets, backup repository) onto the encrypted mount. The passphrase is held only in the operator's password manager with a recovery key in a second LUKS slot; after any reboot the disk stays locked until the operator opens it manually over SSH, so a leaked snapshot yields ciphertext only.
• System-disk encryption via the cloud provider's KMS-backed snapshot-copy-encrypted flow, deferred until the LUKS path has been stable for 30 days and a SOC 2 Type I review determines whether it is required.

Data residency

Melaya's production infrastructure runs on a single dedicated host in the Asia Pacific (Singapore) region. All primary operational data (user accounts, strategy configuration, order execution records, audit logs, and encrypted exchange credentials) lives on that host. The database (PostgreSQL 16) and cache layer (Redis 7) are co-located on the same host and are not reachable from the internet: the host firewall permits only TLS, HTTP redirect, SSH, and git-over-SSH; every other service, including the database and cache, is blocked at the firewall and additionally bound only to loopback or the internal container network, giving two independent layers of isolation.

All browser and API traffic enters through Cloudflare, which terminates TLS, enforces HSTS, applies WAF rules, and performs DDoS mitigation. Cloudflare sees request metadata, IP addresses, and headers; it does not decrypt or store application-layer payloads, trade data, or credential material, and no application data is cached at the edge. Operations-only surfaces are additionally gated by Cloudflare Access with email-OTP, so they are never directly internet-reachable. Logs and host metrics ship off-box to Grafana Cloud's Singapore stack under a signed DPA and SCCs, keeping the off-box audit trail in the same geographic region as the production host.

The strongest residency control we offer is the local runner. Pipelines can execute in cloud-side sandboxed containers or on the customer-controlled local runner (@melaya/runner). When a pipeline runs locally, the Python subprocess executes on the customer's own hardware: pipeline code, documents, RAG indexes, and any credentials or context the pipeline touches are processed on the customer's machine and never transmitted to Melaya's cloud. The runner holds a Socket.IO connection to the platform API for control-plane signaling only (start, status, spans); artifact content does not traverse that channel. Pipelines using local model runtimes (Ollama, LM Studio) or tools requiring a residential IP or browser session are rejected server-side unless a local runner is paired, so sensitive workloads can be kept entirely on hardware the customer owns.

The agent memory system (static context, vector RAG on ChromaDB and Qdrant, cross-run crew memory, working-memory compaction) namespaces all persistent stores per pipeline and per user; on cloud runs those files reside on the Singapore host, on local runs they reside on the customer's machine. Database-backed memory tables are covered by the row-level security regime described under Tenant Isolation.

When a pipeline routes to an external language model (OpenAI, Anthropic, Google), pipeline content flows to that provider as the user's selected processor. We surface this routing choice in the pipeline builder, and provider selection, retention, and training policies are the customer's responsibility under the user-selected routing model (Privacy Policy Sections 2.3 and 12). Customers who require that no content reach an external LLM provider can pair the local runner with a local model runtime, in which case all inference runs on customer-controlled hardware.

Subprocessor geography

For subprocessors outside the EEA, transfers are covered by Standard Contractual Clauses (Module 2 or 3 as applicable), supplemented by our technical measures: envelope encryption for credentials, TLS in transit, and database-enforced row-level security. Enterprise customers receive at least 15 days' written notice before material subprocessor changes (see GDPR section).

Roadmap

• Offsite backup replication: migrating the restic repository target to an offsite object storage bucket in an operator-configured region under WORM retention (a single configuration change, tracked under SOC 2 CC9.2).
• Nightly Cloudflare drift check: automated terraform plan in CI to detect edge configuration drift from the infrastructure-as-code scaffold.
• Subprocessor RSS feed for programmatic change notification.
• Error telemetry provider (operator-configured region, with SDK-level PII scrubbing before transmission); planned, not yet deployed.

Audit logging & observability

Our audit trail is designed so that any consequential action can be reconstructed, and so that tampering is detectable. All state-changing authentication and credential operations are written to the hash-chained agents.audit_log in a SERIALIZABLE transaction. Each row carries an HMAC-SHA256 hash of the actor IP, keyed by a dedicated HMAC key so no raw IP is stored, and a SHA-256 chain hash linking to the previous row, making post-hoc deletion or edits detectable. Sensitive field values are redacted by a denylist before the row is written. A companion agents.audit_log_tombstone table records lawful removals (for example GDPR erasure) without mutating the chain: the tombstoneActor writer is invoked on every deletion path (admin purge, agent-studio user delete, and the self-serve account-deletion route), so an erased subject is tombstoned while the append-only hash chain is left intact. A periodic verification script asserts chain integrity.

The HITL approval trail is the heart of the write-action audit story. When an agent invokes a gated tool (gmail_send, slack_post_text, melaya_place_order, luma_register_event, and others), the middleware pauses execution and writes a pending row to agents.input_requests; the tool does not fire until an operator acts. The decision is recorded in agents.tool_approval_responses, capturing the request ID, run ID, user ID, tool name, a snapshot of the agent's proposed arguments, the decision (approved, rejected, or killed), a free-text reason, the decision timestamp, and any operator-supplied argument overrides. Together the two tables preserve both what the agent proposed and what the operator authorized: a non-repudiable record for every sensitive write action. The middleware is fail-closed; if the approval request cannot be delivered, the tool never fires.

Every pipeline execution is persisted across four linked tables, and the HITL tables extend the chain for gated calls:

The run_id key is present across all five tables, so a single query reconstructs the complete history of any pipeline execution, including every human decision that shaped it. A NULL finish timestamp on a reply indicates a crash or in-flight turn, so gaps are visible rather than silent.

Production deploys are attributable end-to-end. A commit is pushed to the internal source forge (behind Cloudflare Access, SSH-only for git operations); the CI job triggers via a pinned SSH key restricted to a single wrapper script that accepts only an explicit command pair against a service allowlist, rejecting and logging anything else; the deploy script writes a BUILD_INFO provenance file (full commit SHA, engine version, addon version and SHA-256 hash) and appends to a deploy audit log that ships off-box in real time. Direct invocation of the deploy script bypasses the deploy log; the runbook reserves that path for incident recovery only.

Access to the off-box log platform is controlled at the account level. Within the application, agents.audit_log and the HITL tables are protected by row-level security scoped to the row owner and platform admins.

Implemented today

• Hash-chained agents.audit_log covering logins, MFA challenges and verifications, password changes and resets, OAuth sign-ins, account deactivations, API key lifecycle, access grants, and all admin.* user lifecycle mutations with the acting administrator's ID.
• New-device login detection: an auth.new_device_login audit event plus a user alert email.
• Full run/reply/message/span telemetry with OTEL-compatible span records and token accounting.
• HITL approval records preserving agent proposal, operator decision, and argument-level overrides.
• Centralized forwarding of all security streams (audit events, RAG operation events, nginx access and error logs, container stdout, sudo command log with session I/O capture, egress connection logs, daily container image digest drift alerts) to Grafana Cloud Loki via Grafana Alloy, a persistent service included in the boot health check.
• Deploy audit log with commit-level BUILD_INFO provenance.
• Documented log-stream retention in the internal Data Retention Schedule: the system journal is retained one year, off-box application logs roll on a short window, and the audit-log archive is retained long-term under a WORM lock.

Roadmap

• Cloudflare Access audit log ingest is wired but currently returns an authentication error pending an API token permission scope; it does not yet deliver live events.
• Offsite log and backup retention destination (shared with the Backup & DR roadmap).

Backup & disaster recovery

Nightly automated backups cover four categories: the Postgres databases (both the agents schema for users, credentials, MFA state, audit log, and subscriptions, and the cex schema for trading strategies, backtest jobs, and performance history); a project-level export of the secrets vault, envelope-wrapped before storage so the export is unintelligible without the platform envelope key; source forge and CI configuration; and platform configuration files. All backup artifacts are compressed, checksummed, and encrypted with restic. Backup encryption keys are stored separately from the repository and replicated into a sealed offline escrow.

One honest qualifier: the offsite destinations in this table are the designed targets. Today the restic repository is on-host and in-region; migrating it to an offsite object-storage target is a single configuration change pending an operator decision on the provider, tracked under SOC 2 CC9.2.

Restore capability is verified, not assumed. A weekly automated melaya-backup-verify job runs a restic integrity check and a spot-restore of the most recent backup to a scratch directory. The full restore drill, defined as an annual exercise into a throwaway environment in a secondary region, restores the most recent nightly dump, applies every migration in sequence (migrations are idempotent), runs the full verifier suite (rls-verify, audit-log-verify, totp-verify, envelope-verify, jwt-keys-verify, rate-limit-verify, all of which must exit clean), smoke-tests an authenticated login with a seeded account, and records wall-clock time from restore start to all verifiers green as the measured RTO. Drift of more than 20% against target is a finding requiring remediation; each drill produces a written attestation. The first drill has not yet been performed; it is scheduled for 2026-07-15.

RTO and RPO targets

The cex targets are tighter than agents because a missed window of strategy configuration could leave live orders running against stale parameters.

We operate from a single primary hosting region. We state this plainly because reviewers verify infrastructure claims. Compensating controls: continuous WAL archiving gives point-in-time recovery within a 14-day window for scenarios short of full region loss; a synthetic health probe from a secondary region triggers the SEV1 incident workflow within 60 seconds of detection, with DNS failover (60-second TTL) as the recovery path; and dump freshness is monitored, paging on-call if the most recent dump is older than 26 hours. Once the offsite dump target is live, a total primary-region loss falls back to the offsite dump, with data loss bounded by the nightly cadence and a worst-case RTO of approximately 24 hours, documented and accepted as a trade-off for a non-systemic-finance platform and disclosed in the Business Continuity Plan.

Backup procedures are wired into incident response: the Incident Commander may order a forensic database snapshot to a dedicated evidence bucket before any remediation runs, restores follow subsystem-specific runbooks (restore-agents, restore-cex), and for credential-exposure incidents the audit log chain is verified immediately with verify-audit-chain, where a hash mismatch is itself a SEV1 indicator. Quarterly tabletop exercises are defined to include at least one restore-scenario walkthrough, with records committed to the evidence repository.

Implemented today

• Nightly encrypted restic backups across all four data categories, with keys escrowed offline and separately from the repository.
• Weekly automated restic integrity check and spot-restore.
• WAL archiving with 14-day point-in-time recovery; 90-day dump retention; 12-month monthly snapshots.
• Daily WORM export of the audit log with an immutable retention lock.
• Secondary-region health probe, DNS failover path, and dump-freshness alerting.

Roadmap

• First full restore drill (scheduled 2026-07-15) and first tabletop exercise on the same date.
• Offsite restic repository target (single configuration change, pending provider decision).
• Multi-region resilience: RAG index replication and promotion of the secondary-region runbook into automated failover. Until that ships, the approximately 24-hour worst-case RTO for full region loss is a documented, accepted risk.

Penetration testing & vulnerability management

No external penetration test has been completed to date. We say that first because it is the fact reviewers care about most. What exists today is an internal baseline that a third-party tester is expected to exceed, not rediscover: a security regression suite (pentest_attack_primitives.sh, committed 2026-05-20) exercises the pipeline sandbox against eleven attack primitives, including cross-tenant filesystem access, per-tenant kernel-level UID isolation, seccomp filter enforcement, config-code injection by non-privileged users, project-shared pipeline cross-member visibility, HITL approval forgery, environment secret extraction paths, container cancel-path races, and runaway resource exhaustion. All eleven tests pass on the current production build. A validation matrix of twelve topology-by-provider-by-HITL combinations confirmed that the container isolation controls described under Tenant Isolation are present on every spawned run.

Independent testing. Ahead of a formal engagement, an external adversarial review of the platform was fact-checked against live production evidence. Its findings were reproduced and remediated in this release: authentication rate limiting (a mount-path defect that had disabled enforcement, now fixed and covered by a unit table), the absence of a Content Security Policy on the public web application (now shipped), and a set of minor least-disclosure items (collapsing distinct API-key error reasons into a single generic response, making the CORS credentials header conditional on an allow-listed origin, removing an internal engine tag from a public WebSocket frame, and hardening security.txt). The review also confirmed the strong controls already in place: bcrypt at cost 12, TOTP multi-factor authentication, forced row-level security with a NOBYPASSRLS role, and the AES-256-GCM envelope encryption scheme. This internal fact-check does not substitute for the independent third-party penetration test described below, which remains outstanding.

The external engagement is scoped and pending. The scope document (version 1.1) covers the application surface, the agent pipeline sandbox, co-resident infrastructure, and the Cloudflare zone configuration. Vendor selection criteria require CREST accreditation and prior experience assessing crypto and AI platforms. The engagement is gated on two prerequisites: reconciliation of the Cloudflare edge infrastructure-as-code against the live zone, and completion of a 30-day burn-in of the sandbox surface that began 2026-05-20. Once those gates clear, an engagement letter will be signed; a report summary will be retained on receipt.

Implemented today

• Weekly Trivy scan of every running container image against the current CVE database, with output shipped to the off-box log sink for retention and alerting.
• Daily image digest drift detection against a canonical registry; a silent upstream image rotation raises an alert within 24 hours.
• On every CI build: npm audit --production, a gating Trivy filesystem pass that blocks on fixed HIGH and CRITICAL findings, a full-surface non-gating Trivy pass, and gitleaks secret scanning (also a pre-commit hook, run against full repository history).
• OS security patches applied continuously via unattended-upgrades on the Ubuntu 24.04 host, with automatic reboots in a defined maintenance window.
• Remediation SLAs, applying to automated scan findings and to future external pentest findings alike: CRITICAL 48 hours, HIGH 7 days, MEDIUM 30 days, LOW 90 days. SLA misses are logged in the quarterly patching review.
• A responsible disclosure program (policy v1.0, shipped 2026-04-15), published at melaya.org/legal/security, covering the application surface and all Melaya-controlled subdomains. Contact: [email protected]. Written safe harbor for good-faith researchers, covering US, UK, and EU computer-misuse statutes and relevant civil theories. Triage SLA: acknowledgement within five business days, initial severity assessment within ten business days of acknowledgement, remediation per the severity ladder. Rewards today are Hall of Fame credit and platform access; a cash bounty table (CRITICAL $5,000 / HIGH $1,500 / MEDIUM $400 / LOW $75) activates alongside the first SOC 2 Type II engagement.
• Findings flow: confirmed findings route through the incident response severity ladder. HIGH and CRITICAL findings require a tracked remediation PR or a signed risk-acceptance memo within SLA; MEDIUM findings receive an owner and due date. Corresponding SOC 2 control rows are updated as findings close.

Roadmap

• First third-party penetration test: scope drafted, vendor shortlist committed, engagement not yet signed, gated on the two prerequisites above.

SOC 2 readiness

Melaya has not completed a SOC 2 Type I or Type II examination, and no audit has been conducted by a third-party auditor. Our controls are mapped to the 2017 AICPA Trust Services Criteria for Security (CC1 through CC9), and that mapping is a readiness artifact: it accurately represents what is implemented in production today and what remains on the roadmap. It is not an attestation.

Readiness snapshot (2026-07-04 self-assessment of the Security Common Criteria, not independently examined): across 66 mapped sub-controls, 43 are live (an implemented control), 10 partial (shipped but gated on a drill, an infrastructure step, or a publication), and 13 planned, with no unmitigated gaps. The largest cluster of partials clears on the 2026-07-15 incident-response tabletop and restore drills; the remaining planned items are governance and elapsed-time work (external examination, independent oversight, full-disk encryption, recurring management reviews) rather than missing technical controls.

The mapping scope covers the Melaya platform: the agentic framework, the Melaya Engine, billing integration, tenant-isolated retrieval indices, the Postgres database, and the Redis cache. Co-resident services on the same production host (CI, source control, and the self-hosted secrets vault) are explicitly in scope as neighbours with enumerated compensating controls. Third-party language model providers and exchange venues selected by customers are out of scope; they are customer-configured subprocessors with their own compliance programs.

The technical control families are described elsewhere in this document: authentication, RLS, and sandboxing under Tenant Isolation (CC6); TLS and field encryption under Encryption (CC6.7, CC6.8); the audit trail under Audit Logging (CC7.1); scanning and patching SLAs under Penetration Testing (CC6.8, CC8); and backup and continuity under Backup & DR (CC9). The controls unique to this section are organizational.

Implemented today

• Control environment (CC1): a code of conduct covering integrity, market abuse, customer data handling, and anti-bribery, signed at onboarding and renewed annually; a five-module security training curriculum completed before production access; security KPIs in quarterly performance reviews; named owners for each roadmap item.
• Access provisioning (CC6): a documented two-person approval workflow. A tagged access-request issue requires approval from someone other than the requester, accounts start at zero permissions with a mandatory MFA enrollment window, and both request and approval are recorded before provisioning. Offboarding is a single procedure: account deactivation, JWT key rotation invalidating all outstanding sessions, API key revocation, and SSH key removal. Quarterly access reviews verify continued need.
• Administrative surfaces (CC6): CI, source control, and the secrets vault sit behind Cloudflare Access with Google OAuth as the sole identity provider plus each application's own credential check, a minimum of three authentication factors per administrative surface.
• Change management (CC8): every merge to the main branch requires peer review; type checking and security verification scripts run in CI as merge gates.
• Incident response (CC7.3): a written runbook defines four severity levels (SEV1 through SEV4), declaration by any engineer with no management pre-approval, defined roles (Incident Commander, Tech Lead, Comms Lead, Scribe), a containment checklist covering credential rotation, session invalidation, and forensic snapshots before remediation, and a notification matrix that includes the GDPR Article 33 clock (detailed under GDPR). Post-mortems are blameless and committed within 72 hours of resolution. The runbook self-declares inactive until the first tabletop drill executes.
• Risk register (CC3): a formal register with 14 risks, each with likelihood and impact scores, a treatment decision, a named owner, and a status, including four fraud-specific risks (insider credential misuse, fraudulent signups and referral abuse, payment and chargeback fraud, and agent or tool abuse); three risks closed since the register was established.
• Documented ISMS policy set (CC5): an information security policy, acceptable use policy, information classification scheme, secure development standards, supplier security policy, access provisioning procedure, data retention schedule, and records of processing, maintained in the internal security vault and available to qualified reviewers under NDA. Management sign-off of the master information security policy is the remaining governance step.

Roadmap

• First tabletop incident response drill (scheduled 2026-07-15); completion moves CC2.3, CC7.2.b, CC7.2.c, CC7.3.a, and CC7.3.b from framework-ready to live.
• First restore drill (same date; detailed under Backup & DR).
• Full-disk encryption on the production system disk (detailed under Encryption); the only remaining control blocked on a console action rather than a code change.
• First external penetration test (detailed under Penetration Testing).
• Data Processing Agreement in force: template drafted with EU SCCs (Modules 2 and 3), UK IDTA, and Swiss FADP provisions; external counsel review and countersignature pending (detailed under GDPR).
• Offsite backup target (detailed under Backup & DR).
• Independent advisory or board-level security oversight function.
• A standing quarterly formal risk assessment meeting; the register already enumerates fraud risks, and the recurring meeting cadence begins on the drill calendar.
• Confidentiality TSC (C1): protection and retention controls exist, but the Confidentiality category has not yet been formally added to the claimed TSC scope.

ISO 27001 alignment

Melaya does not hold ISO/IEC 27001:2022 certification as of 2026-07-04. No third-party ISO 27001 audit or certification body assessment has been conducted. The framing throughout this section is alignment with ISO/IEC 27001:2022 Annex A control themes, not claimed certification. The controls are internally implemented and verifiable from the source repository and operational runbooks, and formal certification can be scoped and initiated with a readiness assessment in response to partner or customer requirements.

Readiness snapshot (2026-07-04 self-assessment against the 93 Annex A controls, not independently audited): 52 implemented, 29 partial, 1 roadmap, and 11 not applicable (the physical and environmental theme is inherited from the cloud provider under its own attestation). A Statement of Applicability is maintained internally; a management-approved master information security policy and independent audit are the principal items still pending to reach certifiability; the technical control content is substantially in place.

Risk management (Clause 6 / A.6.1) runs on a formal register reviewed quarterly by the security owner. Each entry carries a unique ID, a plain-language description, likelihood and impact ratings on a three-point scale, a composite severity score, a treatment decision (mitigate, accept, or transfer), a named owner, and an open or closed status. The scoring matrix gates urgency: Critical severity triggers immediate remediation, High within 30 days, Medium within 90 days, Low is accepted or monitored. Reviews run on the same calendar anchor as the incident response drill cadence, closed risks are retained for audit continuity, and ownership is distributed across security, engineering, operations, and legal rather than concentrated in one role.

Rather than restate controls covered elsewhere, we map Annex A families to where they are described:

Implemented today

• Business continuity: a documented plan covering primary region outage, database provider failure, secrets vault outage, payment processor outage, primary engineer unavailability, and supplier termination, with per-supplier contingency paths and acceptable degradation windows. Quarterly BCP review is tied to the drill cadence, with an annual full walk-through in the Q4 tabletop exercise.
• Cyber insurance covering breach response and regulatory defense.
• Supplier relationships (A.5.19): a published subprocessor list with DPAs executed or in progress, per-supplier contingency plans in the BCP, and customer-configured LLM providers treated as out-of-scope subprocessors rather than Melaya-managed services.
• A weekly run of the pentest-regression script codifying known attack primitives, plus periodic audit-chain integrity verification.
• A Statement of Applicability covering all 93 Annex A controls with a per-control applicability decision and status (52 implemented, 29 partial, 1 roadmap, 11 not applicable), plus the supporting Annex A policy set (information classification, acceptable use, secure development standards, supplier security), maintained in the internal security vault.

Roadmap

The open items match the SOC 2 roadmap above (external pentest, full-disk encryption, tabletop drill, DPA countersignature, independent oversight) plus egress allowlist enforcement, which is detailed under Tenant Isolation.

GDPR and data subject rights

Readiness snapshot (2026-07-04 self-assessment across the core GDPR obligations, no certification held or implied): the data-subject-rights articles are substantially covered, with the remaining items partial and governance-gated. The self-serve access, portability, erasure, and rectification work in this release moves the data-subject-rights articles toward covered; records of processing (Art 30) and a data protection impact assessment (Art 35) are now authored and maintained internally, and the principal remaining items are the DPA execution with external counsel and self-serve restriction/objection.

Roles. Melaya, Inc. is the controller for personal data collected for its own account management (registration, billing, authentication artifacts, session telemetry, product analytics), governed by the public Privacy Policy (last updated 2026-04-15). Where Melaya processes personal data under a written agreement with an enterprise customer, the customer is the controller and Melaya is the processor; Customer Data in scope includes pipeline configurations, uploaded documents, retrieval index contents, prompts, trading activity metadata, and any identifiable individuals referenced in that content. The split is codified in Section 2 of the DPA template (v1.0-draft, 2026-04-15).

Data categories.

We do not intentionally collect special-category data, biometric identifiers, government identity documents, or payment card PANs. No representation is made about content users may upload to retrieval indices.

Lawful bases for EEA, UK, and Swiss data subjects: performance of a contract (Art. 6(1)(b)) for authentication, subscription delivery, pipeline operation, and engine order execution; legitimate interests (Art. 6(1)(f)) for fraud prevention, abuse detection, security monitoring, billing, product improvement, and defense of legal claims; legal obligation (Art. 6(1)(c)); and consent (Art. 6(1)(a)) for optional analytics cookies, freely given and withdrawable.

Data subject rights. The Privacy Policy acknowledges the full GDPR rights set: access, rectification, erasure, restriction, objection, portability, consent withdrawal, and supervisory authority complaint. Access, portability, rectification, and erasure are now self-serve from the account UI; restriction and objection are handled manually on request.

Implemented today

• Self-serve access and portability (Articles 15 and 20): the accounts.exportMyData query, scoped to the authenticated caller, returns a downloadable JSON bundle of the profile, connected-service list (names and timestamps only), credit balance, and referral count. Secrets are excluded by construction: no password hash, MFA secret or recovery codes, IP hash, or credential values are ever included.
• Self-serve erasure (Article 17): the accounts.deleteMyAccount mutation, which requires the caller to type a literal DELETE confirmation, removes the caller's own account and writes the tamper-evident tombstone described under Audit Logging. The tombstoneActor writer is also wired into the administrative deletion paths, so every erasure is recorded without mutating the audit hash chain.
• Rectification (Article 16) is self-serve through the account UI, with email and username changes gated by step-up MFA and recorded as an audit event.
• Manual rights request handling remains available via our Privacy Team for any right not yet self-serve (restriction, objection), with responses committed within applicable statutory timeframes.
• Account deletion and credential erasure per DPA Section 11: account revocation, removal of uploaded documents and retrieval indices from active storage within 24 hours, cryptographic erasure of envelope-wrapped credentials via envelope key rotation, and backup purge on normal rotation (approximately 35 days).
• Connector token revocation through the product UI, with associated tokens deleted within seven days.
• Retention enforced by an automated retention-sweep script whose sweep events are themselves audited: billing records at least 7 years; run logs and telemetry tier-dependent (sandbox 7 days, forge 30 days, bastion 90 days, citadel no automatic cutoff); uploaded content until user deletion or account closure, purged from backups on normal rotation; envelope-encrypted exchange credentials permanently undecryptable once all backups containing the paired key rotate out; account data for the life of the account plus a reasonable post-closure period.
• Subprocessor change management: at least 15 days' written notice before any new subprocessor engagement or material change, with an objection right during the window; unresolved objections entitle termination with a pro-rata refund. The canonical list is published at /legal/subprocessors (geography and transfer mechanisms per the table under Data Residency).
• International transfers: EU SCCs (Commission Decision 2021/914) Module 2 and Module 3 flow-down incorporated into the DPA template, with the subprocessor list and technical-and-organizational measures populating the SCC annexes; the UK IDTA for UK transfers; Swiss FADP equivalent clauses for Swiss transfers. Executed SCCs are available to enterprise customers under NDA.
• Breach notification: we commit to notifying affected enterprise customers within 72 hours of becoming aware of a personal data breach, providing the nature of the breach, categories and approximate number of data subjects, likely consequences, and measures taken or proposed. This is bound in DPA Section 10, and the Article 33 matrix (affected customers and the lead EU supervisory authority, clock measured from awareness) is documented in the incident response runbook; the breach process is documented today with activation gated on the first tabletop drill (2026-07-15).
• Accountability records maintained internally and available under NDA: Records of Processing (Article 30), a Data Protection Impact Assessment (Article 35) recording an explicit Article 22 finding that Melaya makes no solely-automated decision producing legal or similarly significant effects, a Data Retention Schedule, a Records of Consent register, and a Data Subject Rights Procedure.

Roadmap

• Self-serve mechanisms for the remaining rights (restriction and objection); these are handled manually today.
• DPA in force: the fifteen-section template (roles, processing scope, confidentiality, security measures, subprocessor management, transfer safeguards, rights assistance, breach notification, return-or-deletion, annual audit rights) is offered bilaterally to enterprise customers on request, but external counsel review is still in progress and it is not yet available as a clickwrap at non-enterprise tiers.
• Subprocessor RSS feed for change notification.

Contact. Data protection inquiries, rights requests, and DPA requests: Melaya, Inc., Attention: Privacy Team, [email protected]. EEA, UK, and Swiss data subjects may lodge a complaint with their competent supervisory authority.

Shared responsibility model

Some controls are structurally yours, and the platform is designed so you can hold them.

• Exchange API key permissions. You create and scope your exchange API keys at the venue. We store them only as envelope ciphertext and require MFA to add them, but the permission set on the key (trade, read, withdraw) is set by you at the exchange. We recommend withdrawal-disabled keys.
• LLM provider choice. You choose which model providers your pipelines route to, and content flows to those providers under your configuration and their terms. If no external provider is acceptable, pair the local runner with a local model runtime and keep inference on your hardware.
• Local runner hardware. When you run pipelines on the local runner, the physical and OS security of that machine, and everything processed on it, is under your control. We authenticate the runner with scoped tokens and keep artifact content off the control channel; the host itself is yours to secure.

Working with our team

Evidence artifacts are available to qualified reviewers under a signed NDA: the SOC 2 control mapping matrix with evidence citations; the incident response runbook and drill attestation records; access provisioning workflow and quarterly access review records; the patching cadence runbook with image digest registry; the audit log schema, verification scripts, and a sample export; the risk register with treatment decisions and closures; the code of conduct and training curriculum with acknowledgement log; the responsible disclosure triage routing; the DPA template and executed DPAs with primary subprocessors; business continuity and RTO/RPO documentation; the Statement of Applicability, Records of Processing (ROPA), Data Protection Impact Assessment, Data Retention Schedule, and Data Subject Rights Procedure; and change management records.

Security questions and vulnerability reports: [email protected], with our responsible disclosure policy and safe harbor terms at melaya.org/legal/security. Privacy, data protection, and DPA requests: [email protected].

Frequently asked questions

Version 1.2, 2026-07-04.