Acceptable Use and Security Disclosure

4.1 Security Model in Plain English

Mercury Device Commander is designed with strict security boundaries tailored for AI agent execution on macOS:

[ Your Chosen AI Platform ] (Tested: ChatGPT, Claude. Works with MCP clients; a sample configuration is available for Gemini.)
            │  (Local stdio MCP or user-configured tunnel to 127.0.0.1)
            ▼
[ Mercury Device Commander ] (Local macOS app & MCP Server)
            │
            ├─► 1. Client Token Validation (Optional per-client revocable token; default shared token)
            ├─► 2. Client Profile & Scope Check (owner-full, scoped, read-only)
            ├─► 3. Local Execution Audit Log (JSON Lines on-device operation log)
            ▼
[ Local macOS Host ] (Filesystem, Terminal / Shell, AppleScript, Screen Capture)

1. Local-First Execution: Mercury runs as a native macOS process. Filesystem reads/writes, terminal commands, and AppleScript calls happen locally on your hardware.
2. Access Profiles: Client access profiles and capability scopes are configured by the device owner (owner-full, scoped with a defined capability list, or read-only). Read-only clients cannot modify files, run commands, or execute AppleScript.
3. Per-Client Revocable Tokens: Each AI client can be issued an individual revocable token (by default a shared launch token is used, which is not revocable in v1). Revocation takes effect on the next request without interrupting other clients.
4. Local Activity Logging: All incoming requests and execution outcomes (client, tool, allowed/denied status, duration, and result timestamp) are recorded locally in a JSON Lines operation log on your Mac; request payloads are not stored.

Not a sandbox

Mercury v1 is a privileged tool for the machine owner. It does not confine commands or files to a folder. Security comes from identity, authority, leases, audit and isolation, not from a command allowlist. Default client profile is owner-full.

Known limits

1. No human confirmation before actions in v1.
2. Scoped profiles limit capabilities by name, not by path or command.
3. The shared startup token cannot be revoked in v1.
4. The file reader blocks only files named .env*, so an AI with file access can read other local files, including Mercury's own token files.
5. The operations log is a local file that the machine user can edit, has no hash chain, and does not store request contents.
6. The screen lock (screenshots, opening apps, AppleScript) only coordinates calls that pass through Mercury: a second client waits up to 3 seconds and is then refused; the first client keeps the lock for 10 seconds after its last call; the lock is held in memory and is lost when the daemon restarts.
7. The Android device lease is issued per call and is not exclusive: two clients can still act on the same phone.
8. iOS and iPadOS support is device discovery only; Mercury does not control the iOS interface. Android actions need adb installed and USB debugging authorized.
9. A retried action whose outcome is unknown is reported as UNCERTAIN and is not repeated; Mercury does not roll it back, and this is not exactly-once delivery.
10. Durable sessions that survive restarts are a design goal; they are not claimed as verified.
11. The local daemon listens on 127.0.0.1 only; reaching it from a web AI needs a tunnel that you configure yourself.
12. macOS permissions (for example Screen Recording) still apply.
13. Mercury does not verify real-world side effects after execution.

4.2 What Mercury DOES NOT Do

To ensure transparent expectations, Mercury:

• DOES NOT send telemetry to Merlin&Partners servers: Mercury daemon listens locally on 127.0.0.1; data is only transmitted directly to the AI clients you configure;
• DOES NOT bypass macOS operating system security features (System Integrity Protection, TCC permissions, or keychain protections);
• DOES NOT grant permanent, unattended background root access without explicit administrative user escalation;
• DOES NOT train proprietary AI models on your code, local documents, or terminal commands;
• DOES NOT act as a backdoor for unauthorized third parties: inbound access requires valid access tokens and active client sessions.

4.3 Acceptable Use Policy (AUP)

Users of Mercury must abide by the following standards. You may not:

• Use the software to compromise, probe, or attack third-party computers, networks, or infrastructure without explicit written authorization;
• Deploy Mercury in mission-critical environments where software error could result in death, personal injury, environmental damage, or physical catastrophe;
• Attempt to disrupt local daemon services, bypass access controls, or flood the interface with denial-of-service traffic;
• Use automated agents via Mercury to harvest credentials, scan for private keys, or distribute unsolicited bulk communications.

4.4 Vulnerability Disclosure & Safe Harbor

We welcome and appreciate the assistance of security researchers and community developers in maintaining the security of Mercury.

Reporting Guidelines:

• Send vulnerability reports directly to: office@merlin-partners.com
• Please include:
  1. Detailed summary and description of the vulnerability;
  2. Proof-of-concept (PoC) code or reproducible step-by-step instructions;
  3. Affected software version and macOS environment details;
  4. Your contact details for coordinated follow-up.

Our Commitment:

• We acknowledge receipt of vulnerability reports within 48 hours;
• We conduct root-cause analysis and provide status updates as remediation progresses;
• We practice coordinated public disclosure: we ask researchers to allow at least 30-60 days for a fix to be deployed before publishing public advisories.

Safe Harbor:

If you make a good faith effort to comply with this disclosure policy when conducting security research on Mercury (no denial-of-service attacks, no intentional destruction of data, no access to other users' data), Merlin&Partners will not pursue legal action against you regarding your research.