Security and trust

Security for AnswerLens starts with no hosted control plane.

AnswerLens is designed so that teams can audit public product sites and review results inside GitHub-native workflows without sending their repo history or provider keys to a separate AnswerLens SaaS. It keeps the guardrails explicit: no consumer AI UI scraping, no ranking guarantees, and no dashboard-first rewrite.

What stays under your control

Trust model

Provider API keys stay in your own shell, CI environment, or GitHub Actions secrets.
The core `audit` workflow can run without provider keys at all.
AnswerLens writes reviewable artifacts such as `share-summary.md`, `scorecard.md`, and `recommendations.md` into your own run directory.
Public sharing should use summary artifacts, while raw provider payloads stay private.

Operational detail

Review and deployment model

Concern	AnswerLens approach
Secrets	Provider keys stay in your own shell, CI environment, or Actions secrets.
Hosted control plane	No hosted AnswerLens SaaS is required for the CLI, the GitHub Action, or the static report flow.
Review trail	Use pull requests, Action logs, uploaded artifacts, and repo history as the audit trail.
Public sharing	Share `share-summary.md` or `pr-snippet.md` and keep raw payloads private.

Guardrails

Known limits

AnswerLens does not claim SOC 2, ISO 27001, HIPAA, or other compliance programs for a hosted service because it is not operating as a hosted AnswerLens SaaS today.
The project does not scrape consumer AI interfaces to fabricate visibility claims.
The product does not promise rankings or placement on answer surfaces.
Teams should still review artifacts before posting them to public issues, PRs, or release notes.

That keeps the trust story direct: use your own deployment path, your own secrets handling, and your own repository review process.

Built by YSCJRH from repo-native docs, releases, and artifacts. No consumer AI UI scraping. No ranking promises.