Source: https://chiselbase.com/safety/ # Make production changes deliberately. Browse production read-only, confirm the target before writing and review supported changes in the audit log. Explore how the safeguards work and where they apply. ## Four steps between a click and production. Keep production read-only until you deliberately enable writes. Environment labels, write protection and confirmations work together to help you verify each change. The steps below show which checks run in the interface and which run in the Rust core. 1. ### Environment label You label each connection development, staging or production. The steps below depend on it. set by you 2. ### Write protection A new production connection starts write-protected. It blocks everything except reads until you lower the protection level, which in production asks for the project ID. enforced in the Rust core 3. ### Confirmation Each operation gets the confirmation its environment requires, from none to typing the project ID. Where its environment requires one, the write doesn’t run without a valid token. enforced in the Rust core 4. ### Typed project ID Deletes, bulk changes, Rules deploys and settings changes in production ask you to type the project ID. Confirm stays locked until it matches. Agents don’t type it: your Allow click stands in for the dialog. checked by the dialog There is no cooldown and no rate limit. Guardrails ask. They don’t make you wait. · guardrail · production · write protection Screenshot: Overview of the Fernway Production connection. A red bar across the top reads PRODUCTION fernway-prod and, on the right, Write protection on with a lock. Under the name sit the project ID fernway-prod, a red Production label and a Write protection on chip. The access list says All permissions granted for a service account and lists twelve permissions, from Read Firestore to Realtime Database, each with the role owner. At the bottom: a Write protection: on button and Remove connection. Twelve permissions granted, and still read-only. Write protection on this production connection lets only reads through until you lower it. · guardrail · production · typed project ID Screenshot: The “Delete document?” dialog for orders/ord_10384. It says the action targets a Production environment and asks to type the project ID fernway-prod. The field holds fernway-pr, and the Confirm button next to Cancel is disabled. The last step, halfway typed. fernway-pr is not fernway-prod, so Confirm stays disabled. ## A confirmation is a token, not a pop-up. The Rust core issues a confirmation token for each guarded operation. A token works once, expires after 30 s and is bound to one connection, one environment and one operation. The core checks the token. The typed project ID is checked by the dialog, not by the core. What each operation asks for, by environment | Operation | Development | Staging | Production | | --- | --- | --- | --- | | Read | no dialog | no dialog | no dialog | | Write | no dialog | confirm | confirm | | Delete | confirm | confirm with details | type the project ID | | Bulk change | confirm | confirm with details | type the project ID | | Delete a collection | confirm with details | type the project ID | type the project ID | | Deploy Rules | confirm | confirm with details | type the project ID | | Change settings or lower protection | confirm | confirm with details | type the project ID | - Write protection comes first. While it is on, everything except reads is blocked, whatever the table says. - Firestore migrations and imports, and Storage transfers, count as bulk changes on the target. - The emulator always counts as development. ## What the audit log records, and what it misses. Most writes you make in the app get their audit entry before they run, and stop if it can’t be written. Agent and chat writes are logged right after they run. Some Storage folder operations and emulator actions are logged afterwards or not at all. With a local data policy of none, nothing is logged. · audit log · last 7 days Screenshot: Audit log with the tabs Log and Can be undone (2) and an Export CSV button. Filters: search, all areas, all actors, all statuses, last 7 days, 5 matches. A table with the columns time, action, target, actor and status, grouped by day. Today: a document deleted by App, then two entries “Document written, 2 writes” by Agent · claude-…, one of them marked Failed. Yesterday: a user changed by App. 27 September 2026: Rules published for Firestore by App, marked Failed. The three App rows carry a shield icon for a confirmed write. Filter by area, actor, status and time. Here: 5 writes in the last 7 days, two of them failed. Export CSV takes the filter with it. **ui** you, in the app **mcp:** an agent, by a slug of its client name, such as claude-desktop **chat** the built-in chat ## Restore supported changes with local undo snapshots. For the actions below, Chiselbase attempts to save the previous state locally so you can restore it from the Undo tab. Undo requires a successfully saved snapshot. If a snapshot fails, the change can still proceed. Metadata-only and none policies disable undo. Actions outside this list have no undo. ### Undo covers - Firestore document edits and deletes - Completed bulk runs - Whole collections, from a backup file - Realtime Database edits and deletes ### Final once confirmed, for example - Creating, changing or deleting Auth users - Moving or copying documents - Firestore and Auth imports, Firestore migrations - Storage changes and Rules deploys - Index, backup and bucket settings · audit log · undo · production Screenshot: The Can be undone tab of the audit log, selected next to Log, with the count 2. A table with the columns time, summary, actor and kind. First: Document deleted, orders/ord_10391, by App, kind Reset document. Second: Firestore write (agent), 2 writes, by Agent · claude-d…, kind Reset documents. A deleted document and an agent’s Firestore write, both still undoable. Both are in production. Undo puts the documents back as they were. Before a collection delete, Chiselbase writes a local snapshot to your temp folder. If that snapshot fails, the delete still runs. Treat it as a safety net, not as a backup. ## Set up recovery before you need it. Where undo stops, the way back is a Firestore backup or point-in-time recovery. Configure point-in-time recovery, delete protection and backup schedules in the app. A restore or clone creates a new database and doesn’t overwrite the current one. Without a backup, PITR or an undo snapshot, a confirmed delete is final. ## Stored keys live in your OS keystore. Chiselbase stores service-account keys, Google sign-in tokens and your license key in the keystore of your operating system. Your Google credentials never reach the interface or an agent. Only the Rust core uses them. **Windows** Windows Credential Manager **macOS** macOS Keychain **Linux** Secret Service Application Default Credentials and Firebase CLI logins are not copied. Chiselbase reads them where gcloud and the Firebase CLI keep them. Agents never receive Google credentials. The proxy only carries a client token to the app over loopback, port 48620 by default. Chiselbase can find credentials already on your machine. It uses none until you confirm. ## Where production safeguards apply. Guardrails apply to writes made through Chiselbase. Anything that writes around it is outside its reach. - Writes from the Firebase Console, the Firebase CLI or your own scripts. - Writes from your app’s clients. Security Rules still decide what they may do. - Confirmed writes that undo doesn’t cover, as listed above. - A connection you labelled development that actually points at production. ## Try it on your own project. Browse with write protection, review changes and recover supported edits. Connect a project and choose its environment to get started. [Download for Windows](https://chiselbase.com/download/) [Compare Free and Pro](https://chiselbase.com/pricing/) Windows · x64 or ARM64 · Installer (.exe)