LEGAL

Security

Last updated — 6 August 2026 · v1.4

This page describes how Triophase Global Services Pvt. Ltd. protects the systems, code and data entrusted to us. It is referenced by our Terms of Service and incorporated into Annex II of our Data Processing Addendum, which makes it contractually binding.

1. Our position, stated plainly

We are an AI-native software studio operating from Kolkata, India. We build client software using autonomous agents supervised by senior engineers, and that architecture shapes our security model: isolation per project, encryption everywhere, least privilege by default, and human accountability for everything an agent produces.

We do not currently hold SOC 2, ISO 27001 or equivalent third-party certification. We say so rather than implying otherwise, because a buyer will find out during due diligence and finding out then is worse. Our controls are modelled on those frameworks, we will complete a security questionnaire in detail, and we will support a customer's own assessment.

2. Environment isolation

Per-project build environments. Each active build runs in a dedicated, ephemeral virtualised environment provisioned for that project alone and destroyed when the work completes. Build environments are not shared between customers.

Per-project staging. Each project has its own staging server for client preview. Staging environments are separate from build environments and from every other customer's staging environment.

Separation of duties. Build infrastructure, source control and the client-facing Studio portal are distinct systems with distinct access controls. Compromise of one does not confer access to the others.

Decommissioning. Build and staging environments are destroyed within 30 days of project completion or termination, and the underlying storage is released.

Systems we run ourselves. Source control and continuous integration run on a self-managed GitLab instance, and error tracking and application monitoring are self-hosted. Your source code is never held by a third-party code hosting service, and your application's stack traces — which routinely contain end-user personal data — are never sent to a third-party monitoring service. The Studio portal, our automation platform and our secrets store are likewise operated by us.

3. Access control

Least privilege. Access is granted by role, limited to what a role requires, and reviewed at least quarterly.
Multi-factor authentication is mandatory on all administrative systems, source control, cloud consoles and the Studio.
No shared accounts. Every action is attributable to a named individual.
Just-in-time access to customer environments, granted for a defined purpose and revoked on completion.
Offboarding. Access is revoked within one business day of a role change or departure, against a documented checklist.
Customer credentials. We ask for the minimum access necessary. Where a customer must issue us credentials, we ask for a dedicated account rather than a shared one, so it can be audited and revoked independently. We ask customers to rotate any credential shared with us at project close, and we will remind you to do it.

4. Encryption and secrets

In transit: TLS 1.2 or above for all connections. HSTS enforced on our web properties.
At rest: AES-256 or equivalent for storage volumes and backups.
Object storage: encrypted at rest, with additional application-layer encryption applied before upload for sensitive artefacts.
Secrets: held in an encrypted secrets store with access logged. Credentials are never committed to source control, never stored in plain text in configuration, and never sent over email or chat. Automated scanning rejects commits containing detected secrets.
Key management: encryption keys are stored separately from the data they protect, with access restricted to a small number of named individuals.

5. Secure development

Test-driven development is our standard practice. Tests are written against the accepted specification, and the continuous integration pipeline is the authoritative signal that a milestone is complete.
Human review of AI output. No AI-generated code reaches a customer environment without review and acceptance by an engineer. Accountability sits with us, not with a tool.
Static analysis and dependency vulnerability scanning run in the pipeline. Builds fail on findings above the defined severity threshold.
Peer review on merge to protected branches.
Secure defaults for authentication, session handling, input validation, output encoding, access control and error handling, tracked against the OWASP Top 10 as a baseline for web deliverables.
Synthetic data by default in non-production environments. We ask customers not to place production personal data into development or staging environments, and we will say so again if you offer it.

6. Logging and monitoring

Authentication events, administrative actions, privileged access and infrastructure changes are logged. Logs are retained for 12 months, stored separately from the systems that generate them, and protected against unauthorised alteration. We monitor for anomalous authentication patterns and unexpected infrastructure changes.

7. Backups and resilience

Encrypted backups on a rolling cycle of up to 90 days.
Restore procedures tested periodically.
Documented business continuity and disaster recovery arrangements, reviewed annually.
Customer responsibility. Once an environment has passed to your control, backup of that environment is your responsibility. Where your Order provides for us to host and operate the application, backup remains ours for as long as that arrangement continues.

