Deployment boundary
This website includes an authenticated, server-backed demo dashboard and a separate contact-intake application. Drafts, settings, review decisions, schedules, channel state, and activity are real saved demo records. Sample social identities and seeded engagement metrics are illustrative. Explicit demo publishing changes a record without a network call; scheduling does not operate an automatic external publishing worker. No OAuth connection, social credential vault, MCP server, LLM integration, enterprise SSO, or remote media ingestion is enabled.
The contact endpoint validates requests and writes consented inquiries to a private server-side inbox. It does not send email or create a demo session. Demo users cannot browse contact records or receipts, including through exports or activity.
Threats considered include stolen application sessions, cross-workspace authorization errors, exposed access tokens, untrusted media, prompt injection in future agent instructions, malicious request replay, and administrator changes to execution records. A dark interface and an encryption algorithm alone do not mitigate these threats.
Current demo: isolation, storage, and request boundaries
The deliberately public login credentials are a demo entry gate, not a personal account secret. The server validates them and requires an explicit acknowledgment to use sample data in a private 24-hour session. Each new session owns an isolated seeded workspace. Knowing the shared credentials does not grant access to another browser’s workspace. The session cookie itself is sensitive; never share it or include it in support reports.
A 256-bit opaque token is stored in the pulseflow_demo cookie, with only its hash retained server-side. The cookie is HttpOnly, SameSite=Lax, Secure in production, scoped to the site path, and expires after 24 hours. No session token or password is placed in localStorage. Every private read, mutation, export, and deletion is authorized against the current cookie; client-supplied workspace IDs cannot select another visitor’s data. Private/authentication responses are not cacheable.
Mutations require the trusted request origin, compatible fetch metadata, JSON content type, and a body no larger than 64 KiB. Inputs and workflow transitions are checked server-side. Revision checks reject stale writes rather than silently overwriting another tab. Persisted rate limits bound login attempts and per-session writes without trusting forgeable client IP headers. Capacity is bounded to 500 active sessions, 100 posts and the newest 200 activity records per workspace. These are abuse safeguards for the demo, not distributed enterprise admission controls.
Demo data lives in private SQLite storage under PULSEFLOW_DATA_DIR, separate from CONTACT_INBOX_DIR. Directories and files have restricted permissions; transactions and parameterized statements protect update consistency and query boundaries. Saved state survives reloads and restarts only with the same valid session and persistent storage. Storage failures are errors, never successful in-memory fallbacks. Filesystem permissions are not database encryption: disk encryption, storage access, backups, TLS, and host hardening remain operator responsibilities.
Confirmed deletion or logout removes the workspace and invalidates its session. Expiry denies access after 24 hours; cleanup runs on startup/access and hourly while the process runs. Reset replaces the samples but keeps the original expiry and advances the revision. Local media bytes and blob URLs never enter the database; only planning metadata is saved. No export contains session tokens, token hashes, another workspace, or private contact records. See the implemented API contract for exact endpoints.
Credential vault isolation
The production vault design uses AES-256-GCM authenticated encryption. Each token encryption operation requires a fresh, unpredictable 96-bit initialization vector, a 128-bit authentication tag, and a key version. Reusing a nonce under the same key is forbidden. Additional authenticated data binds the ciphertext to the workspace, connection identifier, platform, and key version, so ciphertext cannot silently move between tenants.
Data-encryption keys must be envelope-encrypted by a hardware-backed key-management service. Application database backups contain ciphertext and key references, never master keys. Decryption is limited to a dedicated publishing worker identity with audited key access. Rotation requires decrypting with the recorded old version and re-encrypting with a fresh nonce and current version; revocation invalidates both jobs and cached plaintext.
Browsers and agents receive opaque credential references, not access or refresh tokens. Tokens must never appear in client JavaScript, analytics, error payloads, prompt context, queue messages, or debug logs. A publishing worker may hold a token in memory only for the authorized API operation. This is network isolation and least privilege—not an “air-gapped” vault: a component making online API requests is not literally air-gapped.
Egress proxy architecture
The reference request path separates intent from authority:
Creator review → consent record → authorized job
→ isolated worker → egress proxy → platform API
Browser / agent sees credential_ref, never the underlying token.Dedicated static egress IPs make allowlisting and incident attribution predictable; they are not an evasion mechanism and do not bypass platform quotas. The proxy permits only documented platform API hosts and required methods. Tokens are injected server-side after workspace and scope checks. Clients cannot choose arbitrary destinations, authorization headers, or credential identifiers from another workspace.
Media retrieval must reject private, loopback, link-local, and cloud-metadata destinations, including after DNS resolution and redirects. A production worker should retrieve only previously validated objects from an owned storage prefix, use short-lived signed URLs, cap response bytes, and reject unexpected MIME types. Raw user-provided URLs are not an unrestricted fetch proxy.
Infrastructure hardening
The live-service deployment design calls for non-root, read-only Docker containers with dropped Linux capabilities, pinned image digests, limited CPU and memory, and writable mounts restricted to the service that owns them. The current demo database and contact inbox each require persistent private writable storage outside public assets. A read-only deployment without those mounts cannot save data and must return an error, not a success message.
Public deployment requires a valid certificate, HTTPS redirects, an appropriate HSTS policy after HTTPS has been verified, request-size limits, and edge admission controls. Traefik is the intended edge router; TLS 1.3 is the live-service transport requirement where supported. Internal services must remain private. A website build or local HTTP run is not evidence that edge routing, TLS, or every host hardening control has been provisioned. Production demo cookies require HTTPS.
The site supplies frame denial, MIME-sniffing protection, restrictive device permissions, a referrer policy, and a self-origin content security policy. Next.js hydration requires inline scripts in the current configuration; the CSP is not represented as nonce-only. No third-party script, analytics beacon, or remote font is loaded. React text escaping is retained for user-entered content.
Contact intake independently rejects cross-origin requests, unsupported content types, invalid fields, and bodies larger than 16 KiB. A process-local admission limit caps intake at 30 requests per hour, with no stored IP addresses. This single-instance safeguard is not a distributed rate limiter; public multi-instance deployment would need shared controls. Request-body errors and storage errors remain failures visible to the user. Contact receipt access is an operator-only local procedure, not a dashboard feature.
Future tamper-evident audit trail
The current dashboard’s saved activity is a readable, bounded history of demo actions with the actor name recorded when an event occurs. It is not immutable, cryptographically chained, a team-access audit, or evidence of a social-platform publication.
The live-service record design chains each event to its predecessor using SHA-256 over a canonical representation of the previous hash and event payload. Payload fields include workspace, action, consent reference, UTC event time, platform response category, and a non-secret publication reference. Sensitive captions, token values, signed URLs, and private contact messages are excluded.
event_hash = SHA256(previous_hash || canonical_event)
event_time = UTC timestamp from the execution service
checkpoint = independently retained signed chain headHash chaining alone does not make a log immutable: an administrator could rewrite an entire unanchored chain. A live deployment must write signed checkpoints to an independently controlled append-only or retention-locked store, control deletion privileges, and verify chain continuity during export. Clock synchronization and monotonic ordering require operational monitoring.
Workspace boundaries and future team roles
The current demo authorizes all workspace access through its isolated session and is single-user: reviewing and approving sample content demonstrates workflow states, not separation of duties between people. Editing reviewed, approved, or scheduled input invalidates approval and clears the schedule. Disconnecting a sample channel returns its affected unpublished work to draft while preserving its content and published history; reconnecting does not resurrect approvals or schedules.
For a future team service, authorization must be checked at every read, publish, disconnect, and export boundary. Editors prepare drafts; publishers approve specific payloads; workspace administrators manage memberships and connections. Administrative access must not automatically permit reading decrypted credentials. Service identities receive only the methods and storage prefixes they need. These roles, enterprise SSO, and organization provisioning are not implemented by the demo.
Changing a caption, media object, destination, privacy level, or commercial disclosure must invalidate prior approval. A future live scheduled job must re-check account connection, token validity, granted scopes, platform availability, and creator restrictions immediately before transit. Revoked permissions cancel work rather than triggering a fallback account. Provider errors, quota limits, and cancellation are distinct states; acceptance of a job is not proof a post is published.
Temporary media transit and deletion
Live-service media ingestion is required to use secure, temporary HTTPS transit, with automatic purging no later than 30 days after ingestion. Successful publishing should trigger earlier cleanup when retries no longer need the original. Original-byte transit does not imply normalization is lossless; any encoding or aspect-ratio change creates a separately reviewed copy. PulseFlow does not add a promotional watermark.
The future 30-day rule must be enforced by storage lifecycle configuration and a monitored deletion process, not a promise in frontend code. Verified live connection or account deletion must erase encrypted tokens and cached profile data within 48 hours, cancel pending jobs, invalidate signed URLs, and prevent backup restoration from reactivating revoked credentials. Retention-locked legal records must be minimized, separated, and disclosed; they must not retain usable OAuth credentials.
The current demo does not upload local media. Temporary local playback references can disappear on reload, but saved captions, planning metadata, settings, and channel state persist until reset, deletion, logout, or session expiry. The 24-hour lifecycle is separate from future live-media retention. Application deletion removes active records, not forensic copies of disk sectors or operator backups; storage and restoration policies must enforce the privacy commitments. Contact requests follow separate operator-managed retention in the privacy policy; neither contact files nor the demo database are encrypted by an OAuth vault.
Vulnerability disclosure
Report a suspected vulnerability privately to [email protected], with “Security disclosure” in the subject. For personal-data exposure, contact [email protected]. Include the affected URL, reproducible steps, the smallest necessary proof, and a safe reply address. Do not include real tokens, passwords, or unrelated personal data.
We target an initial response within 24 hours on business days. Please avoid denial-of-service tests, credential harvesting, destructive actions, access to another person’s data, or testing a social platform without that platform’s authorization. Stop testing and report immediately if you encounter private information. We will coordinate remediation and disclosure timing in good faith. There is no paid bug-bounty program or guaranteed financial reward currently offered.
Before connected-service launch, the operator must validate key custody, tenant isolation, deletion evidence, consent enforcement, restoration behavior, monitoring, and each platform’s app-review requirements. This whitepaper is part of that review, not a substitute for it.