Recommended Free Tools
Secure a Kubernetes-hosted AI agent at two separate boundaries: restrict what its workload can reach in the cluster, and independently restrict what the agent can do through its tools. Use the checklist below to narrow both kinds of authority, protect credentials and data, harden the pod and image, and verify that the controls work in your specific cluster, CNI, cloud environment, and agent framework.
Start with the agent’s authority
An agent can interpret untrusted input, call tools, retain memory, and propose actions. Kubernetes controls can limit the workload’s access to cluster resources and network destinations; they do not decide whether a proposed tool action is appropriate. Conversely, restricting the agent’s tools does not replace container and cluster hardening.
| Control layer | What to constrain | What it does not replace |
|---|---|---|
| Kubernetes and container | Workload identity, API permissions, reachable services, credentials, processes, and available resources | Authorization of the agent’s proposed actions through application tools |
| Agent and tool execution | Which tools the agent may invoke, their permitted operations and targets, and when human approval is required | Cluster isolation, network controls, or protection of credentials at rest |
Inventory every tool, API, data source, memory store, and external endpoint the agent can use. Give it only what its task needs; distinguish read from write access and scope access to specific resources where possible. Keep authorization outside the model: treat a model-generated tool call as a proposal, then have a separate policy or execution component check its permissions, target, and approval status. The OWASP AI Agent Security Cheat Sheet describes risks and safeguards for tool-using agents.
Require human approval for sensitive or irreversible actions. Bind approval to the actor, tool, target resource, normalized parameters, timestamp, and expiry; use short-lived authorization artifacts and replay protection where relevant. Test abuse cases such as direct and indirect prompt injection, unauthorized tool use, data exfiltration, memory poisoning, excessive autonomy, and cost exhaustion or unbounded loops.
#1 Best Overall
Give the workload a narrow Kubernetes identity
- Use a dedicated ServiceAccount for each agent or trust boundary, then grant only the required resources and verbs. Avoid broad cluster-wide bindings.
- Set
automountServiceAccountToken: falseif the workload does not need Kubernetes API access. If it does, use a bound, time-limited token where available and scope its permissions to the task. - Review permissions to
create,update,patch, anddeletecarefully, especially permissions to create or alter workloads or roles. Kubernetes RBAC is coarse for pod resources: the ability to create workloads can confer powerful access to schedulable nodes unless admission controls and namespace policies constrain what may be created. - Do not let untrusted components create Pods in system namespaces or namespaces where pod creation could enable privilege escalation.
Use the Kubernetes Security Checklist, Kubernetes Application Security Checklist, and Kubernetes guidance on securing a cluster to review identity and access controls in context.
Restrict network reachability
- Confirm that the cluster’s CNI supports and enforces Kubernetes NetworkPolicy. A policy manifest alone does not establish that traffic is being restricted.
- Where feasible, begin with default-deny ingress and egress for the agent’s namespace or workload, then permit only the required peer workloads, ports, and destinations.
- Restrict access to cloud metadata APIs unless the agent explicitly needs it; metadata services can expose instance credentials or provisioning data.
- Keep the Kubernetes API, kubelet API, and etcd off the public internet. Limit etcd access and use authenticated, encrypted connections.
- Document model APIs and agent tools as explicit egress dependencies. Review the allowlist periodically rather than assuming the agent only contacts expected destinations.
- For sensitive workloads, consider a service mesh or other network encryption if the CNI does not provide encryption in transit.
Network behavior depends on the CNI and cloud-provider configuration. Check actual enforcement and connectivity in the environment where the agent runs; Kubernetes’ security checklist, cluster security guidance, and application security checklist provide relevant baseline considerations.
Protect secrets and agent data
- Do not put confidential values in ConfigMaps. Enable encryption at rest for Kubernetes Secret data and encrypt backups.
- Give each agent only the credentials it needs. Keep credentials out of prompts, unvalidated agent memory, logs, and broadly readable environment variables.
- Where practical, deliver credentials through controlled files or volumes with restrictive file permissions rather than environment variables; Kubernetes guidance notes that environment variables can be more prone to leakage in crash dumps and logs.
- Do not grant an agent’s ServiceAccount general read access to Secret resources merely to deliver one credential. Consider a third-party secret store or CSI integration for delivery and centralized rotation, while still restricting access to the injected secret.
- Review and rotate cloud, model, and tool credentials; minimize their scope and lifetime.
For implementation context, consult the Kubernetes Security Checklist, Kubernetes cluster security guidance, OWASP Kubernetes Security Cheat Sheet, and OWASP AI Agent Security Cheat Sheet.
Harden the pod and container
- Run as a non-root user with
runAsNonRoot: trueand an appropriate UID and GID. - Set
allowPrivilegeEscalation: false; avoid privileged containers; and setreadOnlyRootFilesystem: trueif the application supports it. - Drop all Linux capabilities, adding back only those the workload demonstrably needs.
- Enforce an appropriate Pod Security Standard. For sensitive workloads, configure Seccomp, AppArmor, or SELinux profiles and evaluate an isolated
RuntimeClass, such as a sandboxed or virtualized runtime. - Set resource requests and limits appropriate to the workload. Namespace quotas can further constrain resource use and help bound runaway compute consumption.
Stronger runtime isolation can bring compatibility and performance tradeoffs. Evaluate it against the agent’s workload and sensitivity instead of assuming every runtime option is suitable. See the Kubernetes Application Security Checklist, Kubernetes Security Checklist, and cluster security guidance.
Rank #3
Secure images and the software supply chain
- Keep production images minimal and run them as an unprivileged user.
- Pin images by digest or validate signed provenance at admission time. Scan images before deployment and patch known vulnerable software.
- Review the permissions requested by third-party integrations before enabling them. An integration that can read all Secrets or create Pods in a permissive namespace may have authority far beyond its apparent function.
These measures are consistent with the Kubernetes Security Checklist, Kubernetes Application Security Checklist, and Kubernetes guidance on securing a cluster.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Monitor, test, and revisit the controls
- Enable Kubernetes API audit logging and store the records securely for investigation.
- Monitor security-relevant process activity and network communications among services and with external clients or servers.
- Keep agent logs useful for security review while redacting secrets and sensitive data.
- Maintain abuse-case tests and CI/CD release gates for prompt injection, unauthorized tool calls, data leakage, and approval of high-impact actions.
- Reassess policy effectiveness after changes to the cluster, CNI, agent tools, model endpoints, or workload sensitivity.
The Kubernetes Security Checklist cautions that “Checklists are not sufficient for attaining a good security posture on their own.” Use this checklist as a starting point, then validate each control against the actual cluster and agent configuration. See the Kubernetes cluster security guidance, OWASP Kubernetes Security Cheat Sheet, and OWASP AI Agent Security Cheat Sheet.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
