Autonomous write access is a security decision before it is a product feature.
Odonat asks for the right to change your production environment. That only makes sense if the blast radius is bounded by architecture rather than by good intentions. This is how it is bounded.
Runs inside your VPC
The agent is a Helm release in a dedicated odonat-system namespace on your own EKS, GKE, or AKS cluster. It accepts no inbound traffic at all by default: the NetworkPolicy denies every ingress and there is no Service. Telemetry arrives by outbound polling, which is what makes that possible. Pods run readOnlyRootFilesystem and runAsNonRoot. Nothing is exposed to the public internet in any configuration.
One port, only if you ask for it
Default installs accept no inbound traffic at all: the NetworkPolicy ships an empty ingress rule set, which denies everything, and the chart renders no Service. If you want the decision counters in your own Prometheus, set metrics.enabled=true. That is a trade-off an operator makes deliberately, so here is exactly what it changes. It adds one NetworkPolicy ingress rule for one port, 8080, reachable only from inside your cluster. The rule permits any pod in any namespace rather than Prometheus specifically, because a rule narrow enough to name Prometheus would match nothing on most clusters. Port 8080 is a single listener, so opening it for scraping also exposes /healthz and /status. Public inbound stays blocked in both configurations. Set metrics.enabled=false to restore the default posture exactly.
No model sees anything, because there is no model
Correlation is deterministic code, not inference. The agent has no LLM client: no prompt is built, no inference call is made, and no third party receives your telemetry or source. The same inputs produce the same verdict every time, and every verdict can be reconstructed from the decision log. It cannot hallucinate a culprit because nothing generates one.
Credentials are stripped from what the agent does send
The one outbound write the agent makes is opening a pull request on your git host, and it passes through an Envoy sidecar that strips credentials from the request body. API keys, bearer tokens, Slack tokens, private key blocks and passwords inside connection strings are replaced with fixed markers such as [REDACTED_AWS_KEY_ID]. Detection is a fixed set of patterns for known credential shapes: not entropy analysis, and not PII detection. If the filter errors the stream is reset rather than forwarded, and the chart refuses to render a configuration that would forward an unredacted body.
Destructive actions are refused, not discouraged
The execution engine carries a compiled, immutable allowlist. git_revert passes; scale_replica is reserved and is not currently grantable, because the ServiceAccount holds no mutating verb. DROP, DELETE, TRUNCATE, chmod 777, delete_namespace, and force push raise an uncatchable exception and halt execution. This is a hardcoded barrier in Go, not a model instruction.
Confidence gating, then a human
Autonomous execution requires a causal-confidence score of 85% or higher. Anything below that threshold is formatted as an RCA and posted to your Slack channel for one-click approval. The default on uncertainty is to ask, not to act.
Least-privilege, short-lived credentials
Cloud API access uses OIDC tokens valid for a maximum of 15 minutes. The GitHub/GitLab app can read contents and checks and open pull requests, never force push and never merge. The Kubernetes ServiceAccount is read-only: it can list deployments and replicasets and nothing else. It holds no mutating verb of any kind. Administrative write to your cloud provider is denied outright.
Your audit trail, in your SIEM
Every decision Odonat makes is written to an append-only JSONL log in your cluster, and optionally posted to a webhook you choose. The compliance record lives in systems you control, so it survives us and can be reconciled independently.
Exactly what Odonat can touch.
Scoped so that a fully compromised agent still cannot destroy infrastructure or exfiltrate credentials.
Supported environments and scale.
Odonat is language agnostic, because it never reads your code at runtime. It reads two things: the alerts your Alertmanager is already producing, and the Kubernetes API record of which workloads changed recently. There is no tracing, no span ingestion and no sampling, so there is no volume at which correlation becomes a bottleneck. The work is a filter over a list of workloads that changed in a 30 minute window, which is tens of objects, not hundreds of thousands of spans.
Ingest ceiling the pipeline is designed against, not an average measured across a customer base. Same basis as the interception targets on the home page. Ask for the sampling policy and the benchmark methodology in a technical review.
VPC-native telemetry processing with secure egress
All proprietary code and telemetry stay inside your Kubernetes cluster. Nothing is sent to a foundation model, because Odonat does not use one. Correlation is deterministic Go: label matching, elimination of changes that shipped after the symptom began, and a confidence threshold. There is no prompt to scrub, no inference provider, and no GPU to provision. The one thing that leaves your cluster is a pull request on your own git host, and the credentials in its body are stripped on the way out.
How the safety plane is proven, not asserted.
- The barrier is the most tested code we ownThe AST parser and the circuit-breaker allowlist are the only things standing between a model and your database, so they carry the strictest coverage bar in the codebase. A gap there is not a bug, it is an incident. We will show you the coverage report and the allowlist source in a technical review.
- Replay against known-cause incidentsEvery release is scored on a fixture set of incidents whose true root cause is already known, so causal accuracy is measured rather than asserted. The set starts from the four injected fault scenarios below and grows with each customer that opts to contribute anonymised cases.
- End-to-end chaos verificationAn injected fault in a k3s cluster must produce detection, correlation, and a revert pull request, end to end, or the build fails. This runs on every pull request. There is no Slack integration and the agent sends no notifications: the pull request is the notification.
These limits are contractual. The compiled allowlist, the 85% confidence threshold, and the 60-second remediation timeout are not only engineering choices. They are written into section 4 of our Terms of Service, so the boundary on what Odonat may do to your environment is something you can hold us to rather than something you have to take our word for.
Certification status. Odonat holds no third-party security certification today, and we will not imply one. What we can show you instead is the mechanism: the Helm chart, the egress proxy’s redaction rules, the compiled action allowlist, and the RBAC scopes above, all reviewable before you grant a single credential. Ask us for the control matrix and we will walk your team through it line by line.
Where we actually stand, control by control.
Every row below is either a control we can demonstrate today or an honest “not yet”. We would rather you found the gaps here than in a questionnaire.
One sub-processor, and it never sees your source.
Odonat does not operate a region for your data, because Odonat does not hold your data. The agent runs inside your cluster, in whatever region you put it, and the only things that ever cross your VPC boundary are listed below and on the architecture page.
What Odonat cannot catch.
Transparency is critical for infrastructure tooling. Odonat is an operational control plane, not a replacement for human QA. Odonat cannot catch deep business logic flaws that do not degrade system metrics (e.g., calculating a 5% discount instead of 10%). Furthermore, Odonat cannot mitigate physical hardware outages, fiber cuts, or cloud provider hypervisor crashes.