Security and trust
Read-only until you say otherwise.
Watching production needs read access and nothing more. Letting sudoSRE act is a separate decision, and every action waits for a person unless your policy says otherwise.
Trust boundary
What leaves your environment: nothing.
- It runs in your cluster
- sudoSRE installs into your own Kubernetes cluster with one Helm chart. There is no sudoSRE-operated service holding a copy of your production data or a path into your infrastructure.
- Your telemetry stays put
- Prod Map keeps a model of your services, their signals, and their changes inside your cluster. Nothing is sent to us, and nothing is used to train a model.
- You bring the model
- Point sudoSRE at a model endpoint your organization has already approved, with your own key, in your own account.
- It proposes, people approve
- Rollbacks, restarts, and scaling are proposed with their evidence and wait for a person to approve them, unless your policy allows a specific kind to run outright.
Design properties
Defaults, not options.
Each of these is how a fresh install behaves. None of them require a configuration flag to turn on.
- Read-only by default
- A fresh install can watch but not change anything. Write permissions are granted only when you enable actions, one kind at a time.
- Narrow RBAC
- The agent gets get, list, and watch on the resources it reads. Patch rights on workloads are added only when actions are enabled.
- Every action is logged
- Each proposed, approved, rejected, and executed action is recorded with who approved it and what changed.
- Every claim cites evidence
- A finding lists the signals, changes, and events it rests on. A claim with nothing behind it is not printed.
- No raw logs kept
- Prod Map stores aggregated signals and references, not copies of your logs or request payloads.
- Reviewable by your security team
- Architecture documentation and the threat model for every design partner. Source code access for review under contract.
Threat model
What can go wrong, and what limits it.
Being specific about the limits is more useful than a claim of total coverage.
# What the cluster agent can do on install. Illustrative.
# Nothing here can write.
apps/v1 deployments, statefulsets, get, list, watch
daemonsets, replicasets
v1 pods, events, configmaps get, list, watch
eBPF request metadata only no payloads
actions: off # patch rights are added per action kind, laterthreat
Text in a log line or commit message injects instructions
response
The model may propose something strange. The worst outcome is a proposed action, which a person reads before approving, with the evidence it claims to rest on beside it.
threat
The agent is used to change the cluster
response
In read-only mode the agent has no write permissions. When actions are enabled, it can only run approved actions of the kinds you allowed, in the namespaces you allowed.
threat
A wrong finding leads to a wrong rollback
response
Each finding shows its evidence, what it ruled out, and a confidence level, so a weak conclusion is visible before anyone approves it. After any action, sudoSRE checks whether the service actually recovered.
threat
Sensitive detail reaches a third party
response
Data stays in your cluster and is sent only to the model endpoint you chose. sudoSRE operates no service that receives it.
Responsible disclosure
If you find a vulnerability, email security@sudosre.dev. We will acknowledge within three working days and keep you updated until it is resolved. Please give us a reasonable window to ship a fix before publishing.
A PGP key and a formal disclosure window will be published before general availability.
Bring your security team in early.
Design partners get the architecture documentation and threat model up front, and source code access for review under contract. We would rather answer the hard questions before deployment than after.