Security posture
This overview describes the technical baseline currently evidenced by FetchSet’s infrastructure configuration and application code. It is not a statement that every production integration or operational control is live.
This page is a structural draft. It is not a security attestation, a questionnaire response, an audited controls report, or a contractual commitment.
Infrastructure
The Google Cloud substrate for FetchSet has been provisioned in a US launch region. It includes Cloud Run services, private-IP Cloud SQL for PostgreSQL, and private-network Memorystore for Redis.
- Cloud Run accepts application traffic through the load-balancer path rather than a direct public service URL.
- Cloud SQL is configured without a public IPv4 address.
- The deployed Cloud Run services still use bootstrap images; production application deployment and live data-store smoke tests remain release steps.
Encryption and secrets
The provisioned baseline includes Google-managed TLS at the public load balancer, TLS for the Redis connection, Cloud KMS keys intended for application-level PII encryption and HMAC operations, and Secret Manager slots for application credentials.
- KMS access is granted to the API and MCP service identities on the specific keys they require.
- Secret Manager access is scoped per secret and service identity.
- Real secret population, application-level KMS integration, and production verification remain release steps.
Access control
The infrastructure configuration uses per-service identities and resource-scoped IAM grants. Cloud SQL runtime users are configured for IAM database authentication.
At the application layer, REST key verification stores hashes rather than plaintext keys. The MCP code implements OAuth 2.1 flows with PKCE; its production dashboard-session and consent integration remains pending.
Edge protection
A Google Cloud Armor policy is attached to the external load balancer. The policy includes adaptive Layer 7 DDoS protection, preconfigured WAF rules, and a coarse per-key throttle.
Precise plan limits are implemented separately in the application. Both layers require production deployment and live verification before they should be treated as an operational assurance.
Service integrity
The application code and tests enforce several product invariants:
- Charge-on-success: an empty result carries
tokens_charged: 0. - Suppression before PII: the resolution path checks suppression before returning personal data, including on cache hits.
- Provenance on every record: personal-data writes require
source,acquired_at, andredistribution_basis.
These are implementation facts, not an independent assessment of operating effectiveness.
Certifications and attestations
This draft makes no claim of SOC 2, ISO 27001, penetration-test, or independent-audit status. Any future attestation statement must be added only after the underlying evidence is complete and approved.
Current status and forward-looking timelines are [to be confirmed].
Report a concern
To report a suspected vulnerability or security concern, contact hello@fetchset.dev. A dedicated security-disclosure address and published policy are [to be confirmed].