AI agent security in Kubernetes needs a production-readiness delta

At a glance

What this is: This is a security checklist for deploying AI agents to production Kubernetes, with the key finding that existing PRR controls need a sequenced runtime delta for non-deterministic workloads.

Why it matters: It matters because platform, IAM, and security teams need runtime-derived identity and behavior artifacts before they can safely govern AI agents, service accounts, and tool access in production.

By the numbers:

• The sensor runs at the kernel layer with single-digit overhead, including 1 to 2.5% CPU and 1% memory, and captures syscall and network activity for every pod in the Deployment.
• A common pattern is that the agent’s ServiceAccount is granted about 30 to 50 permissions during development and uses only 3 to 5 of them in production.

👉 Read ARMO's checklist for deploying AI agents to production Kubernetes

Context

AI agent security in Kubernetes starts with a simple governance problem: a workload that behaves non-deterministically cannot be reviewed as if its privilege needs were fixed at design time. The manifest describes intent, but the agent exercises identity at runtime through dynamic tool calls, changing egress paths, and model-dependent behavior, so the production-readiness review has to move from static configuration to observed execution.

That is why the article frames the PRR Delta as a sequence rather than a checklist of independent hardening tasks. For platform teams, the issue is not whether resource limits, ServiceAccounts, and NetworkPolicy still matter. It is that AI agents need runtime artifacts before those controls can be tuned safely, which makes the deployment pipeline itself part of identity governance.

The checklist is aimed at Kubernetes operators, but the governance implication reaches across NHI, workload identity, and agentic AI programmes. When the platform team cannot prove what the agent loaded, what it invoked, and what it actually used, the security team is left approving production access without a behavioral baseline.

Key questions

Q: How should security teams govern AI agents that call internal tools from Kubernetes?

A: They should separate runtime containment from identity governance. Kubernetes can isolate execution, but the tool boundary still needs delegated identity, per-request authorization, and action-level logging. Without those controls, the agent behaves like an unscoped service account with model-driven output, which makes attribution and revocation much harder.

Q: Why do AI agents complicate Kubernetes least privilege?

A: Because their effective privilege is not fixed at deployment. An agent can load different tools, call different endpoints, and exercise identity in ways the manifest did not predict. Least privilege therefore has to be derived from observed runtime behavior, otherwise entitlement reviews overstate or understate the access the agent actually needs.

Q: What breaks when enforcement is applied before observation in agent deployments?

A: Policy gets written against assumptions instead of data. Without a behavioral baseline, detection cannot distinguish drift from compromise, and NetworkPolicy or seccomp rules may block legitimate agent behavior or miss real risk. In practice, the deployment becomes harder to operate and easier to misclassify.

Q: Who should approve go-live for AI agents that use dynamic tool calls?

A: Approval should sit with the platform and security owners who can verify the runtime artifacts, not only with application developers. The decision should depend on the observed AI-BOM, declared-vs-observed reconciliation, and confirmed behavioral patterns that show the agent is operating within its intended envelope.

Technical breakdown

Observe first: why runtime AI-BOMs matter for AI agents

The article treats observation as the first dependency because static manifests do not tell you what an AI agent actually loads at runtime. A runtime AI-BOM captures the model version, MCP servers, and transitive dependencies that appear after startup, alongside syscall and network activity. That distinction matters because supply chain risk in agentic workloads often appears after deployment, not at build time. The runtime AI-BOM becomes the evidentiary layer for everything that follows, including baseline creation and policy promotion.

Practical implication: build runtime inventory before enforcing controls, or your policies will be written against assumptions instead of observed behavior.

Posture and declared-vs-observed reconciliation for ServiceAccounts and tool access

Posture in this checklist is not just about Kubernetes hardening. It is about reconciling what the deployment ticket says the agent may do with what the agent actually does during observation. The article’s declared-vs-observed report highlights a common NHI pattern: an agent may receive dozens of permissions but exercise only a small subset in production. That gap is the real governance problem because it inflates blast radius and weakens revocation logic. The tool gateway, not the prompt, defines application-layer authorization.

Practical implication: compare granted ServiceAccount scope to observed API use before go-live, and treat unused permissions as excess access, not harmless headroom.

Detect and enforce only after confirmed behavioral patterns exist

The article’s detection model assumes confirmed behavioral patterns must come before enforcement. That means the platform has to separate expected drift, such as model updates or new tool registration, from suspicious change in identity exercise or egress behavior. If enforcement is promoted too early, the SOC will inherit noisy policies built without a behavioral baseline. The article’s sequencing also shows that runtime artifacts are not documentation outputs. They are control inputs that determine what can be detected, what can be allowed, and what can safely reach production.

Practical implication: wire detection and enforcement to observed behavioral baselines, and promote policies only after the agent’s normal operating range is known.

NHI Mgmt Group analysis

