BYOC Storage

With BYOC storage, the raw telemetry from your endpoints lands in a bucket in your own cloud account, and Asymptote’s hosted control plane reads it with access you grant. You own the bucket and every object in it, and revoking Asymptote’s read access stops it loading anything new. Asymptote runs the dashboard, search, detections and policy checks. See Hosting Options for how this compares with the other options.

How data flows

1. Upload. A Vector forwarder on each endpoint uploads compressed batches of events to your bucket, with a credential that can add objects under one prefix. It cannot read or delete objects. On Google Cloud it cannot list them either; on AWS it can list object names by default, because the forwarder’s startup health check needs s3:ListBucket (see the endpoint writer row below).
2. Notify. Each new object posts a notice to a queue or subscription in your account, one per stream (runtime for agent activity, inventory for what is installed). The queues let Asymptote load objects in any order, so an upload that arrives late, from a laptop that was offline, is never skipped.
3. Load. Asymptote’s loader reads the notices, fetches each new object with read-only access, and loads it into your organization’s own tables in Asymptote’s analytics store.
4. Use. The dashboard, search, detections and background reviews read those tables, as in Asymptote Cloud.

What you run and what Asymptote runs

What Asymptote can see

Asymptote reads what your endpoints upload, after Beacon’s local redaction of secrets, and keeps a copy in its analytics store so the dashboard can search it. The bucket forwarder uploads events in full: prompts, the commands agents ran and their output, tool inputs and outputs, and file paths and diffs. The Metadata-only privacy mode is a setting of the Asymptote Cloud forwarder and does not apply to uploads to your bucket. Revoking the read credential stops new loads at once. The copy Asymptote already loaded stays under your agreement’s retention terms unless you ask for it to be deleted.

Policy enforcement with BYOC storage

Policy enforcement does not go through your bucket. The hooks send each prompt or tool call being checked straight to Asymptote’s policy service. Turning enforcement on also needs more than that today: beacon endpoint enforcement enable works only on a Mac connected to Asymptote in system mode (beacon endpoint connect --system), because it proves the device with that connection’s key. A connected Mac also runs the Asymptote Cloud forwarder, which uploads its runtime telemetry to Asymptote’s ingest as well as to your bucket, and disconnect --keep-credentials leaves the Mac not connected, so enforcement refuses to turn on. So with enforcement on, your telemetry also reaches Asymptote Cloud. --no-backfill on connect skips only the 30-day history upload. Talk to your Asymptote contact before turning enforcement on in a BYOC storage deployment.

The BYOC component, by cloud

Get started

1. Ask your Asymptote contact to enable your organization for BYOC storage.
2. Follow the guide for your cloud: Amazon S3 or Google Cloud Storage. Each covers the bucket, the access, what to send Asymptote, the rollout to your Macs and how to check that data arrives.
3. Roll Beacon out with your MDM. For S3: Jamf, Fleet or Rippling. For Cloud Storage: Jamf or Rippling. Each sets up the forwarder and its credential for your bucket.

Related