8. Incident response

We maintain a documented incident response plan with defined severity levels, escalation paths, containment steps and communication responsibilities.

Our commitments if an incident affects you:


Initial notification	Without undue delay, and within 48 hours of becoming aware of a personal data breach affecting your data
Content of notification	Nature of the incident, data and individuals affected so far as known, likely consequences, steps taken, and a named contact
Ongoing updates	Until the incident is closed
Post-incident report	On request, within 30 days of closure
Regulatory reporting	We comply with our own reporting obligations, including to CERT-In where applicable, and will tell you when we have done so

Notification is not an admission of fault or liability. Where you are the controller, notifying supervisory authorities and affected individuals is your responsibility, and we will support it.

9. Personnel

Written confidentiality obligations for every employee and contractor, surviving the end of their engagement.
Security and data protection awareness training on onboarding and at least annually.
Background verification carried out on all employees and contractors before engagement, to the extent permitted by applicable law, with records retained.
Devices used for client work are required to have full-disk encryption, screen lock, automatic updates and endpoint protection enabled.

10. AI-specific controls

Because our delivery method is unusual, these deserve their own section.

No training on customer data. Customer code, data and content are not used to train, fine-tune or evaluate any model. We contract with model vendors on terms that prohibit it and, where offered, enable zero-retention processing.
Model providers are sub-processors and are disclosed at /sub-processor.
Minimised context. Agents receive the context needed for the task. Credentials and secrets are injected at runtime from the secrets store and are excluded from prompts and logs wherever technically possible.
Bounded execution. Agents operate inside the isolated project environment with scoped permissions. They do not hold standing credentials to customer production systems.
Output review. Every agent-produced change passes automated tests, static analysis and human review before acceptance.
Direct vendor calls. We call model providers directly under commercial API terms rather than routing through an intermediary, so the set of parties receiving your content is short and disclosed. Providers may retain content briefly for abuse monitoring under their own terms; they do not train on it.
Regional pinning. We operate across several infrastructure providers, which allows build compute and storage to be restricted to a region you nominate, with an infrastructure attestation produced as a build deliverable. Available on request and assessed case by case; not applied by default. Model inference is subject to the regional availability of the vendors listed at /sub-processor.

11. Sub-processors and vendors

We assess a vendor's security posture and data protection terms before engagement, and bind each one in writing to obligations no less protective than those we owe you. The current list is published at /sub-processor, with at least 30 days' notice before a new sub-processor begins processing customer personal data.

12. Physical security

Our studio premises are access-controlled. All production and build infrastructure is hosted with third-party providers in facilities with their own physical access controls, environmental protection and 24/7 monitoring. We do not operate our own data centre.

13. What we ask of you

Security is shared. We ask customers to:

Issue us dedicated, scoped credentials rather than shared ones, and rotate them when the project closes
Avoid placing production personal data in development or staging environments
Keep your own Studio credentials confidential and enable multi-factor authentication
Tell us promptly at security@triophase.com if you suspect a credential has been exposed
Apply the updates and patches we recommend after handover, and maintain the software once it is yours

14. Responsible disclosure

If you believe you have found a security vulnerability in a Triophase system, tell us at security@triophase.com. Include enough detail to reproduce it.

Our undertaking: we will acknowledge within 3 business days, keep you updated, work to remediate promptly, and credit you publicly if you would like us to.

What we ask: report privately and give us reasonable time to fix the issue before disclosing; do not access, modify or delete data belonging to others; do not degrade our services or those of our customers; do not run automated scanning at volume against production systems; and stay within the law.

We do not currently operate a paid bug bounty. We will not pursue legal action against a researcher who acts in good faith within these guidelines.

15. Security questionnaires and due diligence

We will complete a reasonable security questionnaire, provide our policies in summary form, and support a customer's assessment as described in section 8 of the DPA. Contact security@triophase.com to start.

16. Contact

Triophase Global Services Pvt. Ltd.
ASO-411, 4th Floor, South Block, Astra Tower.
Newtown, Kolkata – 700135, West Bengal, India.
security@triophase.com