CLI workflow

Read-Only kubectl Commands for AI Agents

Pin the context and namespace, use get, describe, logs, and auth checks, and reject mutating subcommands.

Containers and KubernetesRead only

Prepare tools, authentication, and evidence first

Install the recommended tools, confirm minimum permissions, and keep compatibility separate from real execution records.

kubectldocs-verified
Inspect Kubernetes with structured output and gate every cluster-changing command.

Recommended install

$ shell
brew install kubectl
Authentication
kubeconfig, service account token, exec credential plugin
Tested agents
No agent-specific execution record
Evidence status
docs-verified · Documentation checked 2026-07-10
Independent CLI execution
No independently executed version recorded
jqverified
Parse, filter, validate, and transform JSON locally with deterministic output.

Recommended install

$ shell
brew install jq
Authentication
No authentication for the base operation
Tested agents
No agent-specific execution record
Evidence status
verified · Documentation checked 2026-07-10
Independent CLI execution
jq-1.7.1-apple · 4 checks

Copy or download this workflow Skill

The Skill includes input and output contracts, recommended tools, approval points, rollback, and evidence boundaries. Review it against the active environment before saving.

read-only-kubernetes-audit-SKILL.md
---
name: read-only-kubernetes-audit-workflow
description: "Pin the context and namespace, use get, describe, logs, and auth checks, and reject mutating subcommands."
---

# Read-only Kubernetes audit

## Intended outcome

Explain cluster health and likely causes while keeping the audit technically read-only.

## Evidence boundary

- Tool status distinguishes `docs-verified` material from independent execution; the two are not interchangeable.
- The current registry does not attribute a tool execution to a particular agent, so compatible agents cannot be called tested agents.
- Reconfirm the target account, environment, version, and official documentation before execution.
- Never auto-execute an R2, R3, or confirmation-marked step; obtain explicit approval immediately before it runs.

## Recommended tools, installation, and authentication

- **kubectl** (evidence: `docs-verified`, docs checked: `2026-07-10`, no independently executed version recorded)
  - Install: `brew install kubectl`
  - Authentication: kubeconfig, service account token, exec credential plugin
  - Minimum permissions: Use a dedicated context and RBAC role limited to get, list, and watch for audit tasks.
- **jq** (evidence: `verified`, docs checked: `2026-07-10`, independently tested version jq-1.7.1-apple recorded)
  - Install: `brew install jq`
  - Authentication: not required for the base operation
  - Minimum permissions: No service credential is required; restrict filesystem and network access to the task.

## Input contract

- Explicit kube context
- namespace scope
- read-only credentials
- audit question

## Output contract

- Resource inventory
- event and log evidence
- access check
- prioritized findings

## Safe workflow

1. **Confirm identity and scope** — Print the active context and verify allowed actions before reading workloads.
   - Input: Kubeconfig and target namespace
   - Output: Context, namespace, and permission boundary
   - Risk: `read-only`
   - Command: `kubectl config current-context && kubectl auth can-i --list -n example`
2. **Inspect resources** — Read workload status, recent events, descriptions, and bounded logs using structured output where practical.
   - Input: Confirmed context and namespace
   - Output: Resource, event, and log evidence
   - Risk: `read-only`
   - Command: `kubectl get pods -n example -o json`
3. **Summarize without remediation** — Rank findings and propose any mutation as a separate command with expected impact.
   - Input: Collected cluster evidence
   - Output: Audit report and optional remediation proposal
   - Risk: `read-only`

## Ask before proceeding

- Any apply, patch, edit, scale, rollout, delete, exec, or port-forward command
- Reading secrets or broadening namespaces
- Switching to a production context not supplied by the user

## Rollback

- No cluster rollback is required for the read-only path
- Remove temporary local output containing sensitive logs
- For approved changes, capture the existing resource manifest first

## Official sources

- [kubectl reference](https://kubernetes.io/docs/reference/kubectl/) — Official Kubernetes command reference for resource inspection and mutation.

Outcome, inputs, and outputs

Define the result and evidence before the agent selects a command.

Goal

Explain cluster health and likely causes while keeping the audit technically read-only.

Required inputs

  • Explicit kube context
  • namespace scope
  • read-only credentials
  • audit question

Expected outputs

  • Resource inventory
  • event and log evidence
  • access check
  • prioritized findings

Read-Only kubectl Commands for AI Agents: safe workflow

Run each step inside its stated boundary and verify the output before continuing.

Step 1Read only

Confirm identity and scope

Print the active context and verify allowed actions before reading workloads.
Input
Kubeconfig and target namespace
Output
Context, namespace, and permission boundary
$ Confirm identity and scope
kubectl config current-context && kubectl auth can-i --list -n example
Step 2Read only

Inspect resources

Read workload status, recent events, descriptions, and bounded logs using structured output where practical.
Input
Confirmed context and namespace
Output
Resource, event, and log evidence
$ Inspect resources
kubectl get pods -n example -o json
Step 3Read only

Summarize without remediation

Rank findings and propose any mutation as a separate command with expected impact.
Input
Collected cluster evidence
Output
Audit report and optional remediation proposal

Approval points and rollback

Pause at the listed decision points and keep recovery instructions beside the action.

Ask before these actions

  • Any apply, patch, edit, scale, rollout, delete, exec, or port-forward command
  • Reading secrets or broadening namespaces
  • Switching to a production context not supplied by the user

Recovery plan

  • No cluster rollback is required for the read-only path
  • Remove temporary local output containing sensitive logs
  • For approved changes, capture the existing resource manifest first

CLI, MCP, or API?

Choose the interface by execution location, identity, output contract, and permission boundary.

CLI

Best when kubeconfig, context, and namespace are explicit and shell-native evidence is needed.

MCP

Useful when cluster access should be mediated through a narrower tool catalog and central policy.

API

Use for a dedicated audit service with service-account identity and durable result storage.

Recommended approach

Use kubectl with read-only credentials; do not rely on command naming alone as the permission boundary.

Official evidence and references

Use these primary or upstream sources to verify current command behavior before acting.

kubectl reference

Official Kubernetes command reference for resource inspection and mutation.

Questions before you run it

Is kubectl exec read-only?

No. It starts a process inside a workload and can change data or behavior, so it belongs behind approval.

Can logs contain secrets?

Yes. Limit the time window, redact credentials, and avoid copying unrelated log lines.

Related tools and guides

Browse sibling guides and choose the next page that best matches the active task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Inspect installation, authentication, structured output, command risk, and official evidence.