Before an audit someone asks: "are our workloads non-root, are service account tokens locked down, is there a network policy everywhere?" The usual answer is a spreadsheet and a lot of hope. The assistant answers from the manifests themselves. It says "unknown" when it cannot prove something. It also runs a set of rule-based posture checks (checks in code, with no AI model) on the systems around your clusters.
The assistant generates the posture report on demand. It reads every manifest in every writable repository, the same set of files that the repository scanner sees. Then it renders a PDF.
It creates no merge requests and no issues. The other agents already propose fixes for the gaps it counts. The report is the summary, not a second copy of the work.
The first version covers the controls where a manifest can carry positive evidence.
PSS-restricted:runAsNonRoot, every container, init and ephemeral container includedCIS-5.1.x:sa-token-least-privilege, service account token automountNSA-hardening:NetworkPolicy-present, checked against an index of the whole repository, so a policy in a sibling file still countsA false "compliant" is worse than a false gap. Someone may rely on it in an audit. So a control is satisfied only when the manifest says so explicitly. No finding is not proof. The assistant counts anything that the checks cannot decide as unknown, including an error while checking.
The report says on its face: manifest-checkable subset only, not an attestation.
Each control shows how many workloads the assistant scanned and how they split. A reader sees at once that 140 of 212 workloads prove they run as non-root. Another 31 do not, and 41 could not be decided from the manifest alone.
ISO 27001 and SOC 2 are organisational standards. Mapping down to them is planned as a later layer.
The assistant reads each zone, read-only. It checks the minimum TLS version, HSTS, SSL mode, DNSSEC, managed WAF rules and rate limiting. It also checks for dangling CNAMEs, which point at a target that no longer resolves. They are a classic takeover risk.
If a zone's plan does not include WAF or rate limiting, the check abstains and raises no finding. The assistant reports a setting that it could not read as unobserved, never as fine. A separate check catches an armed edge block that would refuse the egress IPs of your own clusters.
If someone can force-push to the deployment repository, the rest of the chain does not matter. The assistant reviews the forge itself.
The assistant reads every active GKE recommendation for each cluster. The text is Google's, never paraphrased. The assistant already covers some recommendations itself (disruption budgets, memory limits, under-provisioned workloads). It attaches those as supporting evidence. It does not file them twice.
New recommendations arrive as issues. The assistant can also turn them into a draft MR against the matching manifest. This is built but not yet switched on.
Before the assistant proposes a Flux spec.verify block, it checks the chart's
signing with cosign (a tool that checks signatures) and caches the result. A verify block on a chart
that is not cosign-signed would break the release, so the assistant refuses it.
When a proposal pins an image to a @sha256: digest, that
digest needs a receipt from the registry. If nobody looked up the digest, the assistant holds
it for review and never ships it.
Edge, forge and cloud settings mostly live outside your git repositories. So these findings are issues. There is one issue per cause, with the evidence, the risk and the fix steps. Sometimes the setting does live in git, for example in a CI file or a manifest. Then a draft MR is possible.
The full issue is below.
$ gitops-assistant compliance-report --output posture.pdf walking 4 repositories · 1,806 manifests 212 workloads · 3 controls PSS-restricted:runAsNonRoot 140 / 31 / 41 CIS-5.1.x:sa-token-least-privilege 96 / 88 / 28 NSA-hardening:NetworkPolicy-present 171 / 12 / 29 wrote posture.pdf · 0 proposals created
spec: template: spec: automountServiceAccountToken: false # CIS-5.1.x ✓ securityContext: runAsNonRoot: true # PSS runAsNonRoot ✓ initContainers: - name: migrate securityContext: runAsUser: 0 # overrides the pod → gap containers: - name: app
runAsNonRoot: true present on pod and not overridden SATISFIEDrunAsUser: 0 on any container GAP| Control | Standard | Satisfied | Gap | Unknown |
|---|---|---|---|---|
| runAsNonRoot | PSS restricted | 140 | 31 | 41 |
| SA token least privilege | CIS 5.1.x | 96 | 88 | 28 |
| NetworkPolicy present | NSA/CISA | 171 | 12 | 29 |
# quoted, never paraphrased "<Google's recommendation text, exactly as returned>"
+ image: registry.example.com/shop/cart@sha256:9c1e… ✓ receipt: resolved from registry at emission + image: sidecar/labeler@sha256:<digest> ✕ no registry receipt · held (NEEDS_REVIEW)
Illustrative. It has the same shape as the edge-posture issues that the assistant files today. Settings outside git become issues. The assistant changes nothing here for you.
acme-prod · zone shop.example · rule min_tls_below_1_2Zone shop.example accepts TLS 1.0 at the edge. TLS 1.0 and 1.1 are deprecated. They fail most compliance baselines (PCI DSS requires 1.2 or later for cardholder data).
The setting lives in Cloudflare, not in a repository. The assistant's Cloudflare access is read-only.
| Surface | Read | Value |
|---|---|---|
zone settings · min_tls_version | ok | 1.0 |
zone settings · ssl | ok | strict |
| security header · HSTS | ok | disabled (separate issue) |
The assistant read all three surfaces successfully in this run. It would report an unreadable surface as unobserved, never as compliant.
| Check | Result |
|---|---|
| HSTS | disabled · medium · own issue |
| DNSSEC | disabled · medium · own issue |
| Dangling CNAME | old-promo → NXDOMAIN · own issue |
| Managed WAF, rate limiting | not available on this plan · abstained |
Security reports lose their value the first time they are confidently wrong. These rules prevent that.