Backstage OpenClaw Drive
Privacy Policy
Effective date: November 11, 2026. This policy covers the private tool. The website policy remains the Privacy Policy for backstageinteractive.com.
I adopted the retention rules on November 7, 2026. Adopting them did not delete anything already stored. Periodic cleanup, complete deletion tooling, and a restore drill are not implemented. The day counts below are manual targets. They are not a promise that material disappears on that day, and they are not automatic expiry.
Who operates the app
The OAuth app name is Backstage OpenClaw Drive. I, Kevin Love, operate it as Backstage Interactive. It is a private tool for my own use. It is not a public product on the website.
I am not the operator of OpenClaw in general. OpenClaw is the software this tool runs. This policy is about this app only.
What this policy covers
This policy is about the private Drive tool described on the app page. It does not cover the website contact forms, KeyProse, WildThesis, or a client site.
The website forms and this tool are different. The forms on the studio homepage, Website Fixes, and the Google Business Profile page collect the notes described in the website Privacy Policy. Those forms do not request Google Drive. Sending a form does not authorize this app, and authorizing this app does not send a website form.
Drive access now
A dedicated Google account has authorized Drive for this app. The app is in Testing mode, not a production publishing status. The account address, test users, and credentials are not printed here.
The scope is https://www.googleapis.com/auth/drive. It allows the app to view, create, edit, and delete Drive files that account can access.
The connector is set to a folder named Backstage Work. That restriction is in the connector configuration. It is not a boundary Google enforces on the scope.
What was tested
One test used a 171-byte file. The upload, the download, and a byte-for-byte comparison passed. The file remains in Deliverables and belongs to the dedicated automation account. That is one test. Routine Drive exchange is not enabled, and Chief integration is not enabled.
The 7-day and 30-day rules for transfer and staging copies apply if that exchange is turned on. They are a future requirement, not a workflow running now.
Server and other services
OpenClaw runs on a DigitalOcean server. Daily backups of that server are enabled. I had already confirmed that they were turned on. DigitalOcean’s documents for the daily plan describe a standard seven-day rolling retention. I checked those documents on November 7, 2026: the backups quick start (opens in a new tab) and how backups convert to snapshots (opens in a new tab). Seven days is that documented standard. It is not a fresh audit of this account’s expiry setting. A copy can remain until that restore point actually expires.
A full-server backup image is not edited to delete one file. Daily backups are not routinely converted into snapshots kept without an end date. Restoring a backup has not been tested. Manual snapshots, exported backups, and migration archives are a separate hold. The seven-day daily rule does not cover them.
OpenClaw uses Telegram for conversations with me. The public website is hosted on Netlify and does not store this tool’s Drive files. Routine Drive exchange and Chief integration are not enabled.
How Drive content is used
When OpenClaw’s AI reads a Drive file, it reads the file contents. The relevant content is sent to Abacus.AI for processing only, to carry out the request. OpenClaw does not store that content anywhere other than Google Drive, apart from the copies described in How long material is kept, such as temporary transfer copies.
OpenClaw does not use Google Drive data to train AI models. We use Abacus.AI under terms that do not permit using this data to train models, as stated in Abacus.AI’s privacy policy (opens in a new tab).
Backstage OpenClaw’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy (opens in a new tab), including the Limited Use requirements.
Drive data is used only to provide and improve user-facing features of OpenClaw for Kevin, never sold, never used for advertising, never used to train generalized AI models, and no human reads it unless the user gives permission, it is needed for security or abuse investigation, to comply with law, or it is aggregated and anonymized for internal operations.
How long material is kept
This is the operating policy I adopted on November 7, 2026. It is the rule I intend to follow. It is not a report that the server already enforces it. No cleanup was run when I adopted it.
Saved work stays until I ask for it to be deleted, or until an expiry I set for that project. Other copies follow the manual targets in the table, including temporary transfer copies. Automatic cleanup is not fully implemented. A deletion request covers controlled live copies first. Backups and outside providers are a separate step. Daily DigitalOcean backups follow that plan’s standard seven-day window. Manual archives do not. Revoking Google access does not delete copies. None of the day counts is a guaranteed deadline or a full automatic purge.
| Material | Target | Clock starts | Status |
|---|---|---|---|
| Saved work. My originals, references, final deliverables, and project knowledge I explicitly save. | Kept until I request deletion, or until an expiry I set for that project. Closed projects get an annual review. Authoritative work is not deleted because of age. | My deletion request, a project expiry I set, or the annual review. | Rule adopted. Adopting it did not delete existing work. |
| Transfer and staging copies | Remove within 7 days after a successful transfer and a verification of that transfer. | Successful transfer and verification. | Future rule. Routine Drive exchange is not enabled, so this is not an active workflow. |
| Failed transfer copies | Up to 30 days to investigate, then resolve or delete. The hold is not extended in silence. | The failed copy. | Future rule, for the same reason. Not an active workflow. |
| Inactive conversations and completed task records | 90 days. Active tasks are excluded. Work I explicitly select is kept separately as saved work. A file’s modification time, by itself, does not show that a conversation is inactive. | Last activity, or completion of the task. | Manual target. Periodic cleanup is not implemented. Older records have not been checked against this target. No cleanup has been run. |
| Inbound attachments and generated intermediate media | 30 days, unless I promote the item to saved work. | Completion of the related task. | Manual target. Not an automatic purge. |
| Diagnostics, application, and system logs | 30 days or less, using rotation that already exists. A single purge of every log at 30 days is not configured. Existing defaults differ. The instruction is also to keep unnecessary file contents, credentials, and full prompts out of logs. That instruction is not proof of what logs contain today. | Existing rotation, with 30 days as the target ceiling. | Manual target. The unified 30-day purge is not configured. |
| Security evidence | Up to 90 days after the incident is closed, and only what is narrowly necessary, with a written reason and restricted access. | Incident closure. | Manual exception. Not automatic. |
| Deletion receipts | One year after the matter is closed. A receipt is minimal and has no file content: an opaque id, dates, categories, the outcome, and provider limits. It does not include sensitive file names or file content. The ledger is kept apart from the server recovery image. That separation is a manual step. | Closure of the deletion matter. | Manual target. The receipt tooling is not implemented. |
| Daily DigitalOcean backups | The daily plan’s documented standard is seven days, rolling. A copy can remain until that restore point expires. One file is not removed from a full-server image on request. Backups are not routinely turned into snapshots kept without an end date. | DigitalOcean’s daily backup cycle. | Backups are enabled, as I had already confirmed. Seven days is the documented plan standard, not a new audit of this account’s expiry setting. |
| Manual snapshots, exported backups, and migration archives | Review and delete 30 days after a migration or restore has succeeded, the result has been validated, and recovery coverage has been checked. A longer hold needs a purpose and a review date. | Successful validation of that migration or restore, including the recovery check. | Manual target. Older archives exist. They do not expire on their own, and the seven-day daily backup rule does not cover them. |
Before older material is deleted, it is sorted into active work, saved work, and inactive material. Exceptions are written down. November 14, 2026 is a review deadline only. It is not a scheduled job, and nothing runs automatically that day. A later look at exceptions every 30 days is the same kind of manual deadline. No cleanup has been run. Older records have not been measured against the 30-day or 90-day targets.
Deleting material
Deletion under this policy is a manual process. The tooling for a complete deletion is not implemented. The steps below are the rule, not a claim that a button already does them.
- Confirm that the request is mine, and confirm the precise scope.
- Deleting a Drive original has to be an explicit choice. Deleting a cache or staging copy is not that choice.
- Pause related transfers, tasks, and any queue that would import the material again.
- Write the content-free receipt outside the server recovery image.
- Find the controlled copies, indexes, logs, and backups the scope covers. Remove those. Leave unrelated work in place. Confirm before the live copy is removed.
- The target for that controlled live deletion is within 7 calendar days after the scope is confirmed. That is a manual target, not a service level.
- Closing the request is a later step. It waits until backup expiry and provider limits are accounted for. Live deletion and full closure are not the same event.
- Then check that no live or indexed copy remains, and that nothing is queued to bring the material back.
Removing a file link is not physical sanitization of a disk. A file in Google Drive Trash can still be recovered. It is not permanent erasure. A copy already held by Abacus.AI or Telegram is deleted through that service’s own process. Deleting a copy on this server does not erase it there.
Revoking Google access
Revoking the Google authorization invalidates that authorized access. Copies already downloaded stay where they are. Deleting the active credential file does not remove credentials that remain inside older backups. Tracking when those backups expire, and rotating credentials after a compromise or a restore, are manual steps. Manual archives are separate from the seven-day daily backups.
Restore safeguard, not yet drilled
This is the restore rule. It has not been implemented as a drill, and a restore has not been run successfully under it.
A restore is done in isolation. The gateway, the Telegram sender, transfers, and paid tasks stay off. The deletion ledger outside the server image is consulted. Deletions made after the backup are applied again. Stale credentials and queues are removed. Indexes are rebuilt. The result is checked before the server is put back on the network.
Questions
Use the contact form on the studio homepage. Say that the note is about Backstage OpenClaw Drive. That form is a website form. It collects the name, email, topic, and note described in the website Privacy Policy. It does not connect to Google Drive.
The OAuth consent screen is already configured with a support address for the dedicated automation account. That address is not printed on this website. Publishing it is a separate choice from having it configured. The public contact path remains the homepage form. This site does not publish a phone number or a street address.