Security and Responsible Disclosure

Last updated: September 21, 2026

This page describes high-level security practices for www.scitechsolutions.io, operated by S&T Integrated Solutions LLC, doing business as Science & Technology Integrated Solutions. It also explains how to contact us about security issues and authorized safety testing.

1. Security Contact

Report security issues or request authorization for safety testing at security@scitechsolutions.ai.

Do not publicly disclose a vulnerability or safety issue until we have had a reasonable opportunity to investigate and remediate it.

2. SOC 2 Status

Our SOC 2 program is in progress. Unless expressly stated in writing, we do not claim current SOC 2 certification or completion of a SOC 2 audit.

3. Security Measures

These are the measures actually in place, rather than a list of things a program of this kind might include:

  • traffic encrypted in transit using modern TLS, terminated at Cloudflare in front of the services;
  • passwords stored only as Argon2 hashes. We cannot read your password and cannot recover it — only reset it;
  • API keys stored as a short public prefix plus an Argon2 hash. The full key is shown once at creation and is not recoverable afterwards, which is why it must be treated as a password;
  • two-factor authentication, with recovery codes stored hashed and therefore displayed to you exactly once;
  • per-tenant webhook secrets encrypted at rest with AES-256-GCM;
  • BYOK provider keys encrypted at rest with AES-256-GCM, never stored in plaintext; their encryption key is held only in the environment, never in the database or repository;
  • application credentials held in Google Secret Manager, not in files on the server;
  • access controls, role-based access, MFA, and least privilege. Access to production is restricted to SciTech personnel who need it;
  • logging, monitoring, alerting, and operational review;
  • vulnerability management and security review processes;
  • rate limiting, abuse detection, bot protection, and DDoS mitigation at the edge;
  • backups retained for 30 days across two United States regions;
  • incident response procedures, personnel confidentiality obligations, and vendor review.

Hosting is Google Cloud in the United States (us-south1), with backups across us-south1 and us-east1. The current list of subprocessors is published in Schedule 3 of the Data Processing Agreement.

Security measures may vary by product, deployment model, customer agreement, and environment.

4. Customer Responsibilities

Customers are responsible for securing their accounts, API keys, provider keys, BYOK configuration, credentials, networks, applications, prompts, data, integrations, tool permissions, agents, and users.

In BYOK mode:

  • Customer provides provider API keys.
  • Customer has the direct provider relationship.
  • Customer controls provider account settings.
  • SciTech routes requests using customer-configured keys.
  • Storing a provider key is Customer's consent for Meter-SPW to route requests through that provider when it is cheaper; Customer can switch cross-vendor routing off under Settings → Cross-vendor routing.
  • Provider keys are encrypted at rest with AES-256-GCM and are never stored in plaintext. Their encryption key is held only in the environment, never in the database or repository.

Customer is responsible for provider-side settings, provider retention and training configuration, provider billing, provider permissions, provider restrictions, and provider security.

5. Data Handling, Caching, and Audit Retention

We do not use customer-provided data to train AI models. We run no session-replay, advertising, or cross-site behavioural-tracking technology. Meter-SPW uses Cloudflare's lightweight edge analytics to report aggregate page-load timing without using cookies to track users between sites.

For operational performance, routing, reliability, response retrieval, troubleshooting, abuse prevention, and security, Meter-SPW retains a per-call audit record containing a SHA-256 hash of your prompt — never the prompt text itself on the ordinary call path — and routing and billing metadata. It caches model answers for 24 hours in memory and up to seven (7) days in the shared cache. For the small fraction of flagged calls, a human-review buffer may hold prompt and answer text for up to seven (7) days, with earlier deletion when review concludes; database-backup copies expire on the 30-day backup cycle.

The credit ledger is append-only and is retained as evidence after an account is deleted, unlinked from the live account, and so is the Meter-SPW per-call audit record, which is the evidence behind every charge. This is an integrity property, not a retention oversight: a ledger that can be rewritten is not a financial record. Neither record contains prompt text.

6. Breach Notification

No system is immune to compromise. If a breach affects your data, we will notify you at your account email without undue delay.

Where SciTech processes Personal Data on a customer's behalf, the Data Processing Agreement additionally commits us to notify the customer within seventy-two (72) hours where feasible after becoming aware of a confirmed incident, and to take commercially reasonable steps to investigate, contain, and remediate it.

7. Authorized Safety Testing

Authorized safety testing requires prior written approval. This includes red teaming, prompt injection testing, jailbreak testing, exploit testing, vulnerability testing, adversarial testing, automated safety probing, and attempts to compromise models, agents, tools, integrations, or provider terms.

To request authorization, contact security@scitechsolutions.ai and include:

  • your name and organization;
  • scope of requested testing;
  • target environment or account;
  • testing dates and methods;
  • data you expect to access or generate;
  • whether third-party model providers, customer environments, or production systems are involved.

Approval is case by case and is not guaranteed.

8. Prohibited Testing Without Written Authorization

Do not conduct testing that involves:

  • unauthorized access to data, accounts, systems, prompts, outputs, logs, API keys, provider keys, or credentials;
  • data exfiltration, data destruction, persistence, malware, ransomware, credential theft, phishing, or social engineering;
  • denial-of-service, load testing, spam, service degradation, or rate-limit abuse;
  • testing against third-party model providers, customer environments, or production systems without authorization;
  • bypassing provider restrictions, model terms, regional restrictions, billing controls, or safety controls;
  • public disclosure before coordinated remediation.

9. Reporting Format

When reporting a vulnerability, include:

  • description of the issue;
  • affected endpoint, product, API, page, or workflow;
  • reproduction steps;
  • impact assessment;
  • proof of concept, screenshots, logs, or request IDs if safe to share;
  • whether any data was accessed;
  • your contact information.

10. Our Response

We will review reports, prioritize based on severity and exploitability, and take commercially reasonable steps to investigate and remediate valid issues. We may request additional information. We do not guarantee a bounty, payment, public credit, timeline, or specific remediation result unless separately agreed in writing.

11. Contact