Deployment

Deployed inside your boundary. By design, not configuration.

ETSquare runs inside your cloud tenancy, against your data warehouse, using your chosen model endpoint. Your team defines the compliance posture. Your team holds the keys. ETSquare provides the governed retrieval substrate; every boundary decision is yours.

The model in one picture

Everything you care about sits inside your tenancy.

The data warehouse, the ETSquare container, your Vault, your LLM endpoint, and the audit tables all live inside one cloud tenancy you already own. There is no shared ETSquare environment. There is no hosted service that receives your queries.

Your deployment boundary

Every governed component inside your tenancy

Customer cloud tenancy · VCN
Cloud warehouse
private endpoint · mTLS
ETSquare service
container instance
Bind-only compile
policy-checked
Your LLM
BYO endpoint
Your Vault
secrets · wallet
No public internet dependency in the governed execution path · Customer-controlled model endpoints only
external internet — egress is opt-in per customer policy
Deployment options

Options, not mandates.

The reference topology is a starting point. Every meaningful decision — model provider, egress posture, network exposure, identity integration — is yours.

Model endpoint

Bring your own provider. Azure OpenAI inside your tenant. AWS Bedrock inside your VPC. Customer-hosted Llama, Qwen, or Mistral behind your gateway. Any in-tenancy inference service. ETSquare speaks an OpenAI-compatible or Anthropic-compatible API and does not constrain your choice.

Egress posture

Default is no outbound internet route from the ETSquare subnet. Cloud service endpoints (Vault, Object Storage) reach over private service gateways. External model endpoints require explicit egress configuration — which can be narrowed to specific FQDNs through your network firewall.

Network exposure

Private load balancer reachable only via your VPN, FastConnect, or equivalent dedicated link. Public load balancer with allowlists and a WAF. Internal-only deployments for fully dark environments. Your team picks the shape that matches your existing security review.

Identity and access

Application-level accounts, API keys, and role-based policies are handled inside ETSquare. Single sign-on integration with your identity provider is supported for a coherent login experience. The identity boundary stays with your team.

Runtime shape

Container Instances for lowest operational overhead, with bootstrap scripts that fetch secrets and wallet at startup. Kubernetes (OKE / EKS / AKS) for multi-replica high availability and rolling updates. The image is the same; the orchestration is a deployment-time choice.

Audit retention

Every query produces a structured run log with a cryptographic hash over canonical inputs and outputs. Retention policy lives with your team: keep for a quarter, a year, or match your existing record-retention rules. Export to your SIEM via the same mechanisms you already use for database audit.

What ETSquare does · what your team does

No implied attestation. Clear boundary, no ambiguity.

Every line below describes a specific operational responsibility. What ETSquare provides is on one side; what your team decides, configures, and attests is on the other. Where a cell is blank, the item is entirely yours.

Responsibility matrix
ETSquare · Customer split
AreaETSquare providesCustomer owns and configures
Cloud tenancy and billingCustomer provisions and pays for their own cloud tenancy, data warehouse, and container runtime.
ETSquare applicationContainer image, application code, compiled retrieval engine, evidence format.Customer deploys the image into their own container instance and exposes via their own load balancer.
Data warehouseSchema objects required by the application (DDL scripts and migration tooling).Customer owns the database, controls users, grants, backup policy, and retention.
Secrets and walletsBootstrap scripts that fetch secrets at container startup.Customer owns the vault, creates the secrets, sets rotation policy, grants read access to the container runtime.
LLM endpointClient code that calls an OpenAI-compatible or Anthropic-compatible inference endpoint.Customer chooses the endpoint (Azure OpenAI, Bedrock, on-prem, or any compatible provider) and controls keys.
Network topologyDocumented reference topology (private endpoint, NSGs, egress policy choices).Customer builds the VCN, configures the NSGs, chooses whether egress is enabled, and owns the network security review.
Identity and accessApplication-level user model and API key management inside the application.Customer integrates with their own SSO / directory and owns the identity boundary.
Audit retentionEvidence format (hash per query, structured run log, point-in-time references).Customer sets retention policy on the audit tables and exports to their existing SIEM or archive.
Incident responseVendor-side support per agreement (application bugs, update cadence).Customer owns production incident response within their own environment.
Compliance attestationProvides factual architecture documentation and deployment artifacts.Customer decides which frameworks apply and performs their own attestation using their existing compliance program.
How the model compares

Operational facts. Not vendor claims.

