Deployment boundary
This website is a product preview and contact-intake application. Its calendar runs in your browser; the social accounts, publish events, and audit history are demonstrative. No OAuth connection, social credential vault, LLM integration, or remote media ingestion is enabled here. The contact endpoint validates requests and writes consented inquiries to a private server-side inbox. It does not send an email or publish content.
Threats considered include stolen application sessions, cross-workspace authorization errors, exposed access tokens, untrusted media, prompt injection in agent instructions, malicious request replay, and administrator changes to execution records. A dark interface and an encryption algorithm alone do not mitigate these threats.
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 deployment design uses non-root, read-only Docker containers with dropped Linux capabilities, pinned image digests, limited CPU and memory, and writable mounts restricted to the particular service that owns them. The contact inbox requires its own persistent private volume; it must not share a public asset directory. A read-only container without this mount cannot accept inquiries and must return an error, not a success message.
Traefik is the intended edge router and TLS 1.3 termination point. Public deployment requires a valid certificate, HTTPS redirects, an appropriate HSTS policy after HTTPS has been verified, request-size limits, and server-level admission control. Internal services remain private. No Traefik or TLS deployment is bundled into this website build, and a local HTTP preview does not demonstrate transport encryption.
The site itself 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 this static-page configuration; the CSP therefore is not represented as a nonce-only policy. No third-party script, analytics beacon, or remote font is loaded. React text escaping is retained for user-entered content.
Contact intake 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 must add shared edge limits. Request-body errors and storage errors remain failures visible to the user.
Tamper-evident audit trail
The production 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 production 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. The browser demo’s activity view is a readable event history, not a cryptographically verified ledger.
Multi-account workspace boundaries
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 does not automatically permit reading decrypted credentials. Service identities receive only the methods and storage prefixes they need.
Changing a caption, media object, destination, privacy level, or commercial disclosure invalidates prior approval. A 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
Production 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 30-day rule must be enforced by storage lifecycle configuration and a monitored deletion process, not a promise in frontend code. Verified 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.
This preview does not upload or retain selected media. Local video object URLs are released when no longer needed, and draft state ends with the browser session. Contact requests follow the separate retention terms in the privacy policy; these records are not encrypted by an OAuth vault. Host-level disk protection is a deployment responsibility.
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.