Security and operations

Before production:

• Make every deployed authentication resolver fail closed.
• Keep provider and connection credentials outside model context and logs.
• Require approval for state-changing tools and sensitive browser actions.
• Set step, tool-call, token, cost, Sandbox, Browser, child, and depth limits.
• Check tenant identity on every thread, event, approval, attachment, and audit request.
• Keep write idempotency keys and block automatic replay of unknown outcomes.
• Test Worker and Durable Object restart during streams, tools, approvals, and archive sealing.
• Run npx flary doctor after each deployment change.
• Before 1.1.0, sweep legacy beta.9 threads with explicit IDs only: npx flary doctor . --app-id my-app --threads-file legacy-thread-ids.txt. Provide FLARY_ACCESS_TOKEN in the environment or .dev.vars; the command processes IDs sequentially and reports exported, already_exported, active, and failed outcomes. Retry every active or failed result. Completed archives are immutable and SHA-256 verified.

Use Cloudflare logs and Flary’s tenant-scoped usage and audit APIs for operations. Public audit views contain hashes, sizes, state, and safe metadata, not secret values.

Process output has bounded retention and cursor replay. Schedule history exposes failed or pending dispatches and their retry timing. Use these alongside audit.list() to investigate a thread. The exported flary/telemetry store is available for applications to wire into their own tracing or reporting; deploying Flary does not automatically install a telemetry dashboard or exporter.