01Trust boundaries
Agent output is untrusted input.
Titles, Markdown, recipe fields, tags, paths, repository details, and other provenance can all originate with an AI client. Treat them as content to inspect, not instructions to execute. DraftRelay does not run saved command blocks, scrape terminal scrollback, read hidden reasoning, or send a saved artifact directly to Slack, email, or GitHub.
The hosted service and the open-source local server have different boundaries. Hosted access is authenticated and workspace-scoped. The local server is intentionally unauthenticated and loopback-only. Putting the local process behind a public proxy is unsupported; use the hosted architecture when remote access and multi-user isolation are required.
02Identity
Short-lived OAuth access for remote MCP clients.
Hosted users can sign in with an email and password and can add a passkey. Passwords are hashed with Argon2; production email addresses are verified. Remote MCP clients use OAuth discovery and dynamic client registration. Access tokens are short-lived, refresh access is bounded, and the requested output scopes are shown during authorization.
Connections can be listed and revoked. Revocation removes the relevant access, refresh, and consent records so that a former client cannot continue using that grant. Do not approve a client name you do not recognize, and revoke clients you no longer use.
03Data
Every hosted query carries a workspace boundary.
Hosted projects, artifacts, revisions, representations, provenance, findings, copy receipts, and usage records are stored with a workspace identifier. Database operations run inside that tenant context. Item identifiers alone are not treated as authorization.
Production traffic must use HTTPS and secure cookies. Authentication and MCP endpoints are rate-limited, request logs redact common authorization, cookie, token, password, and secret fields, and security-sensitive events can be audited. These controls reduce risk; they do not make arbitrary output safe to publish.
04Guardrails
Warnings stay attached to the revision that produced them.
The scanner checks titles and Markdown for common high-risk patterns such as private keys, bearer tokens, provider credentials, JWTs, credentials embedded in URLs, and likely secret assignments. Projects can warn, block high-severity findings, block all findings, require acknowledgement, or require review before copy. Custom project patterns are also supported.
Findings shown to a reviewer use a redacted preview and line information rather than returning the matching secret value. Scanners have false positives and false negatives. Always inspect sensitive client, infrastructure, incident, financial, and personal information before copying it elsewhere.
A branch, commit, test result, or file reference is shown as unknown when the client did not provide it. Its presence records a claim; it does not independently prove that claim.
05Safe operation
Use the narrowest workflow that solves the handoff.
- Save only the final artifact; remove raw logs and unrelated context before persistence.
- Keep credentials out of prompts and saved content even when scanning is enabled.
- Review destination previews, especially links, commands, tables, and @mentions.
- Use project policies for sensitive work and revoke clients after temporary access.
- Protect local SQLite files, hosted exports, and backups as you would protect the source material.
- Delete artifacts and accounts that are no longer required.
06Disclosure
Report suspected vulnerabilities privately.
Do not place exploit details, private artifacts, credentials, or personal data in a public issue. Send a concise description, affected surface, reproduction steps, and likely impact to hi@rashy.me. Rahit Ash will use that information to investigate and coordinate an appropriate response.