Security

Security for support inside your product.

AnswerLattice uses safe page hints, explicit screenshot attachments, bounded source intake, allowed origins, blocked routes, compiled approved context, role-scoped workspaces, and owner-approved answers so support can be helpful without collecting secrets.

Open one-pager View install safety

Widget

Allowed origins, blocked routes, safe context

Sources

Owner-selected intake, capped media extraction

Authority

Owner-approved answers before official guidance

What to remember

Install the widget only on allowed domains and hide it from sensitive routes. Send safe page context instead of secrets. Keep screenshots user-initiated, use selected sources for Knowledge Intake, and approve support answers before they become official.

Open security one-pager

Security at a glance

AnswerLattice is built around product-owned workspace boundaries, widget runtime controls, and reviewed support-knowledge access.

Product app

Allowed origin

Widget config loads only from approved product and staging domains.

Safe page context

Route, feature, workflow, role, and plan hints guide support without secrets.

Blocked routes

Auth, payment, admin, or sensitive pages can hide the launcher.

Protected surfaces

Workspace scope

Support knowledge stays tied to the correct AnswerLattice workspace.

Hosted help boundary

Public docs, FAQ, changelog, robots, and sitemap render without account data.

Owner-approved authority

Drafts and proposals require review before becoming official answers.

Compiled context

Runtime bundles expose approved context, not raw tickets, drafts, audit logs, or API keys.

Product data boundary

AnswerLattice workspace scope

Team permissions

AnswerLattice role claims

Owner reset path

Passcode reset + sign-out

Runtime database

AnswerLattice Firebase project

Widget key storage

Hashed; encrypted recovery when configured

Widget placement

Allowed origins + blocked routes

Screenshot input

Manual attachment only

Source intake

Owner-selected and capped

Hosted help

Registry-scoped domains

Ticket context

Capped and sanitized

Answer authority

Owner-reviewed approved answers

Runtime context

Versioned approved bundles

Expensive requests

Rate-limited endpoints

Scheduler output

Local EOD + compact summaries

Product boundary

AnswerLattice workspace scope

scope

Account-scoped data

AnswerLattice documents use product, account, and workspace scope so support knowledge, tickets, widget settings, and summaries stay tied to the correct workspace.

context

Role-scoped workspace access

AnswerLattice workspace members receive AnswerLattice-specific permission claims so team, billing, widget, knowledge, support, and answer-review controls can be separated by role.

image

Owner reset and sign-out

Workspace owners can create a new temporary passcode and force sign-out for managed team members when access needs to be refreshed.

route

Safe widget context

Widget context is designed for page, route, feature, workflow, role, and plan hints. It is bounded and should not include secrets, tokens, passwords, payment card data, or unrelated personal information.

public help

Explicit screenshot attachments

Users can attach or paste screenshots when visual context helps. AnswerLattice does not automatically capture the host page, scrape the DOM, or write widget images to persistent storage.

ticket

Bounded source intake

Knowledge Intake accepts selected public links, supported files, screenshots, and short recordings as owner-provided evidence. URL import is bounded, media work is capped and credit logged, and raw media is not retained by default.

review

Origin and route controls

Workspace owners can configure allowed origins and blocked routes so the widget appears only where the product owner wants it.

compiled

Hosted help domain registry

Hosted help domains resolve through AnswerLattice-owned registry documents so anonymous docs, FAQ, changelog, robots, and sitemap pages never depend on client-supplied tenant IDs.

logging

Ticket debugging context

Tickets can include a capped, sanitized snapshot of recent browser context at creation time so owners can debug broken screens without asking customers for technical details.

separate product

Owner-approved authority

Generated drafts, entity candidates, and mutation proposals require human review before they become active approved answers.

control

Compiled context boundary

Ready runtime bundles contain approved public-safe context for the widget and server-only private context for authenticated paths. Drafts, tickets, audit logs, API keys, and raw signals stay out.

control

Bounded logging

Operational logs are meant for reliability, failure analysis, and abuse protection. Production flows should avoid storing raw sensitive payloads.

control

Separate product infrastructure

AnswerLattice uses AnswerLattice-owned dashboard routes, constants, schedulers, widget configuration, and workspace data boundaries.

Source intake boundary

Import selected evidence, not everything.

Use public product or docs pages you select, supported files, screenshots, and short recordings that are safe to process. AnswerLattice does not crawl an entire private app, retain raw media by default, or make generated intake output official without owner review.

Page context boundary

Do not send secrets through page context.

Use page, route, feature, workflow, role, plan, or state names. Do not send passwords, tokens, payment data, private customer records, or unrelated personal data. If users attach a screenshot, keep it deliberate and avoid pages that show secrets.

Safe context

Send page hints, not private data.

Allowed page context can guide support while secrets, payment data, and private records stay outside the widget packet.

Allowed hints

