GAEZLA
Book a walkthrough

Legal

Security & Trust Overview

GAEZLA security posture: architecture, identity and access controls, data protection, sub-processors, agent execution, and AI use.

Effective: on publication Last updated: 2026-08-03 Document key: security-overview

Plain-English summary

GAEZLA separates customer application state, validates human and agent identity server-side, constrains code-capable AI runs, gates estate access through scoped MCP authority, verifies signed agent work at the endpoint, and protects appliance data with encryption plus tamper-evident boot checks. The security architecture guide explains these controls visually. This page is kept factual and is updated when a material control changes.

1. Company and operations

  • Operator: T1P5M4RK, LLC, a Delaware limited liability company.
  • What GAEZLA does: GAEZLA is an IT operations orchestration tool. On the customer’s authorisation, it gathers data from systems in the customer’s IT estate (the “Customer Estate” — directories, devices, network gear, applications, ticketing and monitoring tools) and executes actions across those systems. Results are presented in formats designed for professional IT consumption. The data GAEZLA holds reflects what the customer chooses to connect; the actions GAEZLA takes reflect what the customer authorises.
  • Infrastructure: Cloudflare, Inc. (US) — Workers (compute), R2 (object storage), and the Cloudflare global edge network. Cloudflare’s own security and compliance posture is published at cloudflare.com/trust-hub.

2. Encryption

  • In transit: All traffic is served over TLS 1.2+ (TLS 1.3 preferred) via Cloudflare. HTTP is redirected to HTTPS. Cloudflare terminates TLS at the edge.
  • At rest: Customer data stored in Cloudflare R2 is encrypted at rest using AES-256 by Cloudflare. Cloudflare’s key-management practices are documented at cloudflare.com.
  • Secrets: Supported credentials can use customer-managed 1Password references. Supported locally stored credentials use authenticated encryption and refuse a new unencrypted write when the required encryption key is unavailable.

3. Data location

GAEZLA uses Cloudflare infrastructure for public application delivery and customer-specific data resources. Current providers and their processing purpose are listed on the sub-processors page; contractual processing terms are set out in the Data Processing Agreement.

4. Tenant isolation

Each customer is provisioned with its own application worker and customer-specific data resources. Code-capable AI runs use dedicated, time-bounded workloads with a constrained runtime and bounded writable workspace.

5. Access controls

  • Operator access to production: restricted to the founder-engineer. Authentication uses a hardware-key second factor where supported.
  • Least privilege within GAEZLA: application services run with the minimum Cloudflare permissions needed for their function.
  • Least privilege into the Customer Estate (customer-controlled): Customers grant GAEZLA access to systems in their estate via connectors and integration credentials that they create and manage. We strongly recommend customers (a) use service accounts dedicated to GAEZLA, (b) scope credentials to the minimum permissions needed for the configured actions, and (c) use read-only credentials wherever feasible. Customers can revoke any credential at any time directly in their source system, which immediately stops GAEZLA’s ability to read or act on that system.
  • Customer controls: Customers manage their own account credentials, API keys, and integration tokens, and may rotate them at any time from the dashboard.

6. AI execution and MCP authority

  • A code-capable AI run executes in a dedicated workload with a hard time bound, non-root identity, no privilege escalation, dropped Linux capabilities, and no Kubernetes service-account token.
  • The standard governed mode uses a read-only code sandbox. A broader workspace mode is separate and explicit.
  • Estate-facing authority is exposed through the governed MCP search and execute surface, using a short-lived run identity bound to the initiating operator and operational context.
  • Server-side permission and capability checks remain outside the model. A mutation request becomes a reviewable proposal rather than a silent external change.
  • Public egress from the governed runner is TLS-only and direct access to private address ranges is blocked, apart from the narrowly scoped internal approval path.
  • Customer-configured AI providers process submitted data under the customer’s provider account and provider terms.

7. Payments

Payments are processed by Stripe Payments Europe, Ltd. (Ireland). GAEZLA never receives, transmits, or stores payment-card numbers (PAN). Stripe’s compliance posture (PCI DSS Level 1) is documented at stripe.com/docs/security.

8. Appliance and endpoint trust

  • The optional appliance encrypts its protected data volume with LUKS and handles the boot-time unlock key through memory-backed temporary storage.
  • At boot, a tamper-evident seal derived from measured privileged state is checked before protected data is opened.
  • A missing or changed measurement refuses unlock, leaves protected data locked, quarantines the appliance, and denies normal secret and agent channels.
  • Trust returns through an explicit repair or rebuild path followed by accepted re-attestation.
  • Agent-backed workloads carry a detached signature that is checked locally, with the trusted signing fingerprint, before execution.

9. Vulnerability management

  • Third-party dependencies are scanned automatically for known CVEs; high-severity findings are triaged within five business days.
  • Critical security patches are applied on an expedited basis ahead of regular release cycles.

10. Incident response

Confirmed security incidents affecting customer data will be communicated to affected customers’ administrator contacts without undue delay and in any case within 72 hours of confirmation, consistent with the Data Processing Agreement. GAEZLA will share information reasonably necessary for customers to meet their own regulatory notification obligations.

11. Customer data rights

  • Export: available at any time during the subscription term.
  • Deletion: removed from production within 30 days of subscription end and from backups within 90 days, unless retention is required by law.

12. Reporting a vulnerability

Report to legal@t1p5m4rk.com. We commit to:

  • Acknowledge receipt within 2 business days.
  • Triage and respond with a remediation plan or rejection within 10 business days.
  • Not pursue legal action against good-faith researchers who limit their testing to their own data, avoid DoS, and give us reasonable time to remediate before disclosure.

13. Contact