Runtime behavior, not the manifest, is the real identity boundary for AI agents. The article is right to treat the deployment manifest as an incomplete trust signal because non-deterministic workloads can load different models, tools, and dependencies after startup. In NHI governance terms, that means the identity surface is exercised at runtime, not provisioned once and assumed stable. Platform teams therefore need an operational model that can observe, reconcile, and govern the agent as it behaves, not as it was declared.

Declared privilege is not the same as exercised privilege, and the gap is where blast radius forms. The article’s 30 to 50 permission pattern collapsing to 3 to 5 used permissions is a classic excess-access signal. This is the same governance problem seen across human IAM and NHI programmes: entitlement sets grow faster than actual need, then survive because no one has a runtime basis for pruning them. The practitioner conclusion is that access scope must be justified by observed use, not inherited assumptions.

Sequenced control dependency is the right model for agentic Kubernetes governance. Observe, posture, detect, and enforce are not parallel activities when the workload is an AI agent. Each step produces the artifact the next step consumes, which is why the article’s PRR Delta is stronger than a flat control checklist. This sequencing is what converts agent behavior into a governable identity lifecycle, and it should be treated as part of release engineering, not a separate security afterthought.

ServiceAccount sprawl becomes more dangerous when agents can call tools dynamically. Shared or over-broad agent identities blur audit trails, and dynamic tool invocation widens the effective attack surface beyond the Kubernetes object itself. That means NHI governance has to span both cluster identity and application-layer authorization, because the real control point is the tool gateway as much as the ServiceAccount. The practitioner takeaway is that a per-agent identity model is the minimum viable starting point for production AI agents.

Runtime-derived policy promotion is the only defensible way to avoid week-one failure. Policy written before behavior is observed will usually be either too broad to matter or too narrow to operate. The article’s insistence on promoting NetworkPolicy and seccomp from observed behavior captures a discipline that applies across modern identity programmes: controls should codify reality, not speculation. For platform and IAM teams, that means production approval should depend on runtime evidence, not developer intent.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows how easily runtime access assumptions drift away from actual practice.
• For a broader view of where that drift shows up across agentic systems, see OWASP Agentic AI Top 10 for the control classes most often stressed by dynamic tool use.

What this signals

Runtime-derived governance is becoming the only reliable model for agent workloads. AI agents are not governed safely by static declarations alone because their effective access changes when tools, model versions, and egress paths are discovered at runtime. That is why the control conversation is moving from build-time policy to observed behavior, with SPIFFE workload identity specification becoming more relevant wherever workload identity needs cryptographic proof and a clear trust boundary.

Identity blast radius is now a deployment artifact. Once platform teams start reconciling declared and observed access, the size of the permitted scope becomes measurable, reviewable, and reducible. The governance opportunity is to treat every agent deployment as an identity lifecycle event, not only as application release engineering.

Observer-first security will define the next phase of AI agent operations. Teams that can produce runtime inventories, baselines, and correlation-ready telemetry will have a far better chance of governing agentic behavior without freezing delivery. The practical shift is to align release gates with evidence, then tie those gates back to the NIST AI Risk Management Framework for accountability and measurement.

For practitioners

• Define a PRR delta for every AI agent deployment Extend the existing Kubernetes production-readiness review with AI-specific checks for runtime identity, dynamic tool use, and behavioral observation before go-live.
• Capture a runtime AI-BOM before production traffic starts Record the model version, tool endpoints, and transitive dependencies actually loaded at runtime so supply chain review is based on evidence, not manifest intent.
• Reconcile granted permissions against observed API use Compare the ServiceAccount scope and tool privileges granted at deployment with the APIs and tools the agent actually exercises during the observation window.
• Promote policy only after baseline evidence exists Use observed egress, syscall patterns, and confirmed behavioral baselines to generate NetworkPolicy and seccomp rules, then promote them with the deployment.

Key takeaways

• AI agent deployments in Kubernetes need runtime identity governance because static manifests do not capture dynamic tool use or post-startup behavior.
• The article’s most important operational signal is the declared-versus-observed gap, which can turn ordinary over-provisioning into high-blast-radius access.
• Platform teams should treat observation, posture, detection, and enforcement as a sequenced dependency chain, not as parallel hardening work.

Key terms

• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Declared-vs-observed reconciliation: Declared-vs-observed reconciliation compares what a deployment says an agent may do with what the agent actually does during observation. In agentic environments, this exposes excess access, hidden dependencies, and tool paths that static review misses, making it a core control artifact for production approval.
• Application Profile DNA: A behavioural baseline built from what a workload actually does in production, including processes, network destinations, and system calls. It is used to derive least-privilege controls from evidence rather than from guessed or static entitlement models.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• Implementation specifics for the eBPF observation sensor and the runtime AI-BOM workflow on Kubernetes.
• Concrete examples of the declared-vs-observed reconciliation report and how the promotion gates are assembled.
• Per-cloud implementation notes for IRSA on EKS, Workload Identity on GKE, and Defender for Containers on AKS.
• The step-by-step route from confirmed behavioral patterns to enforceable NetworkPolicy and seccomp profiles.

👉 The full ARMO post covers the runtime artifacts, control sequencing, and go-live gating logic in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.