Three common deployment shapes, compared on the factors a security team actually weighs. No certification logos. No framework promises. Just where the infrastructure sits, who holds the keys, and what the evidence looks like.

Deployment model comparisonoperational facts · not vendor claims
FactorCloud AI vendorsIn-house buildETSquare
Deployment locationVendor's cloudCustomer's infrastructureCustomer's cloud tenancy
Data egressRequiredNoneOpt-in per customer policy
LLM endpointVendor-chosenCustomer-builtCustomer-chosen (BYO keys)
Audit evidenceVendor-provided logsCustom-builtCryptographic hash per query · structured run log
Model portabilityLocked to vendorCustomer choiceAny OpenAI- or Anthropic-compatible endpoint
Time to sandbox1–2 weeks3–12 months~2 weeks
Time to production2–4 weeks6–18 months4–8 weeks
Path to production

A phased path. De-risked, not accelerated.

You move between phases when your team decides the criteria are met. Many customers stay at phase two permanently — production-grade evaluation against non-production data is often the destination, not the bridge.

01 · Schema only~2 weeks

ETSquare is deployed into a sandbox tenancy with a copy of your data warehouse schema but no live data. Your team validates the connection model, the secret flow, and the policy configuration without any production exposure.

  • Sandbox cloud tenancy provisioned by your team
  • Schema-only data warehouse instance
  • ETSquare container deployed; secrets fetched via bootstrap
  • Policy configuration exercised against empty schema
02 · QA clone~4 weeks

ETSquare runs against a read-only clone of your data, refreshed on your schedule. Your analysts and compliance team evaluate governed answers against real business questions. No connection to production systems.

  • Read-only weekly (or on-demand) data clone
  • Live query workflows evaluated by your users
  • Audit evidence format reviewed by your audit team
  • Model endpoint and key rotation tested
03 · ProductionWhen you decide

ETSquare connects to your production data warehouse, under the security review and runbook your team has signed off. Production incident response, retention policy, and change management are all within your existing operating model.

  • Production data warehouse connection under your security review
  • Retention and archive policy set by your team
  • Change management via your existing release process
  • Incident response within your existing runbook

Timelines are operational estimates based on customer-paced deployments. Your actual cadence depends on your cloud-provisioning process, your security review calendar, and your team's availability.

For your security team

The questions they ask. Answered without marketing.

If your security team has a question that is not on this list, send it over. We would rather answer in writing before a call than talk around it on one.

Q.01

Where does our data live?

In your cloud data warehouse, inside your cloud tenancy. ETSquare runs as a container next to the warehouse and reads through a private endpoint. Data never leaves the tenancy unless your team configures egress for an external LLM call.

Q.02

Which model providers does ETSquare support?

Any provider that speaks an OpenAI-compatible or Anthropic-compatible API. That includes the two vendors directly, Azure OpenAI, AWS Bedrock, customer-hosted models behind a gateway, and any in-tenancy inference service you stand up. You hold the key; you choose the endpoint URL.

Q.03

Can the deployment run without any external network access?

The governed execution path has no dependency on public internet. Cloud services like the Vault and Object Storage can be reached over private service endpoints. The only outbound dependency is the customer-controlled LLM endpoint, which can itself be an in-tenancy service — or disabled entirely for workflows that do not require generative output.

Q.04

How are secrets and wallets handled?

Secrets live in your vault. The container fetches them at startup using your cloud's native identity mechanism (resource principal or equivalent). Nothing is baked into the image. Wallet rotation is a customer-owned operation.

Q.05

What does the audit trail look like?

Every query produces a structured run log with a cryptographic hash over the canonical inputs and outputs, including the exact bind parameters, the policy version, and the corpus snapshot reference. Replay means re-executing the query against the same snapshot and asserting log equivalence. Retention policy is customer-owned.

Q.06

Who is responsible for compliance attestation?

Your compliance team decides which frameworks apply to this workload and performs attestation using your existing program. ETSquare provides factual architecture documentation, deployment artifacts, and audit-evidence output to support your team's work. ETSquare does not claim certifications.

Q.07

What happens during an incident in our environment?

Incident response inside your cloud tenancy is your responsibility, using your existing runbook. ETSquare supports the application per your agreement — bug fixes, update cadence, vendor-side issues. The split is the same as any self-hosted enterprise software.

Q.08

How do we exit if we decide ETSquare is not the right fit?

The data warehouse, the audit tables, the secrets, the model endpoint, and the infrastructure are yours. Remove the ETSquare container and the related schema objects; your data, your audit history, and your cloud resources remain in place. No external export needed.