Data & Security Overview

BuildLoop coordinates bounded task execution with human approval for sensitive or irreversible actions. Security controls combine product policy, infrastructure configuration, and operational practices.

This page does not claim SOC 2, ISO 27001, PCI, GDPR, UU PDP, or penetration-test certification unless separately documented with evidence.

Actions such as commit, push, merge, and deploy require explicit human approval before BuildLoop continues. Sensitive goals may be blocked at preflight rather than executed automatically.

Approval records are part of the product audit trail.

Tasks run against locked contracts with defined scope, acceptance criteria, protected paths, and a maximum correction attempt limit. An independent checker evaluates results; the worker does not decide its own PASS outcome.

When evidence is insufficient, BuildLoop should surface FAILED, BLOCKED, or human-review states rather than silent success.

Workspaces are tied to connected repository identity. Application data is scoped by authenticated user and project identifiers. Supabase row-level security policies restrict specification, project, and task access to the owning user where enabled.

Orchestrator runtime and evidence may be stored separately (for example Firestore in production) from relational product data in Supabase.

Production deployments may use Google Cloud Run, Cloud IAM, Secret Manager, Firestore, and Supabase. Server-side secrets such as Supabase service role keys and Gemini API keys are intended to remain on the server — not in client bundles or UI.

GitHub access in the current release focuses on public repository URLs and clone operations within task execution boundaries.

Operational logs should prefer safe metadata (error codes, phases, identifiers) rather than full task bodies, specification content, authorization headers, or secrets.

If you believe logs expose sensitive data, report it through the contact channel below.

BuildLoop is designed around least privilege, human-in-the-loop control for irreversible actions, separation of execution and verification, traceability through contracts and evidence, bounded autonomy, secure-by-default UI behavior, explicit protected paths, provenance via Sources Used, and minimum necessary context for planning.

These are engineering goals — not guarantees against all misuse or misconfiguration.

BuildLoop applies reasonable default HTTP security headers where supported by the application server (such as `X-Content-Type-Options`, `Referrer-Policy`, frame protection, and a conservative `Permissions-Policy`).

A strict Content-Security-Policy is not enforced in a way that would break Supabase auth, Vite assets, or required runtime behavior without testing.

This hackathon/demo release supports public GitHub repositories, not private OAuth repository access. Self-service full account erasure may require operator assistance.

Security maturity, retention automation, and formal third-party review remain ongoing work.

Suspected vulnerabilities or security issues for this release can be reported through the public GitHub repository issue tracker: https://github.com/akbartantu/buildloop-hackathon-2026. Please avoid posting secrets or live credentials in public issues.

A dedicated security contact address may be published before wider production use.