Security, data, and access controls for enterprise GEO.
CiteSurge limits private project access by organization, workspace, project, permissions, plan, and enabled features. Public pages cannot reveal client records or change client data.
What should enterprise teams know first?
- Only authorized project members can access supported private project data.
- Dashboard, report, API, MCP, and webhook access follows project permissions and feature availability.
- Unavailable evidence stays unavailable; CiteSurge does not fill a gap with a guessed result.
- Privacy documents and agreed contracts define the commitments that apply to an engagement.
Who can see client data, and what happens when data is missing?
CiteSurge scopes client access through organization, workspace, and project membership. Dashboard, report, API, MCP, and integration access remains subject to the user's project permissions and the features enabled for that project. Public editorial routes do not grant access to private project records or mutating operations.
Client-facing dashboards and reports present supported findings, evidence, actions, and neutral unavailable states. Internal methodology artifacts, staff commentary, raw operational detail, secret values, and material from unrelated customer projects are not client-facing deliverables. A user's ability to view one project does not imply access to another project, an administrative surface, or a provider credential.
Access permission and available evidence are different. A user may be allowed to view a project even when an AI system returns no reliable result. CiteSurge does not replace a missing result with a guess. Client-facing copy states what CiteSurge found and what remains unknown without exposing developer-level provider diagnostics. Public research follows the separate editorial and research standards.
What are the API, MCP, webhook, and data boundaries?
Eligible paid projects can access supported CiteSurge data through the REST API and MCP. Signed audit-completion webhooks are pre-release, developer-gated, completion-only, and not self-service. These surfaces remain subject to plan, project permissions, feature availability, and the documented operation. Public API documentation does not make a private endpoint, project, credential, or mutation crawlable or anonymous.
API and MCP access provides an authorized interface to supported project data. Each AI system retains its availability state. For the developer-gated webhook integration, signatures let a receiving system verify the sender. Client teams remain responsible for their downstream storage and processing. See the API documentation, MCP documentation, and integration help for current public behavior.
CiteSurge publishes the legal and privacy terms that govern the product. They should be read for the applicable commitments rather than replaced by a broad security claim on this page:
How are security and procurement questions handled?
Security, data-handling, and procurement questions are assessed against the proposed scope and current product evidence. Requirements not stated in the public documents are not implied controls or commercial commitments. CiteSurge documents an agreed requirement before relying on it in a procurement response or delivery plan.
Send these questions to support@citesurge.com. Include the relevant product surface, data type, integration, and required control so the response can address the actual scope. Do not send secrets, passwords, or unrelated personal data by email. General enterprise and program questions can use the public contact route.
Published evidence and agreed contractual terms define the controls, certifications, uptime commitments, and data-residency requirements that apply to an engagement. Requirements outside the public baseline are verified during procurement.