Skip to content

Commit bd23368

Browse files
docs(blog): add distribution post batch (#28)
Signed-off-by: Shreyansh Sancheti <43677304+shreyanshjain7174@users.noreply.github.com>
1 parent 082bc6f commit bd23368

1 file changed

Lines changed: 172 additions & 0 deletions

File tree

‎blog/distribution-batch-2026-08.md‎

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
# Clawdlinux distribution batch
2+
3+
Anonymous drafts for developer and platform-engineering channels.
4+
5+
Use the visual listed with each post. Keep the author field empty.
6+
Do not claim customer adoption, air-gap certification, or complete end-to-end attestation.
7+
8+
## Post 1: The boundary question
9+
10+
AI agents are moving from demos into production systems.
11+
12+
The hard question is not whether an agent can call a tool.
13+
14+
It is what happens when the tool call is wrong.
15+
16+
Who is the agent acting as?
17+
What can it reach?
18+
Who approves the action?
19+
What record can an auditor verify later?
20+
21+
Kubernetes gives teams the place to answer those questions.
22+
It does not answer them by itself.
23+
24+
Clawdlinux is an open Kubernetes governance layer for AI agent workloads.
25+
It adds runtime-neutral workload controls, egress policy generation, and offline audit verification primitives.
26+
27+
The current repository is honest about its limits.
28+
Some controls are generated but depend on cluster enforcement.
29+
The full signed artifact path is still a release gate.
30+
31+
That is a better starting point than pretending the problem is solved.
32+
33+
Repo: https://github.com/Clawdlinux/agentic-operator-core
34+
35+
Visual: https://raw.githubusercontent.com/Clawdlinux/agentic-operator-core/main/assets/landing-hero.png
36+
37+
## Post 2: Agent egress is a practical control
38+
39+
Prompt instructions are not a network boundary.
40+
41+
An agent can be told not to call an endpoint.
42+
A compromised tool can still try.
43+
44+
A declared egress policy gives the cluster a second control point.
45+
46+
The Clawdlinux operator can generate default-deny and allow-list policy objects for managed workloads.
47+
Cilium FQDN policy templates are available when the cluster supports them.
48+
49+
The policy is not magic.
50+
The CNI must enforce it.
51+
The selectors must be correct.
52+
The workload must declare the destinations it needs.
53+
54+
That is the practical model for Kubernetes AI agent egress policy:
55+
make the allowed boundary explicit, then verify the cluster enforces it.
56+
57+
Docs: https://clawdlinux.org/products/operator
58+
59+
Visual: Mermaid diagram showing AgentWorkload -> admission -> policy -> sandboxed pod -> allowed endpoint.
60+
61+
## Post 3: Offline audit evidence
62+
63+
A log line is not automatically evidence.
64+
65+
If an auditor can edit the record without detection, the record is weak.
66+
67+
The Clawdlinux operator repository includes HMAC hash-chain and JSONL verification primitives.
68+
The `audit-verify` path can verify exported records without a live control plane.
69+
70+
That matters for air-gapped AI agent deployment.
71+
The auditor may not have access to the production cluster.
72+
The verifier still needs a stable artifact and a clear failure result.
73+
74+
The current code does not claim that every run already emits a complete signed artifact.
75+
That connection remains a release gate.
76+
77+
The useful design question is simple:
78+
what exact file does the auditor receive, and what command proves it was not changed?
79+
80+
Repo: https://github.com/Clawdlinux/agentic-operator-core
81+
82+
Visual: before/after terminal capture of a clean verification and a deliberate tamper failure.
83+
84+
## Post 4: Runtime-neutral means less lock-in
85+
86+
A governance layer should not require one agent runtime.
87+
88+
Teams already have choices:
89+
- a custom pod
90+
- a workflow engine
91+
- a runtime with its own agent resource
92+
93+
The Clawdlinux operator uses runtime adapters around the workload boundary.
94+
The governance controls stay at the pod and network layers.
95+
96+
That keeps the hard control in one place:
97+
isolation, egress, cost paths, and audit primitives apply to labeled workloads.
98+
99+
The adapter chooses how a workload starts.
100+
It should not reimplement the security model.
101+
102+
This is the boring architecture choice.
103+
Boring is useful when a platform team has to maintain it.
104+
105+
Docs: https://github.com/Clawdlinux/agentic-operator-core/tree/main/pkg/runtime
106+
107+
Visual: one diagram with three runtime inputs converging on the same policy and evidence boundary.
108+
109+
## Post 5: A Helm chart where operators search
110+
111+
Platform engineers do not need another landing page first.
112+
They need a chart they can inspect and pull.
113+
114+
The Clawdlinux operator chart is published as a public OCI artifact.
115+
116+
```bash
117+
helm pull oci://ghcr.io/clawdlinux/agentic-operator-core/agentic-operator \
118+
--version 0.1.0
119+
```
120+
121+
The chart metadata describes the real scope:
122+
Kubernetes agent governance, gVisor isolation, egress policy, cost controls, and audit verification.
123+
124+
Artifact Hub listing:
125+
https://artifacthub.io/packages/helm/clawdlinux-operator/agentic-operator
126+
127+
The first install still needs a real cluster review.
128+
Run it with the CNI, RuntimeClass, storage, and image assumptions your environment supports.
129+
130+
Repo: https://github.com/Clawdlinux/agentic-operator-core
131+
132+
Visual: Artifact Hub package screenshot beside the `helm pull` command.
133+
134+
## Post 6: What this does not claim
135+
136+
Clawdlinux is not a claim that Kubernetes makes agents safe by default.
137+
138+
It is not a claim that generated NetworkPolicy objects are enforced by every CNI.
139+
It is not a claim that every run already produces a complete signed attestation.
140+
It is not a claim of FedRAMP, HIPAA, or air-gap certification.
141+
142+
It is a set of Kubernetes governance and evidence primitives:
143+
- runtime-neutral workload adapters
144+
- gVisor RuntimeClass mutation for labeled pods
145+
- generated network policy objects
146+
- cost and model-routing paths
147+
- offline JSONL and hash-chain verification tools
148+
149+
The practical test is small.
150+
Pick one workload.
151+
Declare its allowed destinations.
152+
Run the cluster checks.
153+
Export the record.
154+
Verify it offline.
155+
156+
If that workflow does not work in your environment, the right result is a bug report or a missing control.
157+
Not a marketing claim.
158+
159+
Repo: https://github.com/Clawdlinux/agentic-operator-core
160+
Visual: one screenshot of the actual verification command and its output.
161+
162+
## Distribution checklist
163+
164+
- [ ] Add the public OCI chart to Artifact Hub. Registration is complete; wait for processing.
165+
- [ ] Verify the Artifact Hub package page after processing.
166+
- [ ] Request Google Search Console reindex for `https://clawdlinux.org/` and `/products/operator`.
167+
- [ ] Publish one post at a time. Do not schedule all six without feedback.
168+
- [ ] Use the raw hero image for Post 1 only.
169+
- [ ] Use real terminal captures for Posts 3 and 5.
170+
- [ ] Do not publish an anonymous post under a fake person or fake customer.
171+
- [ ] Keep the Clawdlinux brand visible. Keep the author identity optional.
172+
- [ ] Track installs, replies, and qualified conversations. Do not use impressions as validation.

0 commit comments

Comments
 (0)