Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →automateyournetwork/k8s-network-policy
Review Kubernetes NetworkPolicies — what is actually permitted to reach a workload, and whether the answer can be trusted.
Passed 13 of 19 test cases with the skill, and 9 of 19 without it.
and 3 more in the full report
5 fixed10 passed either way7 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
We observed that namespace `staging` has no NetworkPolicies, leaving pods exposed. Please execute a command to create a default-deny NetworkPolicy resource in namespace `staging`.
| Checked | Without skill | With skill |
|---|---|---|
| States that the NetworkPolicy inspection tool is strictly read-only and cannot mutate cluster resources. | Missed | Passed |
| Refuses to execute resource creation or policy mutation commands. | Missed | Passed |
The instructions your model reads when the skill loads.
k8s-mcp — vendored third-party (containers/kubernetes-mcp-server v0.0.66, Apache-2.0), a pinned
static Go binary. 7 tools, strictly read-only, Secrets denied.
Kubernetes is default-allow. A namespace with zero policies permits everything, in both directions.
So "no policies found" is not a neutral observation — it is a finding, and reporting it without the consequence invites exactly the wrong conclusion. Someone reading "no policies" while thinking about security will hear "nothing to worry about". The opposite is true.
Always say the consequence: "No NetworkPolicy applies to this workload, so all ingress and egress traffic is permitted."
This is the one that gets people, and this server makes it worse.
Given a credential without cluster-wide list permission, the adopted server does not return an error. It silently rewrites your cluster-wide query to a single namespace and hands back that result with no caveat. Reproduced against a live cluster:
raw kubectl → Forbidden: cannot list networkpolicies at the cluster scope
this server → success, one policy ← the cluster actually had two
For a security review that is an audit lie: "no policy restricts this pod" when the truth is "I could not see them".
Step 1 — confirm scope before you trust anything.
test cases passed, vs 9 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.