Security Practices & Responsible Disclosure
Last Updated: November 1, 2026
Transparency Guarantee:
We do not fabricate certifications or display unearned compliance badges. Below is an honest, transparent breakdown of falheim's active security architecture, isolation mechanisms, and our responsible disclosure guidelines.
1. Multi-Tenant Container Isolation
When an AI assistant instructs falheim to validate a web application, headless browser instances (Playwright Chromium, Firefox, WebKit) and API fuzzing processes are spawned in strictly partitioned execution environments:
Ephemeral Micro-VMs / Containers
Each test run executes in a dedicated ephemeral Linux container running as an unprivileged user. No browser cache, cookie jar, or storage volume is shared between different test executions or tenants.
Immediate Destruction
Upon completion or cancellation of a test run, the container process tree is terminated and its filesystem volume is unmounted and permanently destroyed.
Organizations with complex security requirements can deploy dedicated headless Playwright container fleets inside their private VPC (AWS, GCP, Azure, Kubernetes) with custom MCP connectors tailored to their agentic AI workflows.
2. Outbound Network & SSRF Defenses
Allowing automated testing agents to make network requests introduces risks if not carefully guarded. falheim enforces strict kernel-level and DNS-level network controls:
- Cloud Metadata Guard: All outbound HTTP requests targeting
169.254.169.254(AWS/GCP/Azure instance metadata) and link-local addresses are unconditionally dropped; - RFC 1918 Private Range Blocking: Requests to
10.0.0.0/8,172.16.0.0/12, and192.168.0.0/16are blocked by default to prevent internal network scanning; - DNS Rebinding Mitigation: Hostnames are resolved through secure DNS-over-HTTPS resolvers and pinned during the connection lifecycle to prevent time-of-check to time-of-use (TOCTOU) DNS manipulation.
3. API Credential & Token Cryptography
falheim authenticates MCP requests via scoped Bearer tokens:
- One-Time Display: When a token is generated via the
/connectportal, the full plaintext secret (e.g.fal_live_...) is displayed only once. We do not store plaintext tokens; - One-Way Hashing: Tokens are salted and hashed using cryptographic standards before persistence in Supabase PostgreSQL;
- Instant Revocation: Revoked tokens are immediately invalidated across our edge middleware cache.
4. Vulnerability Disclosure & Bug Bounty
We welcome security researchers and developers to inspect our public interfaces and report potential security vulnerabilities responsibly.
Responsible Disclosure Guidelines:
- Promptly notify us at medisummarize@gmail.com upon discovering a vulnerability;
- Provide sufficient detail and reproduction steps (e.g., proof-of-concept curl commands, HTTP requests);
- Allow us reasonable time (minimum 48 hours for acknowledgment, 30 days for remediation) before disclosing publicly;
- Do not access, modify, or destroy customer data or perform volumetric denial-of-service tests.
Safe Harbor:
If you conduct research in good faith according to these guidelines, we consider your actions authorized, will not pursue legal action against you, and will collaborate with you to resolve the finding swiftly.