Secret by default
Reveal a new token only when required, mask it afterward, and prevent it from entering public markup, telemetry, support screenshots, or caches.
Security and trust architecture
Give agents current evidence without giving up credential control.
SearchSignal’s connection model depends on a sensitive credential and authorized project data. The public presentation, authenticated application, MCP service, HTTP API, logs, analytics, and deployment layer must all treat that boundary seriously.
Trust model
One credential. Explicit scope. Revocable access.
The site should explain the controls accurately without inventing certifications, uptime commitments, encryption claims, or audit results that have not been independently verified.
Project-scoped requests
Resolve the account and project server-side for every call. Treat the client prompt as untrusted input, not an authorization decision.
Rotate and revoke
Give account owners a clear way to replace a credential, invalidate an exposed token, and review the resulting client state.
Freshness and limits
Return timestamps, coverage, partial-data states, and typed errors so the model does not silently fill operational gaps.
Production controls
Security belongs in the entire request path.
A polished token screen cannot compensate for an exposed browser bundle, permissive project API, verbose logs, or weak server-side authorization. The launch gate has to test each layer directly.
- Transport encryption and modern TLS configuration at the public edge
- Server-side authentication and authorization for app, API, token, project, and billing routes
- CSRF protection on state-changing browser actions
- Rate limits, abuse controls, dependency review, and structured security events
- Private or no-store caching for authenticated and secret-bearing responses
- Documented credential exposure, incident response, rollback, and notification procedures
Marketing, docs, and setup explanation only.
Server-rendered states, CSRF protection, no-store.
Resolve scope, limits, freshness, and audit events.
Task-shaped response with stable references.
Authorization gate
Private routes must reject unauthenticated requests.
Interface visibility is not an access control. Every protected browser route, token action, project object, billing operation, MCP call, and API request must enforce identity and workspace scope on the server.
| Surface | Expected access | Release check |
|---|---|---|
| Public marketing and docs | Readable without an account; no customer or secret-bearing state. | Inspect source, caches, analytics, and social previews for private data. |
| Application and token controls | Authenticated account owner or explicitly permitted team member. | Direct requests without a session return a denial, not a hidden page. |
| MCP and HTTP API | Valid, active credential with an authorized project scope. | Invalid, revoked, expired, and cross-project requests fail predictably. |
| State-changing actions | Authorized identity plus appropriate anti-forgery and rate controls. | Rotation, revocation, billing, and project changes generate auditable events. |
Release requirement: Verify these controls against the production origin before publishing a security page or making security, availability, or compliance claims.
Frequently asked questions
Trust answers without unsupported promises.
This presentation does not claim SOC 2, ISO 27001, penetration-test, or other certification status. Publish only independently verified certifications and current reports.
Use the approved secret store for the client or a server-side secret manager. Never place a real token in public HTML, browser bundles, screenshots, analytics, logs, or source control.
The production application should show the new value once, invalidate the prior credential according to policy, refresh generated client configurations, and preserve an audit record of the event.
No. Keep the public explanation indexable, but render token status, secret values, rotation, revocation, projects, usage, and billing only after authentication and authorization.
The production authorization model should resolve the permitted workspace for each request and reject cross-project or cross-account access. Do not rely on the model prompt as an access control.
Connect once. Ask anywhere.
Connect the agent. Protect the boundary.
Use the production integration guide, deployment templates, and release checklist included in this package before making the redesign public.