Wiki · Concept · Last reviewed June 25, 2026

Pod Security Standards

Pod Security Standards are Kubernetes' built-in profile language for saying how much privilege a pod should be allowed to request.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, Pod Security Standards, Pod Security Admission, sandboxing, AI governance

Definition

Pod Security Standards, or PSS, are Kubernetes policy profiles for pod-level security. Kubernetes documentation defines three cumulative policy levels: Privileged, Baseline, and Restricted. Privileged is intentionally broad and unrestricted. Baseline is minimally restrictive and blocks known privilege escalations while remaining broadly usable. Restricted is more restrictive and follows current pod-hardening practices.

The standards describe what a pod may ask the cluster to allow: host namespaces, privileged containers, Linux capabilities, host paths, seccomp, AppArmor, SELinux, privilege escalation, and other security-context fields. They are not an AI-specific safety framework. They are a Kubernetes vocabulary for reducing workload blast radius.

How It Works

Pod Security Admission is the built-in admission controller that implements the standards. Kubernetes documentation says namespaces can configure three modes: enforce, which rejects violating pods; audit, which records audit annotations while allowing the pod; and warn, which shows user-facing warnings while allowing the request. Namespace labels such as pod-security.kubernetes.io/enforce, audit, and warn set the chosen level, and version labels can pin checks to a Kubernetes minor version.

This makes PSS different from ValidatingAdmissionPolicy, Kyverno, and OPA Gatekeeper. Those tools can express custom policy. PSS gives a standardized set of pod-hardening profiles that administrators can apply through namespace labels.

The security context is the field family that makes many of these checks concrete. Kubernetes' security-context documentation says security contexts define privilege and access-control settings for pods or containers, including discretionary access control, SELinux labels, privileged or unprivileged execution, Linux capabilities, AppArmor, seccomp, and privilege escalation.

Agent Context

For AI systems, the relevance is runtime containment. Browser automation workers, coding-agent sandboxes, model-serving pods, tool servers, vector stores, and evaluation jobs can all run as Kubernetes pods. A deployment agent that creates those pods should not be able to silently request host access, broad kernel privileges, or unrestricted volume mounts unless the namespace is intended for that risk.

A practical AI platform might run ordinary tool servers under Baseline, require Restricted for untrusted code-execution workers, and reserve Privileged for tightly controlled infrastructure namespaces. Those are deployment choices, not Kubernetes claims about model behavior. Passing a Restricted profile means the pod configuration met that profile. It does not prove the model is safe or the workflow is authorized.

Governance Use

A governance-grade PSS record should preserve namespace, labels, selected modes, selected versions, pod name, workload owner, service account, security context, admission result, warning or audit message, exception path, and reviewer. For AI workloads, it should also connect the pod to the model, tool, pipeline, or evaluation job it supports.

The rollout path matters. Warn and audit modes can show where existing workloads would fail before enforcement begins. Enforcement changes should be staged, documented, tested against representative workloads, and paired with a rollback path. Otherwise a good hardening rule can become an availability incident.

Limits

Pod Security Standards are necessary but narrow. They do not verify image provenance, inspect software bills of materials, restrict network egress, authorize API calls, prevent prompt injection, or evaluate generated content. They also do not replace runtime monitoring, workload identity, RBAC, network policy, supply-chain verification, or human approval for consequential agent actions.

PSS also operates where Pod Security Admission is enabled and labels are correctly scoped. Privileged namespaces, exempt users, emergency procedures, separate clusters, or non-Kubernetes workloads can sit outside the control. The record should name those gaps instead of pretending the profile covers the whole system.

Source Discipline

Claims about Pod Security Standards should cite Kubernetes documentation on PSS, Pod Security Admission, namespace-label enforcement, security contexts, and Linux kernel security constraints. Claims about AI should be labeled as deployment inferences: PSS governs pod configuration, and the AI relevance follows when agent and model infrastructure is deployed as pods.

Do not collapse PSS into general sandboxing. AI Agent Sandboxing includes filesystems, tools, credentials, networks, approvals, and logs. PSS addresses a specific Kubernetes layer: whether pod specifications request dangerous runtime privileges.

Spiralist Reading

Spiralism reads Pod Security Standards as a vocabulary of refusal at the container boundary. The pod asks for privilege; the namespace answers with a profile.

That is not enough to govern an agent, but it is one of the places governance becomes real. A system that cannot say no to a privileged pod will struggle to say no when automation asks for more.

Sources

Return to Wiki