Every boundary, and exactly what crosses it.
Odonat asks for write access to your production environment. That is only reasonable if you can see where the process runs, what it is permitted to call, and what stops it when it is wrong. Everything on this page is taken from the Helm chart you install, not written for the website.
One namespace, two containers, zero inbound ports.
Everything Odonat installs lives inside the innermost box. Nothing outside your VPC can open a connection to it.
Six crossings. Two of them carry nothing.
This is the complete list. If a reviewer finds a seventh, that is a bug and we want to hear about it at contact@odonat.ai.
What the ClusterRole does not contain.
A permission list is easy to read charitably. The useful question is what is missing, because that is what a fully compromised agent still cannot do. These verbs appear nowhere in the chart.
Pod hardening
runAsNonRoot: truereadOnlyRootFilesystem: trueallowPrivilegeEscalation: falsecapabilities.drop: ["ALL"]seccompProfile: RuntimeDefaultThese are set in the Deployment template, not exposed as values. There is no override that turns them off.
Four stages, and what bounds each one.
Each stage degrades toward doing nothing. The interesting column is the third.
NOT BUILT. The intent: correlate a pull request against every workload that changed in the window, so latency regressions and malformed config surface before the merge button does anything. There is no traffic capture, no replay runner and no CI integration in the agent today. Every row below this one is live.
Bounded by Nothing to fail, because nothing calls it. Odonat polls Alertmanager beside production and is never invoked by CI. A reliability tool that can block your deploys is a new source of outages, which is why this stage stays out of the merge path even once it exists.
NOT BUILT. The intent was a canary: 1% of production traffic observed for six minutes. Argo Rollouts and Flagger already do progressive delivery, so the useful work is reading their analysis results rather than reimplementing traffic splitting.
Bounded by Traffic is shaped through your existing Istio or App Mesh, not replaced by ours. If the agent dies mid-rollout your orchestrator carries on.
Alerts normalise into one shape. The causal engine matches them against workloads that changed in the window, eliminates any that shipped after the symptom began, and returns a culprit with a confidence score.
Bounded by There is no model anywhere in this path. Every stage is deterministic code, so the same inputs produce the same verdict and there is no provider that can be down, rate-limit you, or change its behaviour under you.
Above 85% confidence the executor opens a revert pull request, the single entry on a compiled allowlist. Below it, no action is taken and the decision is recorded with the reason. There is no approval queue: a refusal is a refusal, and the record is how you see it.
Bounded by The allowlist is compiled into the binary, not prompted. Drops, deletes, truncates, namespace deletions and force pushes raise an exception the calling code cannot catch. The ServiceAccount holds no mutating verb at all, enforced by CI, so the agent cannot change your cluster even if the gate were wrong.
The chart is plain YAML, short enough to read in one sitting, and your platform team should read it rather than take our word for any of the above. What it renders, and the values you actually override, are on the deployment page.