This Security Overview describes the technical and organizational measures Melaya Labs LLC ("Melaya") currently applies to protect the confidentiality, integrity, and availability of the Melaya platform. It is intended to give prospective and existing users, enterprise buyers, and auditors an honest picture of what is in production today, what is in progress, and what is not yet implemented. Where a capability is aspirational or in progress, it is explicitly marked as such rather than hidden behind vague language. Security is a shared responsibility: Melaya is responsible for the security of the platform, and customers are responsible for the security of what they build, upload, and execute on top of it.
1. Encryption in Transit and at Rest
All data in transit between user clients and the Services is protected by Transport Layer Security (TLS) version 1.2 or higher, terminated at Cloudflare at the edge of the deployment. The production TLS profile follows the Mozilla Intermediate compatibility guide: TLS 1.2 and 1.3 only, ECDHE cipher suites only, forward-secret AEAD ciphers only, HSTS with a two-year max-age and the preload directive, and a strict Content Security Policy with an explicit connect-src allow-list. The Content Security Policy is applied on both surfaces: the API server sets default-src 'none' via its security-header middleware, and the public web application ships a policy that allow-lists our own backends plus the payment and sign-in providers, blocks plugin content and base-tag or form-action hijacking, and confines script execution, so an injected script cannot exfiltrate data to an attacker origin. The full TLS profile, the committed cipher list, and the quarterly review cadence are documented in the TLS Baseline runbook in the internal security vault. Internal service-to-service calls within our infrastructure run over loopback or private network links.
Encryption at rest is implemented today at the application layer through field-level envelope encryption. Full-volume disk encryption at the storage layer is not yet enabled: the production block devices are presently unencrypted at the disk level. Volume-level encryption using LUKS has been selected as the remediation path and is a committed item on the security roadmap; until it is executed, Melaya does not represent disk-layer or provider-managed volume encryption as an active control.
Sensitive values are protected by an application-level envelope encryption layer implemented in our envelope-encryption service. Exchange API credentials (key, secret, passphrase), per-user connector credentials and OAuth tokens, and MFA secrets and recovery codes are wrapped with AES-256-GCM using a 256-bit master key held only in the server process before they are sent to the Infisical vault provider or written to the agents.credentials fallback table. The wire format carries an explicit key identifier (v1:<kid>:<base64(iv|ciphertext|tag)>) so the server can accept multiple valid keys during a rotation window and route reads to the exact key that wrapped each value. New writes always use the active key, which is the first entry in the configured key list. Rotation is a three-release procedure that never takes the platform down: add the new key as the second entry (writes still go to the old key, new key is read-only), promote it to first (writes flip to the new key, old key remains readable), re-wrap any historical rows bound to the retired key identifier, then drop the old entry. Neither Infisical nor the Postgres host sees plaintext credentials at any point: a compromise of either subprocessor in isolation yields only ciphertext, and the attacker additionally needs a configured envelope key to recover any exchange key. A one-shot migration script handled the residual legacy plaintext rows from before the envelope layer existed; the sweep completed against the production database and its round-trip verifier (envelope-verify.ts, 7/7 scenarios) exits zero on every CI run and against live production.
2. Tenant and Pipeline Isolation
The platform enforces logical isolation between tenants at the application layer. Every authenticated request carries a user identifier derived from a validated JSON Web Token, and every database query, object store access, and retrieval index lookup is scoped by that identifier through parameterized SQL and tRPC context plumbing. Retrieval indices built for the Agentic Framework are stored per-pipeline and are only returned to queries that originate from the pipeline that owns them. Engine state, strategy configurations, and order histories are similarly partitioned by user. Postgres row-level security is enforced as a defense-in-depth layer behind the application-layer scoping: FORCE ROW LEVEL SECURITY is active in production across 44 tables in the agents.* and cex.* schemas under 117 row-level-security policies, and the application connects under a dedicated low-privilege role that runs NOBYPASSRLS and therefore cannot see across tenants even if a query accidentally forgets its WHERE user_id clause. The per-request row-level-security context sets the tenant identifier and role as session parameters before any query executes, and the connection pool issues DISCARD ALL on release so that context cannot carry over between tenants. Seventeen cross-tenant scenarios in our verifier rls-verify.ts exit zero against the live database on every CI run, including SELECT, INSERT, UPDATE, DELETE, ownership-reassignment, admin bypass, no-context zero-row, and context-leak regression cases.
3. Key and Secret Management
Application secrets, signing keys, database credentials, and third-party API keys used by Melaya itself are stored in an operator-controlled secrets file loaded at process start and in our vault provider. They are never committed to source control and production values are not shared between developers. The envelope encryption key is a dedicated encryption key held only in the operator's secrets store, separately from the Postgres database credentials and separately from the Infisical vault token, so compromise of any single one of the three does not yield plaintext exchange credentials. Customers are strongly encouraged to scope every exchange API key to trading-only permissions, to disable withdrawals at the issuing venue, and to apply IP allowlisting where the venue supports it.
Session tokens are signed under a multi-key rotation window. The server accepts an ordered set of signing keys, each tagged with a short key identifier. New tokens are signed under the first (active) key and carry that identifier in the JWT header for O(1) verification. Tokens issued under any retired key in the window continue to verify until their seven-day TTL elapses, at which point the retired key can be dropped. Expired tokens are rejected immediately even if a non-active key would otherwise accept them. Verification round trips are asserted in our verifier jwt-keys-verify.ts.
4. Authentication and Access Control
User authentication is based on email and password with bcrypt hashing at work factor 12, combined with rate limiting on the login, register, and forgot password endpoints (20 attempts per IP per 15 minutes, enforced by a Redis-backed distributed limiter). Session tokens are issued as JSON Web Tokens with a seven-day expiry and bound to the user, role, and tier claims. Role-based access control distinguishes user from admin, and tier-based access control gates features per the four-tier catalog. Every action of consequence is checked on the server side; client-side gates are purely a UX hint and are never relied upon for security.
Two-factor authentication is available to all users via the standard TOTP profile (RFC 6238, SHA-1, 6 digits, 30-second period, ±1 window drift) and is compatible with every mainstream authenticator app. TOTP shared secrets are generated server-side with 160 bits of entropy, wrapped through the envelope encryption layer described in section 1, and stored in a wrapped column on the user row. Recovery codes are generated once at enrolment, bcrypt-hashed at work factor 12, and then wrapped a second time by the envelope layer so a database compromise alone cannot resurrect them. Enrolment is a two-step process that requires the user to prove they have configured their authenticator by entering a live code before the second factor is marked active. Login flow becomes a password check, then a short-lived (five-minute) challenge token, then a code verification that atomically consumes the challenge row; a captured challenge token cannot be replayed after a successful consume. MFA is required for adding CEX API credentials and for generating platform API keys, the two highest-impact fund-interacting actions in the product. Every MFA challenge outcome (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) is written to the append-only audit log described in section 6 so that challenge patterns are auditable and tamper-evident.
Melaya employee access to production systems is granted on a per-engineer basis under a documented two-person approval workflow and removed when no longer required. Access provisioning requires approval from someone other than the requester, and offboarding deactivates the account, rotates the JWT signing keys to invalidate outstanding sessions, revokes API keys, and removes SSH keys. Stale privileged sudoers entries and SSH authorized keys are cleaned on a session-by-session basis, and a quarterly access-review cadence is documented. A full split between the deploy user and the service runtime user (so a compromised service process cannot pivot to the deploy path) is tracked as a planned control on the security roadmap.
5. Network and Infrastructure Rate Limiting
Rate limiting is enforced at the application layer by a Redis-backed shared store so that the limits are global across every server instance rather than per-process. Two independently configured buckets apply: a strict bucket on authentication endpoints (20 attempts per IP per 15 minute window) and a general API bucket (200 requests per IP per minute). The limiter is fail-closed: if the Redis store is unreachable, the auth endpoints deny rather than fall through. The limiter's tRPC batch-aware wrapper is verified by our verifier rate-limit-verify.ts (7/7 scenarios, including the batch-laundering attack).
Edge traffic is fronted by Cloudflare with WAF, bot detection, and geo-blocking on high-risk paths. A Terraform scaffold for the Cloudflare zone is committed alongside an operational runbook covering drift detection, emergency override, and the 24-hour reconcile rule; the import-and-reconcile of the currently-manual zone against that scaffold is in progress and is the gating task before the first external penetration test is scheduled.
6. Monitoring, Logging, and Audit
The platform emits structured logs from the Node.js tRPC server, the Rust Engine, the Python worker, and the edge. All host-level and container-level logs (the systemd journal, host system logs, nginx access and error logs, CI and source-forge container stdout, and every Melaya application log) are shipped off-box in real time to a Grafana Cloud Loki tenant in the same region as the production host via a Grafana Alloy collector, so the audit trail survives host compromise or disk loss. Outbound network connections are recorded by a network-layer egress logging rule and forwarded to the same off-box sink; this egress traffic is logged and observed today, while enforced deny-based egress allowlisting remains a pending roadmap item.
Security-relevant events (authentication outcomes, MFA challenge results, CEX credential adds and removes, platform API key issuance and revocation, tier changes and rollbacks) are additionally written to an append-only agents.audit_log table. The schema revokes UPDATE and DELETE from the application role, maintains a cryptographic hash chain over rows (prev_hash / row_hash), stores the actor IP only as an HMAC-SHA256 digest under a keyed secret (not plain SHA-256, which is dictionary-attackable), and provides a side-table agents.audit_log_tombstone for GDPR Article 17 erasure that never mutates the chain. A daily verifier (verify-audit-chain.ts) walks the chain end-to-end, asserts timestamp monotonicity with a ±2 second NTP tolerance, and emits an anchor digest suitable for external write-once storage. Six tampering scenarios in audit-log-verify.ts exit zero against live production.
7. Vulnerability Management
Every commit runs npm audit --production and a Trivy filesystem scan as part of CI. Trivy is invoked twice on each build: once in a gated mode with ignore-unfixed: true so actionable findings fail the check, and once with ignore-unfixed: false and non-gating so the complete vulnerability surface is uploaded to the repository's Security tab for compliance evidence. The production host runs unattended-upgrades with the security channel enabled and an automatic reboot window. Third-party container images for the CI, source-forge, secrets-vault, Postgres, and Redis services are review-gated before version bumps, tracked in the Patching Cadence runbook in the internal security vault, and monitored by a daily image-digest drift detector that alerts within 24 hours of any silent image rotation.
Melaya has not yet undergone a third-party external penetration test. The engagement scope (including in-scope and out-of-scope assets, rules of engagement, vendor shortlist requiring CREST accreditation, and post-engagement remediation cadence) is committed in the internal Pentest Scope runbook so vendor selection can move as soon as the Cloudflare IaC reconcile from section 5 lands. No "annual pentest" claim is made anywhere in Melaya documentation.
8. Secure Software Development
Changes to the platform flow through source control with peer review before merge. TypeScript's strict mode and static analysis run on every client and server build. gitleaks runs as a pre-commit hook and in CI, with a path-scoped allow-list rather than a global one, so accidental disclosure of credentials fails the build before merge. All CI actions are pinned by commit SHA to prevent supply-chain tag-rewriting attacks. Production deployments go through a restricted Jenkins SSH wrapper with an authorized_keys command= restriction so even a compromised CI runner can only invoke the explicit resync <service> and log <service> operations for the allowlisted Melaya services: no arbitrary shell, no filesystem traversal, no privilege escalation beyond the service restart itself. Every deploy pipeline invocation is logged off-box to the Grafana Cloud Loki tenant for audit, together with a committed provenance record linking the running binary to its source commit.
9. Incident Response
Melaya maintains a written Incident Response runbook covering severity declaration (four severity levels), role assignments (Incident Commander, technical lead, communications, scribe), a containment checklist that includes explicit envelope-key, JWT-key, and audit-log IP-HMAC-key rotation steps, the GDPR Article 33 72-hour notification matrix, and a post-mortem template. The runbook is committed to the internal security vault and treated as a live document: the first tabletop drill is scheduled for 2026-07-15, and the runbook is explicitly flagged as "not active" in its own procedures until that drill executes. On-call engineers respond to real incidents today; the drill gate is about the formal tabletop exercise, not the existence of the response path.
10. Backup and Disaster Recovery
Per-subsystem Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets are published in the internal RTO RPO runbook: the agents.* tier targets 15-minute RTO / 2-hour RPO, CEX credential storage targets 5-minute RTO / 1-hour RPO, Infisical and object storage target 4-hour RTO / 1-hour RPO, and Redis is no-backup and rebuilt on reconnect. Backup mechanics combine continuous WAL archiving with a 14-day point-in-time-recovery window, a nightly logical dump retained cross-region, a monthly base backup, and a daily write-once audit-log anchor export to an external location. All backup artifacts are compressed, checksummed, and encrypted with restic. Restore verification runs on two cadences: an automated weekly job performs a restic integrity check and a spot-restore to a scratch directory, and the first full restore drill into a throwaway environment is scheduled for 2026-07-15, after which its written attestation of restore wall-clock and integrity check will be committed to the same runbook. Melaya operates from a single primary hosting region today; this is disclosed plainly, and the compensating controls (cross-region nightly dumps, continuous WAL archiving, a cross-region health probe, and Cloudflare DNS failover) bound the worst-case full-region-loss RTO at approximately 24 hours as a documented and accepted risk.
11. Business Continuity
A written Business Continuity Plan is committed in the internal security vault covering primary-region outage response, Postgres-provider failure, Infisical vault outage (the server keeps serving existing sessions via cached credentials, new CEX writes refuse with a user-visible error), Stripe outage (existing subscriptions unaffected), personnel availability matrix, and a per-supplier contingency table. The plan is reviewed on the same quarterly cadence as the TLS baseline, with an annual full walk-through as part of the tabletop exercise.
12. Vendor and Subprocessor Security
Melaya uses subprocessors and infrastructure providers for functions described in the public Subprocessors list. The contractual role, location, and transfer safeguard of each provider must be evaluated from the actual deployment and agreement; customer-selected model, connector, merchant, or tool providers may act under the customer's instructions and their own terms rather than Melaya's vendor contracts. Enterprise customers receive applicable subprocessor notice and objection rights under their agreement or data processing addendum. Melaya's primary hosted environment is presently operated in Singapore, which is not covered by an EU adequacy decision, so applicable transfers require a lawful transfer mechanism and supplementary safeguards where required. A local runner executes Python, local files, retrieval operations, and selected credentials on customer-controlled hardware, but run configuration, signed dispatch content, selected credential delivery, collaboration events, telemetry, cloud-model requests, or connector calls can still pass through or reach Melaya and third parties according to the selected mode. The public Subprocessors page, customer agreement, and actual data flow - not the word "local" alone - determine recipient and residency disclosures.
13. Compliance Posture
Melaya is building its controls with the SOC 2 Trust Services Criteria and ISO/IEC 27001 in mind. As of the date of this document Melaya does NOT hold SOC 2 Type I, SOC 2 Type II, ISO/IEC 27001, or any equivalent third-party security attestation, and no examination or certification body assessment has been conducted. These are aspirational milestones on our roadmap. Any prospective customer requiring an attestation today should expect a gap analysis deliverable rather than a completed report. Enterprise customers may request our current control matrix and the list of remediations in progress by contacting [email protected].
A fifteen-section Data Processing Addendum template has been drafted and committed in the internal security vault. It incorporates the European Commission Standard Contractual Clauses (Module 2 for controller-to-processor and Module 3 for processor-to-processor), the UK International Data Transfer Addendum, and the Swiss FADP equivalent. The GDPR Article 33 72-hour breach-notification commitment, return-or-deletion procedure, and audit rights (limited to annual and NDA'd SOC 2 Type II when that lands) are all bound in the template. External counsel review is pending before the DPA is offered as a clickwrap at paid tiers and as a bilaterally-signable version at the citadel tier.
14. Customer Responsibilities
Security on Melaya is shared. Customers are responsible for choosing strong, unique passwords, protecting their account credentials, scoping exchange API keys to the minimum permissions required, reviewing and validating the behavior of the pipelines they build, controlling what content they upload to retrieval indices, reviewing the terms and data handling practices of any third-party language model providers they choose to route through, and promptly reporting any suspected compromise. We strongly recommend enabling two-factor authentication in account settings the first time you sign in; it is required before any CEX credential can be added or any platform API key can be generated, and it is the single highest-impact security control a customer can apply to their own account.
15. Responsible Disclosure and Safe-Harbor
Safe-harbor. Melaya Labs LLC will not pursue legal action against, or support any third-party legal action against, security researchers who act in good faith and comply with this policy. This commitment applies to claims Melaya could otherwise bring under the U.S. Computer Fraud and Abuse Act (CFAA), the U.K. Computer Misuse Act, the equivalent provisions of EU Member State computer-misuse statutes, and any civil-law claims for breach of contract, tortious interference, or trespass to chattels. "Good faith" means the researcher made a genuine effort to comply with the scope and rules of engagement below, did not access, modify, destroy, or exfiltrate data belonging to other users, did not intentionally degrade the Services for other users, and disclosed the finding privately to [email protected] before any public disclosure. This clause is binding on Melaya and does not require per-report approval. It does not cover conduct that is independently illegal under the researcher's jurisdiction, such as actual financial fraud against other users, or extortion.
Scope. Testing is authorized against melaya.org and all subdomains in the *.melaya.org zone, the application surface at app.melaya.org, the Builder API endpoints, and the Melaya-published legal pages. Testing is NOT authorized against: (i) live order placement, cancellation, or modification on any third-party exchange reached via Melaya; (ii) third-party language model providers (OpenAI, Anthropic, Google, Cohere, local runtimes) reached via a user-configured pipeline; (iii) Cloudflare, hosting provider, or vault provider infrastructure themselves; (iv) any form of denial-of-service attack (L3/L4 flood, L7 flood, credential stuffing at volume); (v) social engineering of Melaya employees, contractors, or customers; (vi) physical intrusion.
Rules of engagement. Researchers must stop testing the moment a finding has been proven (a single non-destructive read is sufficient proof of cross-tenant access), must never modify or exfiltrate other users' data, must not install persistence, and must keep automated testing under 1 request per second sustained. Testing traffic should carry a distinct User-Agent: Melaya-research/<handle> header so Melaya can distinguish it from real traffic and will not page the on-call for it.
Triage SLA. Melaya commits to acknowledging valid reports within five (5) business days of receipt, providing an initial severity assessment within ten (10) business days of acknowledgement, and remediating findings per the severity ladder: Critical within 48 hours, High within 7 calendar days, Medium within 30 calendar days, Low within 90 calendar days. If Melaya misses an SLA commitment, the researcher may provide seven (7) days written notice of intent to publish and the safe-harbor protection remains in effect through publication provided the researcher complied with the rules of engagement throughout.
Contact. Reports should be sent to [email protected]. A PGP key for encrypted reports will be published at /.well-known/security.txt. Reports should not be sent via social media, GitHub issues on public Melaya repositories, or any support chat surface: those channels are not monitored for security-sensitive content and create a risk of accidental public disclosure before remediation.
This Section 15 is self-contained and its commitments are binding. The safe-harbor in the first paragraph, the scope and rules of engagement in the second and third paragraphs, the triage SLA in the fourth paragraph, AND the Terms-of-Service interaction and prospective-only amendment rules in the immediately following paragraph together constitute the full set of commitments binding on Melaya with respect to security researchers. Every paragraph in this Section 15, not only the first four, is part of the binding commitment set. Melaya maintains an internal operational runbook for triage routing and escalation, but that runbook does not add to, subtract from, or modify any of the commitments in this Section 15, and a researcher does not need to read any other document to rely on the safe-harbor above. Any change to this Section 15 applies only prospectively: a finding reported in good faith under the version of this Section 15 in effect at the time of the report remains protected by that version's safe-harbor regardless of any subsequent amendment.
Interaction with the Terms of Service (binding). This Section 15 constitutes Melaya's express authorization for security research activity that would otherwise be restricted by the Terms of Service prohibitions against circumventing, disabling, or interfering with Melaya's security, rate-limiting, or access-control features. A researcher acting within the scope and rules of engagement above is therefore not in breach of the Terms for that conduct, and Melaya waives any claim it could otherwise bring under the Terms with respect to that specific conduct. This paragraph is itself part of the binding commitment set above and is not merely interpretive text.
Device Control security model
Device Control is designed as a user-authorized, deny-by-default channel. The Android app cannot enable Accessibility or screen capture by itself; the user must grant those permissions in the operating system. Android may require restricted-settings approval for sideloaded builds.
Paired phones authenticate with a revocable device token whose SHA-256 hash is stored server-side. The raw Android token is currently stored in the app's private SharedPreferences rather than hardware-backed encrypted storage; the iOS app stores its token in Keychain. Phone tokens are separate from browser sessions and runner tokens, are limited to phone endpoints, expire or can be revoked, and should be protected by the user's device security.
Accessibility screen-tree reads and foreground-restricted taps, typing, swipes, and similar actions are checked against the user's approved-app allowlist on the server and Android device. Global navigation actions have different boundaries, and full-display MediaProjection frames are not technically cropped or gated to the foreground allowlisted app; an unapproved or sensitive app visible during mirroring may therefore appear in a frame.
Live screen frames are downscaled full-display images relayed as latest-frame data for the authenticated owner session and screenshot tools. They are held briefly in server process memory for freshness and delivery, but selected screenshots, tool results, model requests, telemetry, or logs may persist or reach a selected cloud model or connector. Users should stop mirroring before opening unrelated sensitive content.
Phone command queues and approved-app policy are currently scoped by user account rather than selected device. If multiple phones are paired, the first eligible polling phone can claim a queued command; after claim, the result is associated with that job and phone token. Native runs also register an active run so the same user's overlay kill control can request termination of that registered run; it cannot terminate arbitrary users' pipelines.
Mobile Agent and device-execution controls
Mobile Agent security separates decision, authorization, routing, and physical execution. A model or agent may propose a command; Melaya services validate the authenticated user, paired-phone status, action policy, and command envelope; the first eligible polling phone may claim a user-scoped queued job; and the registered user-controlled device then performs the command under operating-system permissions.
Device credentials are distinct from browser sessions, cloud service identities, provider credentials, and local-runner tokens. The server stores a SHA-256 hash of the revocable phone token. Android currently stores the raw token in private SharedPreferences, while iOS stores it in Keychain. A phone token does not authorize general account administration, another user's phone endpoints, or an unrelated runner.
Commands are deny-by-default and scoped to the authenticated user, claimed job, app policy, action type, parameters, and queue lifetime. The queue and allowlist are presently user-scoped, not deterministically addressed to a selected device when several phones are paired; after a phone claims a job, ownership checks bind its result. Sensitive endpoints authenticate callers, validate sizes and ownership, and reject expired jobs, but customers should pair only trusted devices.
High-impact or ambiguous actions should require fresh human confirmation, clear target and consequence information, and an available pause or kill path. Persistent indicators, overlays, foreground-service notifications, previews, timeouts, rate limits, audit trails, and terminal-state cleanup provide defense in depth but cannot guarantee that an action is correct or reversible.
Command and telemetry channels use encrypted transport and authenticated identities. Signed or integrity-protected dispatch, nonces, command identifiers, expiry, device binding, and replay detection are used where implemented to reduce tampering and cross-user execution. Transport encryption does not prevent an authorized endpoint from seeing plaintext needed to execute the request.
Local runners keep Python execution, local files, and local-model inference within the user's environment, subject to the user's operating-system controls. Hybrid runs additionally expose inference or tool payloads to selected cloud providers. Cloud runs execute within Melaya-managed infrastructure and can process runtime data and selected secrets. Sandboxing and isolation reduce, but do not eliminate, application, dependency, model, prompt-injection, or infrastructure risk.
Stored credentials use encryption or secret-management controls and are delivered only when selected for a run. The execution process and external provider necessarily receive usable authentication material. Users must apply least privilege, separate production from testing credentials, rotate and revoke promptly, restrict provider scopes, and never place secrets in prompts, screenshots, logs, or untrusted tool output.
Telemetry and collaboration services can receive any message, trace, tool event, result, cost, status, approval request, screenshot, or diagnostic payload that a runtime emits. Customers should configure event detail and retention appropriately, avoid unnecessary sensitive data, and apply workspace and project access controls. "Local" describes execution location, not a guarantee of zero transmitted telemetry.
Android Accessibility and MediaProjection are user-granted sensitive capabilities. The mobile app must provide required prominent disclosure and affirmative consent before access, use the narrowest available API, remain visible when required, degrade when permission is denied, and never use permissions to bypass platform security or hide activity. A Play-distributed build must not permit Accessibility to autonomously initiate, plan, and execute actions contrary to Google Play policy.
The iOS App Store application is constrained by Apple's sandbox, entitlements, and public APIs and does not offer unrestricted third-party app control. Mac runner, Developer Mode, XCTest, WebDriverAgent, paired-device, and developer-signed testing paths have a different threat and trust model and require control of the Mac, signing identity, device pairing, test target, and network channel.
No control eliminates every risk. Models can be manipulated by prompts or screen content; applications can change layouts; permissions can be overbroad; dependencies can be compromised; devices can be lost; and authorized users can misuse capabilities. We investigate credible reports, may revoke or isolate affected credentials or devices, and encourage immediate use of kill, revoke, rotate, and incident-reporting procedures.
16. Changes to This Overview
Melaya may update this Security Overview from time to time to reflect changes to the platform, our controls, or our subprocessors. The "Last updated" date at the top of this document reflects the most recent revision. When operationally-pending items (such as the first restore drill, the first IR tabletop drill, the first external pentest, volume-level disk encryption, or external counsel review of the DPA template) complete, the corresponding section is rewritten to reflect the new state and the change is announced in the product changelog.
17. Contact
For security questions, vulnerability reports, or to request compliance documentation, contact: