Architecture & Deployment Models

Hosting topology

TATER is a multi-tenant SaaS platform on Microsoft Azure with strict per-tenant data partitioning enforced server-side. Customer data never leaves the tenant boundary; cross-tenant queries are explicitly opt-in (SuperAdmin only) and use forceQueryPlan: true so the Cosmos SDK fans out across all partitions instead of routing to a single one.

User Browser
    │
    ├─→ www.tatersecurity.com  ──┐
    │                            ├─→ Azure Static Web App (swa-tater-marketing)
    ├─→ app.tatersecurity.com  ──┘    Marketing pages + TATER.html (app)
    │
    ├─→ ops.tatersecurity.com  ──→ Azure Static Web App (swa-tater-app)
    │                              TATER Ops (help desk, scripts, workflows)
    │
    ├─→ manage.tatersecurity.com →  Azure SWA — TATER Manage (SuperAdmin only)
    │
    ├─→ my.tatersecurity.com   ──→ Azure SWA — My TATER (per-user dashboard)
    │
    └─→ api.tatersecurity.com  ──→ Azure Function App (func-tater-sec-api)
                                          │
                                          ├─→ Azure Cosmos DB (ComplianceDB)
                                          │      Partition key: /tenantId
                                          │
                                          ├─→ Azure Key Vault (X.509 certs, secrets)
                                          │
                                          ├─→ Azure Automation Account
                                          │      Scan-M365Cloud, Run-Remediation, etc.
                                          │
                                          ├─→ Anthropic API (AI Compliance Analyst, MCP)
                                          │      Optional, BYOK supported
                                          │
                                          └─→ External SIEM (syslog/CEF or webhook)

All resources live in rg-tater-prod in the TATER Security subscription, Azure region East US 2. Federal/dedicated deployments are provisioned in a customer-isolated subscription with separate Cosmos accounts.

Deployment models

Capability	Multi-tenant SaaS	Dedicated tenant	GCC / GCC High
Hosting region	Azure East US 2 (commercial)	Customer-selected commercial region	Azure Government (East/West US Gov) — roadmap 2026 H2
Cosmos isolation	Per-tenant partition key	Dedicated Cosmos account	Dedicated Cosmos in Gov cloud
API surface	`api.tatersecurity.com`	Customer-vanity domain	Customer-vanity domain on .gov / .mil
Time to provision	Same-day with sales-assisted onboarding	~5–10 business days	FedRAMP authorization gates timeline
BYOK support	Yes (Anthropic AI)	Yes (Anthropic + Cosmos CMK)	Yes (Customer-managed keys throughout)
SOC 2 Type II	In progress (Q4 2026)	Inherits from SaaS attestation	FedRAMP Moderate roadmap 2027–28
Backup/restore	Continuous, 7-day PITR	Continuous, configurable retention	Continuous, customer-controlled
Pricing	Per-user-seat, monthly	Per-user-seat + dedicated infra fee	Custom (sovereign-cloud premium)

On-prem self-hosted is not currently supported. The platform's compliance posture, threat-intel feeds (CISA KEV, EPSS, regulatory feeds), and AI capabilities depend on continuous cloud connectivity. Air-gapped deployment is on the roadmap behind GCC High but is not committed.

Data flow — what crosses each boundary

From customer endpoints → TATER

Compliance scan results (control-by-control pass/fail/manual + evidence text)
Endpoint inventory: hostname, OS, hardware ID, device serial, MDE risk score
Software inventory (Phase 4): installed packages with versions for KEV correlation
Optional: agent command stdout/stderr (when Phase 2 remote control or Ops Script Library job runs)

From customer M365 / cloud tenants → TATER

Microsoft Graph queries via tenant-scoped app registration (read-only by default)
Defender for Endpoint / Intune / Purview compliance state
Conditional Access policies, PIM assignments, user authentication methods (read-only)

What we don't collect

Email content, calendar contents, file contents from SharePoint/OneDrive
User passwords (Entra ID handles authentication; we never see credentials)
Endpoint browsing history, application telemetry beyond explicit pageview beacon

