Security and data handling

This page describes how Lightcone isolates sessions, how API keys are protected, and what happens to the data that flows through the platform, so you can decide what to run on it and how.

Isolation

Every computer you create is an isolated virtual machine with its own filesystem, network stack, and display. Sessions do not share state with each other or with other customers.

When a computer is deleted, explicitly or by timeout, the VM is destroyed along with its filesystem, unless the session was created with persistent: true (see Session state below).

API keys

• Keys start with the sk_ prefix and are scoped to your organization.
• Keys are hashed at rest: only a hash is stored on our side, and the full key is shown exactly once, at creation. If you lose it, generate a new one.
• Keys can be revoked at any time in the dashboard.
• Temporary keys are supported for short-lived or scoped access, useful for CI jobs or handing limited access to a service.

Keep keys in environment variables or a secrets manager, never in source code:

from tzafon import Lightcone

client = Lightcone()  # reads TZAFON_API_KEY from the environment

import Lightcone from "@tzafon/lightcone";

const client = new Lightcone();  // reads TZAFON_API_KEY from the environment

Never commit an API key to source control or embed it in client-side code. If a key may have leaked, revoke it in the dashboard immediately.

Data flows

Different response types are handled differently:

Data	How it’s handled
Screenshots	Uploaded to object storage; returned as presigned URLs valid for roughly 7 days, after which the links expire
Page HTML	Returned inline in the API response
Shell output	Streamed inline in the API response
Prompts and model outputs	Processed to provide the service (Tasks and model-compatible endpoints)

Anyone with a screenshot URL can open it until the link expires. Treat screenshot content as sensitive: avoid capturing screens that display passwords, tokens, or other secrets, and don’t forward screenshot URLs to untrusted parties.

Credentials and logins

The recommended way to log in to third-party sites is the login handoff pattern: you (or your user) take manual control of the session and type credentials directly into the page. Credentials entered this way go straight into the isolated session. They are never sent through the model or included in task context.

Practical guidance:

• Use persistent: true sessions so a human enters credentials once and the saved session is reused afterwards.
• Never put passwords in task instructions. Instructions are processed by the model; credentials in them defeat the point of the handoff pattern.
• Prefer accounts with the minimum privileges the task actually needs.

See Logins and sessions for the full pattern.

Session state and persistence

• persistent: true saves session state associated with your organization: cookies and site storage for browser sessions, disk state for desktop sessions. Reusing the session restores that state.
• Non-persistent sessions (the default) are discarded when the computer is torn down.

Delete persistent sessions you no longer need from the dashboard or API; saved state is retained until you do.

Network

• All API traffic uses TLS.
• The API allows cross-origin requests, but it is designed for server-side use. A browser app calling the API directly would expose your key to anyone who opens dev tools. Keep keys on your server and proxy requests through your own backend.

Security documentation and questionnaires

For security documentation, questionnaires, or questions about data handling that this page doesn’t answer, contact support@tzafon.ai.

Next steps

• Logins and sessions: the login-handoff pattern in detail
• Production checklist: hardening your integration before launch
• Errors and status codes: how the API reports failures