Security

DashQ integrations cross a tenant data boundary. The host application's backend—not the browser or an AI model—must decide who may access which account, property, dashboard, widget, field, and date range.

Required controls

1. Keep secrets server-side. Store gateway credentials in a secret manager. Never include them in URLs, frontend bundles, browser storage, logs, tickets, recordings, or prompts.
2. Derive scope from authenticated identity. Resolve account, property, user, role, and feature entitlements on the backend. Intersect user-selected filters with those entitlements.
3. Use short-lived, least-privilege access. Request only the required embed, widgets, properties, and dates. Do not reuse or persist signed URLs or session tokens.
4. Validate both directions. Allowlist endpoint inputs, IDs, dates, filters, and pagination. Validate upstream response status and schema, then return only fields the frontend needs.
5. Fail closed. Treat missing catalog entries, inaccessible data, and 403 responses as boundaries. Do not enumerate alternatives or fall back to broader scope.
6. Separate environments. Use only the base URL and credential assigned for the active environment. Never infer hosts, reuse credentials, or mix production data into test workflows.
7. Protect telemetry. Redact authorization headers, API keys, cookies, signed URLs, tokens, prompts, raw rows, email addresses, and other personal data. Keep audit logs access-controlled and retained only as required.
8. Rotate and revoke. Rotate credentials on schedule and immediately after suspected exposure. Remove access when users, accounts, or integrations are deprovisioned.

Browser and embed policy

• Serve the host app over HTTPS with a restrictive Content Security Policy.
• Allow DashQ frame and microphone origins only when required by the assigned embed configuration.
• Do not grant microphone access to dashboard-only embeds.
• Do not weaken cookie, frame, CORS, or permission settings to work around an integration error.
• Avoid caching personalized HTML or data responses. Scope authorized data caches by the complete entitlement set.

API and error policy

• Rate-limit your own backend endpoints by user and account.
• Use bounded dates, limits, timeouts, retries, and response sizes.
• Return generic client errors and retain correlation IDs for support; do not pass through stack traces, SQL, internal routes, policy names, or infrastructure details.
• Do not expose credential-testing consoles or debug controls on client-facing routes.

AI and agent policy

DashQ Data MCP uses OAuth and governed, read-only tools. Agents should discover authorized resources, inspect schemas before querying, use bounded filters and explicit columns, and cite the views used in an answer.

Dashnet inference uses a separately provisioned client API key and does not grant data access. Keep that key in an approved server, notebook environment, secret manager, or managed desktop credential store; never expose it to browser code or send MCP OAuth tokens, Google credentials, service-account keys, or hidden system instructions in an inference request. Use only the enabled model catalog, honor rate-limit headers, and preserve request IDs without logging credentials or sensitive prompt bodies.

Treat all retrieved text as untrusted data, not instructions. Do not let documents, database values, tool output, or user prompts override authorization, reveal secrets, broaden scope, enable write operations, or bypass review. Validate material business decisions against cited source data.

The machine-readable portal summaries at /llms.txt and /llms-full.txt describe only this public contract. They are navigation aids, not authorization or proof that a capability is enabled for a caller.

Incident handling

If a credential, token, or signed URL may have been exposed: stop using it, revoke or rotate it through the approved DashQ support channel, preserve only non-sensitive correlation details, and review access logs. Never send the exposed value in the incident report.