Integrations matrix

TATER integrates with the systems your team already uses. Most integrations are read-only; write integrations are explicitly opt-in per organization.

System	Direction	Auth method	Scope
Microsoft Entra ID	Read	App registration, certificate-based	Users, groups, sign-ins, CA policies, PIM, auth methods
Microsoft Graph (M365)	Read	App registration, certificate-based	Exchange, SharePoint, Teams, Defender, Intune, Purview
Microsoft Defender for Endpoint	Read	App registration	Devices, vulnerabilities, software inventory
Microsoft Intune	Read	Graph API	Device compliance, configuration profiles
Azure subscriptions	Read	Service principal	Resource inventory, RBAC, NSG rules, Key Vault, Defender for Cloud
Microsoft Sentinel / QRadar / ArcSight / Splunk	Write (audit forwarding)	Syslog UDP/TCP	CEF-formatted audit log entries
Generic webhook (HMAC-signed)	Write	HMAC-SHA256	Compliance events, override creation, scan completion
Jira / Jira Service Management	Read + Write	API token (encrypted at rest)	Ticket creation from issues, status sync
ServiceNow	Read + Write	OAuth or basic (encrypted at rest)	Incident / change request creation
Microsoft Teams	Write	Webhook	Notifications
Slack	Write	Webhook	Notifications
Azure DevOps	Read + Write (bidirectional sync)	PAT (encrypted at rest)	Work items in/out, status sync via service hooks
SMTP / Microsoft Graph email	Write	App password / Graph token	Notification delivery, report email
Power BI / Power Automate	Read	Custom connector + API key	Compliance datasets, scan completion triggers
Anthropic Claude API	Read + Write	API key (BYOK supported)	AI Compliance Analyst, Evidence Agent, MCP server
CISA KEV feed	Read	None (public)	Known Exploited Vulnerabilities cross-reference
endoflife.date	Read	None (public)	Software lifecycle data for app discovery

Every credential is encrypted at rest with AES-256-GCM. Every external write is HMAC-signed where the destination supports it. SSRF protection (private IP / metadata endpoint blocking) applies to every webhook URL.

Stack at a glance

Frontend

Vanilla JavaScript + CSS variables (no framework lock-in). Single-page apps deployed to Azure Static Web Apps. MSAL.js with 3-CDN fallback for Entra authentication.

API

Azure Functions v4 (TypeScript, Node.js 22). 75 MCP tools, 90+ REST endpoints, all rate-limited and audit-logged.

Database

Azure Cosmos DB SQL API. Per-tenant partition. Continuous backup with self-service PITR. Composite indexes on high-traffic containers.

Endpoint agent

Single static Go binary. CGO-free Windows + Linux. macOS arm64 + amd64 with system tray. SHA256-verified auto-update. Runs as Windows service / systemd / launchd.

Cloud scanning

Azure Automation runbooks (PS 5.1 + 7.2). Per-org dedicated Automation accounts for client tenant scans.

Anthropic Claude (latest model). BYOK supported. MCP server (HTTP + stdio) with 75 tools. No customer data leaves Anthropic's commercial API path; no training on customer data.

Customer-side prerequisites

Microsoft 365 cloud scanning

Entra ID app registration in the customer tenant with read-only Graph + Defender + Intune permissions (we provide a setup runbook wizard)
One-time admin consent
Optional: certificate-based authentication for runbook scans (no client secrets)

Endpoint scanning

TATER Agent installed via Intune Proactive Remediation, MSI, or Linux package — single static Go binary, ~10–15 MB per platform
Outbound HTTPS to api.tatersecurity.com on port 443. No inbound firewall rules required.
Optional: SCAP / DISA STIG .ckl imports from existing scanner output

For SIEM forwarding

Syslog endpoint reachable from Azure (UDP/TCP) or webhook URL with HMAC validation
No agent installs needed for SIEM forwarding — we push directly

More questions? Architecture review calls are available for active prospects under NDA.

Request architecture review → Trust Center