Controls around workspace access, rendering and publishing.
Review PB workspace access, publishing credentials and approval controls, public rendering boundaries, customer responsibilities and current limitations.
On this page
Overview
Implemented controls
Prerender Buddy connects workspace evidence, full article generation and supported reviewed publishing with public-page rendering. This page describes implemented access, credential, approval and rendering controls, together with the responsibilities that remain with each customer. How PB works explains the platform workflow.
This is a technical security overview, not a certification or independent security audit.
Implementation reviewed: October 6, 2026.
Current controls
What the service enforces today.
Account and service access
Account routes require Clerk authentication. Admin routes require a separate configured admin identity. Rendering-engine and cache operations require a server-side service token. Developer API and hosted MCP requests use account-scoped credentials or OAuth authorization, with workspace/site and action-scope checks. A client receives authorized response data; that does not grant unrestricted publishing or settings access.
API key handling
Prerender Buddy stores an API key prefix and cryptographic hash rather than the complete key. Keys can be revoked from the account, and rendering requests are limited to sites registered in the same workspace.
Public URL validation
Rendering accepts HTTP and HTTPS URLs only, rejects embedded credentials, blocks local and private network destinations, validates DNS results, and applies request guards inside the browser context.
Bounded rendering work
Fresh render concurrency, navigation time, upstream response size, rendered HTML size, cache entries and cache memory are bounded to reduce runaway work and oversized responses. The managed gateway periodically removes entries past their retention deadline, applies configured freshness and bounded stale-response rules, and avoids a duplicate local HTML cache on dedicated workers. This describes the managed implementation, not every separately operated open-source engine.
Publishing credentials and destination access
Stored publishing secrets use AES-256-GCM with a server-side encryption key. This includes configured CMS/GitHub credentials, deploy hooks and webhook signing secrets. Ordinary connector responses expose connection metadata and whether a secret exists, rather than the stored secret. Generated signing secrets or private feed keys can be returned to the authorized user during setup or rotation. Feed access keys are stored as hashes.
Disconnecting a connector clears its stored credential and feed-key hash and prevents subsequent sends through that disconnected connection. It does not retract copies already delivered to a CMS, repository, webhook or host. Revoke credentials at the destination as needed and protect any setup key shown to you.
Review, publication and schedules
Article generation creates a full draft for human review; generating or approving content does not itself send it to a destination. Delivery checks the account, article, site, connected destination and approval state. An editorial date alone does not publish. An explicitly approved publication schedule is bound to the reviewed article/destination snapshot; relevant changes require renewed review. Scoped Developer API writes have separate confirmation requirements.
Buddy explains evidence and next steps. Hosted MCP can prepare proposals and generate confirmed unapproved drafts, but does not approve or publish them; the published local MCP package has bounded reads and diagnostics. The platform's publishing controls are separate. See Developer API, workspace MCP and supported destinations.
Rendering boundary
Public pages only.
Prerender Buddy is designed for public, cacheable website content rather than authenticated or personalized application routes.
Excluded by default
Non-GET requests, static assets, APIs, account pages, login and signup, admin, dashboard, checkout, billing, settings, and profile routes bypass crawler rendering in maintained integrations.
Customer-specific routes
Customers must keep any additional private, authenticated, personalized, preview, or sensitive routes outside the render path and avoid placing secrets in public URLs.
Known limitations
What these controls do not prove.
-
Crawler detection uses user-agent text. It does not authenticate a crawler operator by IP range or reverse DNS.
-
No public claim is made here for a security certification, penetration test, data-residency region, or formal uptime commitment.
-
Application-level URL validation is not a substitute for infrastructure-level egress controls and ongoing dependency maintenance.
-
A rendered response can reproduce public page content. Do not configure pages that expose account data, credentials, or private customer information.
Report a security concern
Send the affected URL, observed behavior, and reproduction steps.
Do not include passwords, complete API keys, or unrelated personal data in the report.