Built for teams that vet a safety product first
FortifyRoot is a safety and observability platform, so security is the product. Here's how your telemetry is handled.
SDK-side detection & masking
Safety detection runs in your own runtime and can mask PII, PCI, PHI, secrets, API keys, and prompt-injection before content reaches the model: ALLOW or MASK, no proxy in the path.
You control content capture
Prompt and completion content capture is configurable per the SDK (FORTIFYROOT_TRACE_CONTENT). Disable it entirely, or mask sensitive fields, depending on your environment.
Network isolation
Services run in a private VPC with private subnets; TLS terminates at the load balancer. Admin APIs are not exposed to the public internet. Hosted ingestion needs only outbound HTTPS to api.fortifyroot.com, no inbound ports.
Encryption
TLS 1.3 for external traffic; encryption at rest for databases and object storage; secrets held in a managed secrets store. End-to-end prompt/completion encryption is on the roadmap.
Authentication
JWT-based auth (via Clerk) for the app and CLI; SDK API keys are stored as hashes only and can be rotated or revoked at any time.
Authorization & tenant isolation
A 4-role RBAC model (Member < Ingestor < Admin < Owner) governs every operation, and tenant isolation is enforced on all queries.
Data handling & residency
- FortifyRoot's MVP cloud deployment is operated in a US single-region environment.
- Data-access retention is tier-enforced; physical purge, backups, queues, logs, and operational stores follow platform-level retention schedules.
- FortifyRoot receives telemetry only from applications you instrument and configure.
Compliance posture
SOC 2 and HIPAA readiness are in progress. FortifyRoot does not claim current certification. For data-processing agreements or a current subprocessor list, contact us.
Responsible disclosure
Found a vulnerability? Please report it through our contact page so we can investigate and respond. See also our Privacy Policy and Terms of Service.