Security & Trust

Gravity is built by XAI Technologies Pvt Ltd in Bangalore, India. This page describes the security controls that apply to the Gravity platform, the production environment, and customer data. It supports our Data Processing Addendum and our Privacy Policy.

01Our security stance

1.1. Gravity executes AI agents that take real actions on real services. Security is not an add-on; it is the precondition for the product. Our security program is designed around three commitments:

• Least authority. Agents act with the minimum scopes the User explicitly grants. Internal systems follow the same rule.
• Defense in depth. No single control is trusted to be perfect. Encryption, segmentation, monitoring, and human review combine.
• Accountability. Every action that touches customer data is logged, attributable, and reviewable.

02Security program

2.1. The security program is owned by the security and engineering leadership team until a dedicated CISO is appointed, with formal hand-off documented as the team grows. Day-to-day responsibilities include risk assessment, vendor review, incident response, and policy upkeep.

2.2. We maintain an internal information security policy aligned with ISO/IEC 27001 Annex A control objectives, supplemented by the AICPA Trust Services Criteria (Security, Availability, Confidentiality).

2.3. All personnel with production access complete security awareness training before access is granted and at least annually thereafter.

03Data protection

04Access control

• Identity. Internal access is mediated through SSO with mandatory multi-factor authentication (hardware-backed WebAuthn for production engineers).
• Least privilege. Production access is granted by role and approved by the security owner. Standing access is minimized; just-in-time elevation is preferred.
• Audit. Access changes and production console actions are logged and reviewed.
• Joiner-mover-leaver. Access is provisioned at hiring, reviewed on role change, and revoked within 24 hours of departure.
• End-user accounts. Users authenticate via OAuth (Google) or email + password with strong password rules; account-level MFA is on the roadmap for general availability.

05Infrastructure

5.1. The marketing site (gravity.fast) runs on Cloudflare Workers and Pages with Cloudflare's WAF, DDoS protection, and Bot Management enabled.

5.2. Product workloads will run on AWS (ap-south-1, Mumbai, primary; us-east-1 secondary) and Supabase (Mumbai). Refer to /sub-processors for the current list.

5.3. Networking: VPCs are segmented per environment (dev / staging / production); security groups apply least-privilege ingress; outbound traffic is restricted to allow-listed destinations where feasible.

5.4. Patching: managed services receive vendor-supplied patches automatically. Self-managed components are patched on a published cadence with critical CVEs addressed within seven days.

06Secure development

• Source control on GitHub with branch protection and required code review before merge.
• Static analysis and dependency scanning on every pull request.
• Continuous integration enforces lints, tests, and security checks. Production deploys go through automated pipelines; manual production console changes are exceptional and logged.
• Threat modeling is performed for new features that touch authentication, authorization, payments, or external integrations.
• Pre-launch web application penetration testing is planned with an independent firm.

07Agent execution isolation

7.1. Each Agent execution runs with a per-execution context that includes (a) the User's prompt and uploaded content, (b) the OAuth scopes the User has granted to connected services, and (c) the Agent's authored prompts.

7.2. Agents do not run inside the same security context as the platform control plane. Builder-authored prompts cannot escalate beyond the scopes the User granted.

7.3. Inputs and outputs are filtered against safety policies described in the Acceptable Use Policy. Egregious matches are blocked at runtime.

7.4. Prompt-injection mitigations include input sanitization, scope-checking before any external action, and user confirmation prompts for high-impact actions (e.g., sending email, posting public content, transferring funds).

7.5. Builders cannot access raw User Content; performance and quality signals are aggregated and anonymized.

08Vendor security

8.1. Every sub-processor is reviewed against a security baseline before activation. The current sub-processor list is published at /sub-processors.

8.2. Where available, we prefer providers with SOC 2 Type II, ISO 27001, or equivalent third-party assurance. Provider-specific reports are reviewed and on file with the security owner.

8.3. AI model providers are configured to use endpoints that exclude customer data from training, where the provider offers that option.

09Monitoring & incident response

9.1. Production telemetry feeds a central log store. Alerting covers authentication anomalies, unusual data egress, error spikes, and known abuse signatures.

9.2. An incident response plan defines roles, severity levels, communication channels, and time-bound milestones (detection, containment, eradication, recovery, lessons learned).

9.3. If a Personal Data Breach affects Customer Personal Data, Gravity notifies affected Customers without undue delay and within seventy-two (72) hours of becoming aware, per the DPA § 10.

9.4. Major outages are reported on the public status page (status.gravity.fast, available at general availability) and via email to affected accounts.

10Compliance & certifications

11Reporting a vulnerability

If you have discovered a vulnerability in the Platform or in any Gravity-controlled property, please report it through our Responsible Disclosure program. We commit to acknowledging valid reports within 72 hours and to working in good faith with researchers who follow the disclosure process.

12Contact