Isolation model
Every agent instance runs in its own Firecracker microVM on Fly Machines — not a container on a shared kernel. A runaway loop or compromise inside one instance cannot reach the filesystem, process tree, or network namespace of any other instance, including other instances owned by the same account.
Each microVM has:
- Its own kernel and minimal root filesystem.
- Its own block-mounted Fly Volume for persistent state.
- Its own private IPv6 address (6PN) and outbound NAT for the public internet.
- A unique public subdomain with auto-issued Let's Encrypt TLS.
Outbound network from an instance is unrestricted by default — agents need to call LLM APIs, fetch packages, scrape web pages. Inbound traffic is allowed only on the agent's declared port, only over HTTPS, only via the subdomain.
Data at rest
| What | How |
|---|---|
| Per-instance volumes | Encrypted at the Fly Volume layer (block-level, AES-XTS). Decryption keys held by Fly; tied to the volume. |
| Model provider API keys | Application-level encryption with AES-256-GCM. Encrypted before hitting Postgres; decrypted only at instance create / start to inject as an env var. We can't recover plaintext from a database dump alone. |
API tokens (gn_live_…) | We store sha256 of the token, not the token itself. A leaked database snapshot can't be used to call our API. |
| OAuth session tokens | Stored server-side, looked up by the cookie value (also random, unguessable). Sessions can be revoked by deleting the row. |
| Database (Postgres) | Hosted on Fly with disk-level encryption. Backups are encrypted and retained 90 days. |
Data in transit
- All public endpoints (
gentity.ai,<subdomain>.gentity.ai) require HTTPS. HTTP is redirected. - TLS certificates are issued by Let's Encrypt and rotated automatically.
- Internal traffic between the control plane and Fly Machines uses Fly's 6PN private mesh.
- The WebSocket terminal proxy (
compute ssh) inherits the same TLS — no plaintext fallback.
Authentication and authorization
- Dashboard sign-in via GitHub or Google OAuth. We don't store passwords.
- API access via Bearer tokens (
gn_live_…). Mint and revoke at /dashboard/settings/tokens. - Tokens scope to the entire user account. Mint one per machine / CI environment so they can be revoked individually.
- Every API route checks Bearer token first, then session cookie. Both paths resolve to the same user-id check before any data access.
The subdomain caveat
Anyone who knows <your-subdomain>.gentity.aican reach your agent's UI directly (no Gentity-level auth in front of it). We chose this model because each agent has its own auth surface upstream, and adding a second layer would break workflows like embedding the agent UI in an iframe or hitting it from a CI pipeline.
Mitigations on our end:
- Subdomains are random 8-character strings with a 2-character agent prefix. Effectively unguessable.
- They're only handed out to the account that created the instance. We don't list them publicly.
- You can
compute stopany time to take the subdomain offline.
Practical advice: treat the subdomain like a password. Don't paste it into public chat, don't commit it to repos, don't share it with people you don't want using your agent.
Operational practices
- Production deploys go through GitHub Actions with a deploy token scoped to the Gentity control-plane Fly app only. No engineer SSHes into production.
- Database migrations run on container start (
prisma migrate deploy), tested in a staging schema before promoting. - flyctl tokens have scoped access; they can't reach personal Fly accounts.
- Secrets are stored in Fly app secrets, never in the repo. The repository is private; the CLI repo (gentityapp/cli) is public but contains no credentials.
What we explicitly don't have yet
We'd rather be straight about gaps than imply we have controls we don't.
- No SOC 2 / ISO 27001 / HIPAA / PCI attestations. We use providers that hold these (Fly, Cloudflare, Stripe), but Gentity itself is not audited.
- No 2FA beyond what GitHub / Google enforce on their OAuth side. Hardware-key 2FA on the dashboard is on the roadmap.
- No formal SLA. We monitor and aim for 99.9% uptime, but the terms today don't commit to a credit schedule.
- No published bug bountyyet. We'll honor reasonable disclosure reports and credit reporters; see below.
Reporting a vulnerability
Email security@gentity.ai with details. Please don't open a public GitHub issue for anything that lets someone access another user's data, escape a microVM, or bypass authentication.
We try to acknowledge within 2 business days and triage within 5. For reproducible high-severity findings, we'll publicly credit you (with permission) in a security note once the fix has shipped.
Please don't:
- Test against other users' accounts or instances.
- Run DoS / DDoS / brute-force tests.
- Exfiltrate or retain real user data — a proof-of-concept that the access is possible is enough.