Skip to content
AutoObserve
Design Partner

SECURITY & TRUST

Security is part of the platform architecture — not an optional feature.

Direct answers on deployment boundaries, data flow, permissions, and automation — no form gate. AutoObserve is designed for production environments where telemetry, operational decisions, and automation require clear trust boundaries, customer control, and transparent behaviour.

View trust boundariesView deployment architectureContact security
KubernetesOpenTelemetry

Trust boundaries

What AutoObserve does — and deliberately does not do

Platform engineers evaluating infrastructure software need explicit limits, not feature lists. These boundaries define how AutoObserve behaves inside your environment.

What AutoObserve does compared with what it deliberately does not do
AreaAutoObserve doesAutoObserve does not
TelemetryIngests configured telemetryCollect arbitrary production data
KubernetesUses granted permissionsRequire cluster-admin by default
AI / AIDDEProduces evidence-backed recommendationsExecute changes without configured policies
Customer dataProcesses telemetry within your deployment modelImplicitly transmit production telemetry externally
AutomationOperates within defined policiesBypass RBAC or customer controls

Deployment & data flow

Customer-controlled deployment models

AutoObserve runs where you decide. Egress requirements are explicit per deployment mode — never a silent SaaS siphon.

Customer environment

  1. Applications
  2. Collector
  3. AutoObserve
  4. Evidence store

Outside

Nothing — unless explicitly configured

Developer

  1. Laptop
  2. Docker
  3. AutoObserve

Kubernetes

  1. Cluster
  2. Collector
  3. AutoObserve
  4. Storage

Data flow

  1. Application
  2. Collector
  3. AutoObserve
  4. Evidence
  5. Investigation
  6. AIDDE

Data types

Telemetry data types and their purpose in AutoObserve
DataPurpose
MetricsBehaviour
LogsContext
TracesExecution
Resource attributesWorkload identity
Kubernetes metadataRuntime relationships
Deployment eventsChange correlation

AutoObserve ingests what you configure — not everything by default.

View full platform architecture →Deploy on Kubernetes →Why deployment changes belong in observability →

AI trust & automation safety

Evidence before automation

Recommendations are inspectable. Automation is earned through evidence, confidence, and policy — not assumed by default.

Evidence-driven AI

  1. Evidence
  2. Correlation
  3. Investigation
  4. Recommendation
  5. Human review
  6. Automation

  • Evidence visible

    Every recommendation links to the telemetry, changes, and topology that support it.

  • Confidence visible

    Hypotheses ship with confidence bands — not opaque model scores.

  • Reasoning inspectable

    Engineers can follow the investigation path and challenge conclusions.

  • Actions reviewable

    Automation proposals remain policy-bound and human-reviewable before execution.

Automation safety

  1. Observe
  2. Recommend
  3. Approve
  4. Execute
  5. Verify

Confidence ladder

  1. LowObserve
  2. MediumRecommend
  3. HighEligible → Policy → Execute
Explore AIDDE →See an investigation →

FAQ

Evaluation questions for platform engineers

Does telemetry leave our environment?
Design-partner and self-hosted paths prioritize running AutoObserve where your data already lives. Egress requirements are explicit per deployment mode — never a silent SaaS siphon.
Does AutoObserve require internet access?
Not for core investigation workflows in self-hosted deployments. Any outbound connectivity is explicit and documented per deployment mode — there is no hidden phone-home for production telemetry.
Can it run entirely inside our cluster?
Yes — self-hosted deployment is the default posture for early partners. Managed options, if offered later, will be opt-in and documented separately.
Does AIDDE send telemetry externally?
No — AIDDE reasoning runs within your deployment boundary. Recommendations are produced from evidence already inside your environment, not from sending production telemetry to an external model service.
Do we need proprietary agents?
No. AutoObserve is built to consume OpenTelemetry and Kubernetes signals you already emit. Agents are not a prerequisite for the investigation model.
Does AutoObserve replace Prometheus / Grafana / our APM?
No. Those remain source systems. AutoObserve correlates and explains; it does not demand you abandon the tools your on-call already trusts.
What permissions are required?
Least privilege for the signals you choose to connect: telemetry pipelines, change events, and Kubernetes APIs required for topology and runtime context. Exact RBAC is documented during partner onboarding.
How are secrets and PII in logs handled?
Treat logs as untrusted input. AutoObserve supports deployment architectures where sensitive information can be filtered before ingestion. Redaction and field allowlists are part of integration guidance — do not send secrets to any investigation system, including AutoObserve.
Can automation be disabled?
Yes. Automation operates within defined policies and can remain in observe-or-recommend modes until your team explicitly enables execution. Human review stays the default posture for design-partner deployments.
What happens when AutoObserve is wrong?
Every RCA ships with evidence you can inspect and a confidence band. Wrong hypotheses are debuggable — not hidden behind an opaque model score.
Who can see investigations?
Access follows your deployment boundary. There is no public multi-tenant browsing of customer incidents in the design-partner model.
How are upgrades handled?
Upgrades follow your deployment model — container images and Helm charts you control in your cluster. Release notes document breaking changes; design partners get direct engineering access during rollout.

Security contact

Reach the security team

Security reviews, vulnerability reports, and deployment-boundary questions go here — not the general inbox.