# Security

> How AkaPhone handles sign-in, API keys, model keys and device isolation, what is shared between accounts on a host, how long data is kept, and how to report a vulnerability.

Source: https://akaphone-docs.pages.dev/security/

This page describes how the hosted service works today, including its limits. If something here does not match what you see, tell us at [security@akaphone.com](mailto:security@akaphone.com).

## Sign-in and sessions

- **Google is the only way to sign in.** There are no AkaPhone passwords to leak or reset. The OAuth flow uses PKCE (S256), a single-use `state` bound to your browser, and a `nonce`; the ID token's signature, issuer, audience, expiry and `email_verified` claim are all checked.
- **Accounts are tied to a Google account**, not just an email address. A different Google account presenting the same email is refused rather than merged.
- **Sessions** are a random id in an `HttpOnly`, `Secure`, `SameSite=Lax` cookie set only on the API host, signed with HMAC so forged cookies are rejected outright. Sessions last 30 days; signing out deletes them.
- **Cross-site requests are refused.** Requests authenticated by the cookie that change anything must come from the dashboard's origin, and so must live-stream connections. Other sites get no CORS access.

## API keys

- Keys are 43 random characters after `ak_live_`. Only a **SHA-256 hash** is stored, so a database leak does not reveal usable keys, and AkaPhone cannot show you a key again.
- Keys can be revoked at any time and stop working immediately. `last_used_at` helps spot keys that are unused or used unexpectedly.
- Keys have no scopes: each has the full rights of your account. Use one per machine or pipeline.

## Model keys

Your Gemini, Anthropic or OpenAI key is sent per task in the `X-Model-Key` header and is **never stored**:

- The API holds it in memory for the request and passes it to the device's host in the task message. It is not written to the database, KV storage, logs or the audit trail, and is never returned. Automated tests check the database, audit log and KV for it.
- On the host it lives only in the memory of the agent and in the environment of that task's ARTEMIS process: not on disk, not on a command line, not in logs. Logs, the task log artifact and the task result go through a redactor that strips it.
- The key never reaches the Android system on the device.

The dashboard keeps the key you paste in your browser's local storage on that computer, so you do not have to paste it every time. **Forget key** removes it. See [Model keys](https://akaphone-docs.pages.dev/guides/model-keys/).

## Device isolation

Each device is its own Android container on a AkaPhone host:

- **Own network.** Every device has a separate Docker network with traffic between containers disabled.
- **Egress filtering.** Devices cannot send email (SMTP ports are blocked), reach the cloud provider's metadata service, or reach private network ranges. Other outbound internet traffic is allowed, so apps work normally.
- **No inbound access.** Hosts have no open inbound ports. They connect out to AkaPhone's control plane. The Android debug bridge listens only on the host's loopback interface.
- **Nothing persists.** When a device stops, its container and disk are deleted. Only [snapshots](https://akaphone-docs.pages.dev/concepts/snapshots/) you take survive.

> **Devices from different accounts can share a host**
>
> To run Android, device containers need elevated (privileged) access to the host kernel. Devices from different accounts can run side by side on the same host. If an attacker fully compromised one device, for example through a malicious APK combined with an Android or kernel privilege-escalation bug, they could realistically break out of the container to the host, and from there see the screens, app data and anything typed into other devices on that host.
>
> We treat that as a real risk, not a theoretical one. Until per-account host isolation is available on the hosted service (see the [roadmap](https://akaphone-docs.pages.dev/roadmap/)):
>
> - **Use test accounts and test data** on devices. Do not sign in to production admin accounts, personal email or banking.
> - **Do not type secrets into a device** that you would not want another tenant to see. Your AkaPhone API key and your model key never enter the device, so they are not exposed this way.
> - **Install only APKs you trust.**

## Data and retention

| Data | Where | Kept for |
|---|---|---|
| Account (Google id, email, name, avatar URL) | Cloudflare D1 | While your account exists |
| API key hashes | Cloudflare D1 | Until revoked |
| Device records | Cloudflare D1 | Kept for your history |
| Task records and steps | Cloudflare D1 | Your plan's retention: 7, 30 or 90 days |
| Task artifacts (video, screenshots, trace, log) | Cloudflare R2 | Your plan's retention: 7, 30 or 90 days |
| Uploaded APKs | Cloudflare R2 | 7 days |
| Snapshots | The device host's disk | Until you delete them or the host is retired |
| Credit ledger | Cloudflare D1 | Kept; usage rows are combined by month after 90 days |
| Audit log (sign-ins, key and device actions) | Cloudflare D1 | 180 days |
| Model keys | Memory only | Never stored |

Device hosts run in Hetzner data centres in Germany (region `eu-central`). The API, database and file storage run on Cloudflare. Payments are handled by Lemon Squeezy as merchant of record; AkaPhone never sees your card details. Database backups are taken nightly.

Artifacts and uploads are reachable only through short-lived presigned URLs (15 minutes) issued to your account.

## Transport

All endpoints are HTTPS-only with HSTS. API responses carry a restrictive `Content-Security-Policy`, `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff` and `Referrer-Policy: no-referrer`.

## Acceptable use

Do not use AkaPhone to automate accounts you do not own, create accounts in bulk, scrape, commit ad or review fraud, bypass rate limits or CAPTCHAs, or break another service's terms. Accounts that do are suspended: every API key and session stops working and running devices are stopped.

## Reporting a vulnerability

Email **[security@akaphone.com](mailto:security@akaphone.com)** with what you found, how to reproduce it, and its impact as you understand it. Please:

- give us a reasonable time to fix it before disclosing it publicly,
- test only against your own account and devices, and do not access other users' data,
- avoid denial-of-service testing and anything that degrades the service for others.

We read every report and will keep you updated while we work on a fix.