← Security at QuotaGuard

Information Security Policy

Owner: Alpine Shark LLC · Review cadence: semiannual and annual · Effective: June 12, 2026

1. Purpose and scope

This policy defines how Alpine Shark LLC ("QuotaGuard") protects the information involved in operating the QuotaGuard Static and QuotaGuard Shield proxy services. It applies to QuotaGuard personnel, the production infrastructure, and the operational data the services process.

QuotaGuard operates two products: QuotaGuard Static, an HTTP and SOCKS5 proxy, and QuotaGuard Shield, a TLS-wrapped proxy. Both support inbound and outbound traffic.

2. The data QuotaGuard handles

QuotaGuard's services operate as network proxies. The governing principle is that QuotaGuard does not store customer application payload in any mode, and does not decrypt it except for QuotaGuard Static in TLS-terminating inbound mode. The information QuotaGuard processes in ordinary operation is operational connection metadata: timestamps, source and destination host and port, byte counts, status codes, and proxy identifiers.

QuotaGuard classifies the data it handles into two categories: operational connection metadata, which it processes to route and operate the service, and customer application payload, which QuotaGuard does not store and, except for Static inbound, does not decrypt or inspect. For Shield in both directions and for Static outbound, full URLs, query strings, request and response headers, cookies, authorization headers, and message bodies are not logged or accessible at the proxy layer.

QuotaGuard Static, in TLS-terminating inbound mode, terminates TLS using a customer-supplied or QuotaGuard-provided certificate and operates at the HTTP layer by design. In that mode the full request URL is visible at the proxy and logged, while headers, cookies, and bodies are not. Customers who require that the proxy never terminate TLS select Shield, which routes on SNI without decrypting.

Customer-controlled metadata, such as destination hostnames used for routing, is visible to the service for routing. Customers are instructed not to place sensitive data, including PHI, in hostnames, domains, or configuration fields.

3. Roles and responsibilities

QuotaGuard is operated by a focused engineering team. Infrastructure access is restricted to a small number of named, authorized personnel. The founder is accountable for this security program and its review. Security responsibilities are assigned to the founder and the engineering team.

4. Access control

Administrative and production access is restricted to authorized QuotaGuard personnel.

  • Multi-factor authentication is enforced on the administrative and production systems in the customer-data path, including AWS, GitHub, Google Workspace, and Heroku at the platform level, and on Stripe, Cloudflare, and Postmark.
  • Production access is limited to the operations team, with administrative access to the AWS account and shell access to proxy hosts through AWS Systems Manager Session Manager. Access is revoked through AWS IAM credential revocation on departure.
  • Non-interactive programmatic access uses access keys without console login.
  • Shared credentials are held in a company 1Password vault, and where a credential is shared, multi-factor authentication is carried through 1Password shared TOTP.

Customer dashboard access (dash.quotaguard.com):

  • The dashboard offers per-user TOTP multi-factor authentication with backup codes.
  • Passwords are stored using bcrypt with a per-user salt at cost factor 12.
  • Marketplace single sign-on by signed token is available to Heroku, AWS, and Azure addon customers.

5. Encryption

In transit:

  • Shield enforces TLS on the customer-to-proxy connection (port 9294 for HTTPS, port 1081 for secure SOCKS), and the plaintext equivalents are not open on Shield hosts.
  • Inbound Shield is limited to port 443, and port 80 redirects to HTTPS. The only plaintext-forwarded path is the Let's Encrypt ACME challenge, which carries no customer payload.
  • Administrative access uses TLS through AWS Systems Manager Session Manager and SSH with strong ciphers.

At rest:

  • Operational data stores are encrypted at rest with AES-256: SSE-S3 for S3, AWS-owned keys for DynamoDB, and AWS-managed keys for RDS MySQL.
  • At-rest keys are managed by AWS key infrastructure.

Customer keys:

  • For Shield, customer TLS private keys are never uploaded, because Shield routes on SNI without terminating TLS. For Static inbound in TLS-terminating modes, customers upload certificates so the proxy can terminate TLS.

6. Acceptable use

  • Production access is limited to authorized personnel and is used only to operate and support the service.
  • Credentials are managed through the company 1Password vault and are not shared outside it.
  • Personnel do not access customer payload, because the proxy architecture does not expose it and payload is not stored in any mode. Administrators access operational metadata and infrastructure only as required for operations.
  • Customers must not transmit prohibited data, including PHI, through channels not designed to carry it, including support tickets and customer-controlled metadata fields.

7. Change management and software development

Development is performed using GitHub for version control and code review, with changes documented at commit and reviewed before release, and deployment through GitHub-based workflows.

8. Vulnerability management, incident response, and business continuity

These areas are governed by separate documents: the Vulnerability and Patch Management Statement, the Incident Response Policy and Plan, and the BC/DR Summary. These detailed documents are available under NDA; request access at Security at QuotaGuard.

The proxy design reduces attack surface. The proxy does not store customer payload in any mode and, except for Static inbound, does not terminate TLS, and the managed AWS services in the path (RDS, DynamoDB, S3) are maintained and patched by AWS. QuotaGuard has had no reportable security incidents in the last 36 months.

9. Subprocessors and third parties

QuotaGuard maintains a subprocessor list; the published version lists subprocessor names and purposes. Subprocessors process operational metadata, billing, DNS, support, and email, and none are intended to process customer payload. Subprocessors are established providers operating under their own attestations.

10. Policy governance

This policy is owned by the founder and is reviewed on a semiannual and annual cadence, covering access review, subprocessor review, and policy review, with an annual re-evaluation of certification posture. Security inquiries and reports are received at security@quotaguard.com.