Asymptote Cloud

In Asymptote Cloud, your endpoints send their telemetry to Asymptote, and Asymptote stores it and runs everything that reads it: the dashboard, search, detections, policy checks and findings. You run only Agent Beacon on your endpoints. It’s the fastest way to start, and the option to pick unless a policy says the telemetry must stay in your own cloud. See Hosting Options for the other two.

How data flows

1. Enrollment. beacon endpoint connect enrolls the device with Asymptote. In system mode, the usual mode for a fleet, it opens the dashboard and a member of your organization approves the device. In user mode, the person’s own beacon login sign-in to Asymptote authorizes it instead. The device gets its own ingest key, stored in a file only Vector reads. Revoking the device on the dashboard stops its uploads within about a minute.
2. Upload. A Vector service on the endpoint sends new runtime events and the inventory baseline over HTTPS, with a disk buffer for offline periods. Each connect also sends the last 30 days of agent sessions, so the dashboard has history on day one.
3. Storage. The ingest service checks the key, stamps your organization on every event, and writes it to Asymptote’s bucket. Your organization’s events load into tables of their own; no other organization’s queries can reach them.
4. Use. The dashboard, search, detections and background reviews read those tables.

The Managed architecture page has the detail.

What you run and what Asymptote runs

What Asymptote can see

Asymptote holds what your endpoints send, after Beacon’s local redaction of secrets:

• Standard mode sends retained content: prompts, responses, tool inputs and outputs, commands and their output, file paths and diffs.
• Metadata-only mode removes that content on the endpoint before upload, and sends identifiers, hashes, counts, timestamps, commands, file paths, token usage and other structured metadata.

When policy enforcement is on, the hooks send the prompt or tool call being checked to Asymptote’s policy service, whichever privacy mode the device forwards in. Telemetry is stored on Google Cloud in the United States. Ask your Asymptote contact about retention terms and other regions.

Get started

1. Request access at asymptotelabs.ai/contact. Asymptote enables your organization for managed ingest.
2. Install Beacon on a test machine and connect it to Asymptote. The CLI’s default service is beacon.sh, so name Asymptote explicitly:
   Connect a machine to Asymptote

   sudo beacon endpoint connect --system --dashboard-url https://asymptotelabs.ai
   
   A member of your organization approves the device in the browser that opens. To connect in user mode instead, sign in first with beacon login --auth-url https://asymptotelabs.ai, then run beacon endpoint connect --dashboard-url https://asymptotelabs.ai; the URL must match the sign-in. Try it on one Mac walks through a package install.
3. Roll Beacon out to your fleet with your MDM. See MDM deployment.

Move to BYOC later

Every option uses the same Beacon events, so you can move. Adding a bucket forwarder does not stop the Asymptote Cloud forwarder: the two run side by side. To move to BYOC storage:

1. Set up your bucket and roll out the bucket forwarder, as in the BYOC storage guides.
2. On each endpoint, run sudo beacon endpoint disconnect --system (or beacon endpoint disconnect for a user-mode install). It stops the Asymptote Cloud forwarder and removes the device key.
3. Revoke the devices on the dashboard’s Beacon Endpoints page, so their keys stop working server-side.

If you use policy enforcement, read Policy enforcement with BYOC storage first: enforcement needs the device to stay connected. What Asymptote already holds stays under your agreement’s retention terms unless you ask for it to be deleted.

Related