Security

How Furnace decides who may do what, what it records, and how to reach us about a vulnerability.

The model

• One authorization path. Human UI, REST, and MCP run the same permission checks on the same server — there is no surface where a hidden control is still callable, and nothing is enforced only in a client.
• Authority only narrows. Access tokens are bound to a user and can be scoped below — never above — that user's permissions. See Personal access tokens.
• Namespaces isolate. Each app's data lives in its own namespace; a token scoped to one namespace cannot read another, and cross-namespace access is never implicit.
• Everything is attributed. Every mutation lands in an audit trail under the identity that made it — a person clicking or an agent calling with their token look the same to the record.
• Server-side resolution. Entitlements, flags, and permissions resolve on the server; clients and agents are told outcomes, never targeting rules.

Your side of the contract

• Treat tokens as passwords: never commit, log, or share them.
• Prefer narrow tokens — read-only, namespace-scoped, expiring — for anything long-lived or held by an agent.
• Revoke on any suspicion; revocation is immediate on every surface, and Sign out everywhere kills all interactive sessions.

Reporting a vulnerability

If you believe you've found a vulnerability, contact us through falcata.io(opens in a new tab) with enough detail to reproduce it. We confirm receipt, and we ask that you not disclose publicly until we've had a reasonable window to fix it. Please never include live tokens or personal data in a report.