Route, workflow, role, plan, and product area can guide support.

Safe packet

AnswerLattice uses bounded context for answer relevance.

Blocked data

Tokens, card data, passwords, and private records stay out.

Trust controls

What AnswerLattice protects by design

These controls map to the implemented AnswerLattice runtime: dashboard APIs, widget config, widget search, feedback, tenant-scoped rules, summaries, and owner review queues.

Workspace isolation

AnswerLattice management routes resolve an AnswerLattice product account and workspace before reading or writing workspace data.

AnswerLattice documents use product, account, and workspace scope.
Dashboard APIs check AnswerLattice scope before mutations.
AnswerLattice Firebase rules default to deny and allow tenant-scoped access explicitly.

Team permissions

AnswerLattice team access uses product-specific roles for support, knowledge, widget, billing, answer review, and workspace controls.

Owner, Manager, Support Staff, and custom roles map to AnswerLattice permission keys.
Dashboard routes and protected AnswerLattice APIs check the active role before exposing controls.
Password/passcode reset and force sign-out revoke active sessions for sensitive access changes.

Widget runtime control

The widget is designed to be installed on selected product pages, not sprayed across every route by default.

Widget keys are stored as hashes after creation.
Allowed origins restrict where runtime config can be used.
Blocked routes let owners hide the launcher on sensitive screens.
Malformed al_* keys are rejected before expensive lookup work.

Hosted public help

AnswerLattice can publish reviewed support content on support domains without exposing authenticated support operations.

Domain registry docs resolve workspace scope server-side.
Anonymous pages render published docs, FAQ, changelog, robots, and sitemap only.
Tickets, chat history, feedback writes, and account data stay out of hosted help.

Ticket debugging context

AnswerLattice keeps ticket debugging context useful by tying it to the reported issue instead of broad background collection.

Recent browser context is captured only when a ticket is created.
The payload is capped and intended for debugging the reported issue.
Support teams see context in the ticket instead of asking users to describe browser-level details.

Bounded page context

AnswerLattice treats page context as a hint for support relevance, not as trusted identity or tenant authority.

Context should describe page, route, feature, workflow, role, or plan.
Secrets, tokens, passwords, payment card data, and unrelated personal data should not be sent.
Server-side validation keeps tenant scope separate from client-provided context.

Explicit visual context

Screenshots can help explain a broken screen, but they should remain a deliberate user action instead of background collection.

Users upload or paste screenshots only when they want to include visual context.
The widget does not automatically capture the host app screen or scrape the DOM.
Image inputs are bounded by type and size, and widget images are not stored as persistent files.

Knowledge intake boundary

Intake is designed to teach AnswerLattice from selected sources without creating a crawler, private connector, or automatic publishing path.

Public URL discovery imports only owner-selected pages.
Files are capped before processing; screenshots and short recordings are extracted into support text.
Paid OCR and transcription work is support-credit logged and refund-aware on failure.
Accepted output publishes through existing KB, FAQ, surface, changelog, or approved-answer proposal workflows.

Reviewed answers

Support correctness comes from approved knowledge, not automatic rewriting.

Approved answers are served before fallback.
Drafts and mutation proposals remain review work until approved.
Stale-answer and signal checks surface stale or missing knowledge.

Cost and abuse controls

AnswerLattice keeps high-cost and public runtime paths bounded so one noisy widget cannot become an uncontrolled backend workload.

Public widget config, search, and feedback endpoints are rate limited.
Repeated approved-answer hits can use cache with freshness checks.
Ready widget context can be served through versioned bundles and server cache instead of raw collection fanout.
Dashboards prefer summary documents over broad collection scans.
Hosted help content uses cached public payloads and compact display fields.

Compiled context separation

AnswerLattice separates reviewed source data from runtime context so public and authenticated consumers receive only the approved fields they need.

Source records remain inside AnswerLattice for drafts, tickets, signals, proposals, and audit state.
Public widget bundles include only public-safe product and support context.
Private server bundles stay behind authenticated AnswerLattice APIs.
A stale or failed build does not replace the last ready bundle.

Scheduler cost boundary

Daily support review work is centralized and workspace-aware rather than split into many scheduled functions.

The scheduler evaluates due workspaces by local timezone and support-day end time.
Source-version checks decide whether compiled context needs repair.
Summary documents keep owner dashboards readable without large scans.

Operational separation

AnswerLattice keeps its product data and support runtime bounded to AnswerLattice workspace, widget, hosted help, and answer review surfaces.

AnswerLattice has product-owned routes, constants, schedulers, and dashboard sections.
AnswerLattice Firebase config can run as dedicated product infrastructure.
Client products are integrations, not hardcoded AnswerLattice dependencies.

Security and responsible disclosure

Report security, privacy, or data-handling concerns to the AnswerLattice team. Do not include secrets, production credentials, or full customer data in the first message.

hello@answerlattice.com