Trust & Security

We hold ourselves to the standard we sell.

Xtrom secures other companies' AI agents — so our own security posture is foundational, not an afterthought. This page explains how we protect your data and the controls we operate today. For the full technical control mapping, see our SOC 2 evidence pack (available under NDA).

Last updated: September 27, 2026 · North-star Week 1 (invariants + verifiable supply chain)

Core promise: your agents and their data stay in your environment. The Xtrom data plane runs inside your own VPC on any cloud (EKS/AKS/GKE, pluggable JIT backend). Prompts, secrets, tool inputs/outputs, and processed content are evaluated locally and never transmitted to us. The Xtrom-managed control plane only ever sees privacy-scrubbed, per-tenant HMAC-pseudonymized metadata.

Product invariants (locked, CI-enforced)

Three commitments define what Xtrom is. Any code or configuration that violates them is by definition not-Xtrom. A build-blocking CI hook (scripts/check_invariants.py) enforces them on every pull request. Changing any invariant requires a PR to PRODUCT.md with maintainer sign-off.

Deterministic, zero-egress data plane. The enforcement path makes no network calls, reads no wall-clock, and ships no ML weights. A verdict is a pure function of (policy_bundle, event, prior_taint_state). Two runs on two machines produce byte-identical outputs — verified by 10k-run differential fuzz between the Python reference and the Rust production engine.
ML lives only in the control plane. Trained detection models are never shipped to the customer VPC. The data plane calls a signed /score endpoint or runs a quantized model behind an inference boundary that never exposes readable weights. The deterministic guarantee above does not depend on ML.
Every enforcement decision is replayable from the event log. The audit trail is WORM, actor-attributed, tamper-evident, and complete enough that any historical decision can be re-evaluated on a fresh engine with the same policy_bundle.version and produce the same verdict.

Data protection at a glance

Customer-owned data plane

Runs in your VPC on any cloud. Sensitive agent data never leaves your environment.

KMS-signed policy

Policy bundles signed with KMS RSASSA_PSS_SHA_256 in prod (HMAC dev-only). Every decision stamps its policy_version.

Immutable audit (WORM)

Actor-attributed audit written to S3 Object-Lock (COMPLIANCE mode) — readable, never rewritable.

Data minimization + PII scrub

Per-tenant HMAC-SHA256 pseudonymization on every external log path. Prod refuses to boot without the salt — no fall-open.

Cross-tenant isolation

Every DynamoDB read/mutate scopes by pk=TENANT#…; mutation-tested with 10 isolation tests.

Zero standing secrets

JIT broker enforces standing_secrets == 0. Ingest refuses grants without a bounded TTL (max 24h).

Architecture

Xtrom uses a clean control-plane / data-plane split. The data plane (interceptor + deterministic engine + gateway) is deployed in your environment and makes all allow / step-up / block decisions locally, in-line with your agents. The control plane handles policy signing, dashboards, and cross-fleet detection corpus, and only ever receives privacy-scrubbed metadata. This design means a compromise of our control plane cannot expose your agent data.

Runtime enforcement (shipped rules)

Least-privilege capabilities — ungranted tool → BLOCK (L4:scope).
Prod-destructive step-up — rds_delete / kubectl_delete / terraform_apply / execute_shell on env=prod → STEP-UP.
Secret-egress allowlist — secret leaving to a non-allowlisted host → BLOCK.
Human approvals — STEP-UP → approvals queue → approve/deny → WORM audit; silence-is-a-DENY SLA.
Deterministic taint / IFC — untrusted data ↛ sensitive action, the guarantee (published as CaMeL research).

Platform hardening (Phase 1–3 sprint, 2026-09-26)

Policy-versioned decisions with gateway-cached bundles, fail-closed on stale cache.
Signed API-version + policy-bundle schema_version handshake — no silent drift.
Micro-frontend SRI loader (SHA-384/512) — supply-chain swap is a hard error, not silent RCE.
Two-tier rate limit + Prometheus /metrics (RED + kill-switch + fail-closed counters).
Webhook retry + DLQ; STEP_UP approval SLA (silence is a DENY, never an ALLOW).
Global kill-switch (fail-safe — a partition cannot flip it on) with admin+reason gate and audit event.
Cross-language decision parity fuzzer (Python engine ≡ Go gateway, 500 iters/CI).

Verifiable supply chain (cosign + SBOM + Rekor)

Every Xtrom container image is keyless-signed via Sigstore/Fulcio and ships with a CycloneDX SBOM attested by cosign. Signatures land in the public Rekor transparency log, so any customer or researcher can verify without contacting us. The signing identity is our GitHub Actions deploy workflow on refs/heads/main — a Fulcio short-lived certificate, no long-lived signing key to rotate or leak.

$ cosign verify \
  --certificate-identity-regexp \
    '^https://github\.com/saurabhpanday57/xtrom/\.github/workflows/deploy\.yml@refs/heads/main$' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  <ecr-registry>/xtrom-alpha-control@sha256:<digest>

Full guide with verify-attestation for the SBOM and Rekor cross-check: SUPPLY-CHAIN.md. SLSA build-level provenance (mode=max) is emitted by buildx today; SLSA-3 attestation-generator upgrade is tracked and in-progress.

Encryption & key management

In transit: TLS at API Gateway HTTP API; internal service calls over HTTPS.
At rest: KMS CMK; DynamoDB SSE-KMS; S3 SSE-KMS; SQS SSE; ECR KMS.
Policy signing: KMS asymmetric (RSASSA_PSS_SHA_256) in prod; default_signer() refuses to guess.
Secrets: brokered just-in-time (STS / Vault / GCP-WI / Azure-MI) so agents hold no long-lived credentials.

Compliance roadmap

Framework	Status	Notes
SOC 2 Type II	Attesting toward	Technical controls implemented and mapped (see evidence pack under NDA); organizational policies, DR drills, and an observation period with an auditor still to close.
ISO/IEC 27001	On roadmap	Planned following SOC 2 Type II attestation.
HIPAA	On roadmap	For healthcare deployments; BAA available on request.
EU AI Act readiness	Supported	Agent inventory + WORM audit + CSV/SIEM export cover the evidence surface.
GDPR / CCPA	Supported	DPA available on request; see Privacy Policy.

Documentation: security questionnaires, architecture diagrams, sub-processor lists, and the SOC 2 control-mapping evidence pack are provided to customers and prospects under NDA. Request via security@xtrom.ai.

Operational security

Continuous monitoring, centralized logging, and alerting; /metrics scrape target on the gateway.
Vulnerability management: dependency scanning, SAST/DAST, and periodic third-party penetration testing.
Secure SDLC with peer review and least-privilege CI/CD; OIDC deploy (no static keys); per-env approval gates.
Documented incident-response plan with defined severities and customer-notification commitments.
Business continuity: multi-AZ managed serverless, SQS + DLQ with redrive, DynamoDB PITR (prod), deletion protection (prod).

Sub-processors

We use a small set of vetted sub-processors (cloud infrastructure, analytics, communications), each bound by confidentiality and data-protection terms. A current list is available on request, and we provide advance notice of material changes where required.

Responsible disclosure

We welcome reports from security researchers. If you believe you've found a vulnerability, email security@xtrom.ai with details and reproduction steps. We commit to acknowledge promptly, investigate in good faith, keep you updated, and not pursue legal action for good-faith research conducted under this policy. Please don't access others' data or degrade the service while testing.