--- title: "From Merged PR to Governed Pod: Automating AI Agent Deployment on Kubernetes" source: "https://www.tigera.io/blog/from-merged-pr-to-governed-pod-automating-ai-agent-deployment-on-kubernetes/" description: "Automating AI agent deployment on Kubernetes: what each pipeline stage must enforce, the 2026 CI incidents that show why, and what a governance layer adds." --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # From Merged PR to Governed Pod: Automating AI Agent Deployment on Kubernetes By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 13, 2026 • 19 min read In short, automating the AI agent lifecycle is this year’s pitch: Google Cloud’s walkthrough of 30th July 2026 turns the whole thing into a conversation with a coding agent. On Kubernetes the deploy half of that lifecycle is already a pipeline and a set of manifests, and 2026 has shown what happens when the pipeline is the soft spot: in March a compromised GitHub Action dumped runner memory and hunted for Kubernetes tokens, and in February a GitHub issue title talked an AI triage bot into exposing a project’s publishing credentials. The pipeline that ships an agent holds more authority than the agent does, and it is the one place that can ship the agent’s permissions in the same commit as its code. This post walks the path from a merged pull request to a governed pod stage by stage, says what each stage must enforce when the workload is an agent, then says what a governance layer like Tigera Lynx can and cannot do about it. It is written for the platform and security engineers who own that pipeline, and the leads who sign off on what it deploys. On 19th March 2026, from about 17:43 UTC, an attacker holding a compromised credential force-pushed 76 of the 77 version tags in [aquasecurity/trivy-action](https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23), the GitHub Action for the Trivy vulnerability scanner, so that each tag pointed at a commit carrying credential-stealing code. Any pipeline that referenced the action by tag ran it on the next scan. By the advisory’s account the payload ran before the legitimate scan, dumped the memory of the runner’s worker process, searched 50 or more filesystem paths for SSH keys, cloud and Kubernetes credentials, Docker configs and `.env` files, and sent what it found, encrypted, to attacker infrastructure. The window was about twelve hours, and the remediation advice is blunt: “all secrets accessible to affected pipelines must be treated as exposed and rotated immediately.” It was the second act. The advisory dates the first compromise to late February; Aqua’s own write-up says the attackers “exploited a misconfiguration in Trivy’s GitHub Actions environment, extracting a privileged access token,” and the maintainers’ [incident thread](https://github.com/aquasecurity/trivy/discussions/10425) says of the rotation that followed that “the process wasn’t atomic and attackers may have been privy to refreshed tokens.” [InfoQ reported on 11th March](https://www.infoq.com/news/2026/03/ai-bot-github-actions-exploit/), citing StepSecurity’s analysis, that the February break-in belonged to a campaign run from a GitHub account describing itself as an “autonomous security research agent powered by claude-opus-4-5,” which gained code execution in five of the seven repositories it targeted, three of them through the `pull_request_target` trigger with an untrusted checkout. GitHub’s [documentation](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows) for that trigger says: “Avoid using this event if you need to build or run code from the pull request.” Before either act, a different pipeline had been opened by a sentence. On 9th February 2026 the researcher Adnan Khan [published](https://adnanthekhan.com/posts/clinejection/) what he named Clinejection. Cline, an AI coding assistant, ran an issue-triage workflow on Anthropic’s `claude-code-action` with Bash, Read and Write tools. “Since the issue title is interpolated directly into Claude’s prompt,” Khan wrote, a crafted title could make the agent install a package from an attacker’s fork, whose preinstall script then ran on the runner. The triage job exposed no publishing secret of its own, but it “shares the same cache scope as the high-privilege nightly release workflow,” so a poisoned cache entry handed over the npm, VS Code Marketplace and Open VSX publishing tokens. On 17th February an unauthorized `cline` 2.3.0 appeared on npm whose only change was a postinstall script that installed a third-party AI agent; Cline said afterwards that the npm token had not been properly revoked during rotation. Set those against the pitch for automating the agent lifecycle. On 30th July 2026 Google Cloud [published a walkthrough](https://cloud.google.com/blog/topics/developers-practitioners/automate-agent-development-lifecycles-with-gemini-enterprise) in which a coding agent scaffolds, deploys, governs, evaluates and publishes an agent from a prompt. The closing line is the thesis: “Your coding agent isn’t just where you write agent code. It’s the control plane for the whole lifecycle.” That is the right ambition. Nobody should be hand-applying manifests for the fortieth agent, and Kubernetes is moving the same way: a [Sandbox resource](https://kubernetes.io/blog/2026/03/20/running-agents-on-kubernetes-with-agent-sandbox) for agent workloads is in development under SIG Apps, its [GKE version](https://cloud.google.com/blog/products/containers-kubernetes/bringing-you-agent-sandbox-on-gke-and-agent-substrate) went generally available on 21st May, and the CNCF’s [2025 survey](https://www.cncf.io/announcements/2026/01/20/kubernetes-established-as-the-de-facto-operating-system-for-ai-as-production-use-hits-82-in-2025-cncf-annual-cloud-native-survey/), published on 20th January 2026, found 82% of container users running Kubernetes in production. The agent is becoming a Kubernetes resource like any other, delivered by a pipeline like any other. Which is the point. A pipeline that can deploy an agent holds the cluster credential, the registry token and the cloud role, more authority than the agent will ever be granted, and in February and March that pipeline was what the attackers went for. The pipeline is part of the agent’s security boundary. It is also the one part of the boundary that can ship the agent’s permissions in the same commit as its code, if you build it that way. ## What changes in a pipeline when the workload is an AI agent? The YAML is mostly the same. [AI Agents on Kubernetes 101](https://www.tigera.io/blog/ai-agents-on-kubernetes-101-from-laptop-script-to-production-pod/) walked one agent from a laptop script to a pod by hand and told you not to stop there. A pipeline automates those steps and adds the ones a hand-applied deployment skips. The difference is in three places. **The artifact does not contain the behavior.** For a web service, the image is the behavior. An agent’s behavior is the image plus a system prompt, a tool list, a model name and whatever its context window collects at runtime, and three of those four are configuration. A pipeline that reviews the image and lets the prompt change through a ConfigMap edit has reviewed the part that matters least. For an agent, a config change is a behavior change. **The pipeline holds what the agent must never hold.** The agent needs a model key. The pipeline needs a credential that can write to a namespace, push to a registry and assume a cloud role. A model key in the pipeline’s secrets is one memory dump from being public, and a kubeconfig in the agent’s environment is one prompt injection from the control plane. And an agent that runs inside the pipeline reads untrusted input with the pipeline’s authority. Khan’s lesson: “AI agents with broad tool access create a low-friction entry point into CI/CD pipelines previously only reachable through code contributions, maintainer compromise or traditional poisoned pipeline execution.” **The permissions are part of the deliverable.** A web service’s NetworkPolicy is hygiene. An agent’s list of which endpoints it may reach, which tools it may call with which arguments and which model it may use is the specification of what the agent is. A pipeline that ships the Deployment and leaves the permissions to a ticket has shipped half an agent, and the half that acts is the half that shipped. The deploy half of the lifecycle has five stages, and each one holds something worth stealing. **Stage** **What it does** **What it holds** **What an agent adds** 1. Build Turns the merged commit into an image Registry push token, the runner’s environment Prompt, tool list and model name are build inputs, versioned with the code 2. Sign and publish Signs the image, packages the chart A signing identity, the chart repository The chart carries the permissions (egress, identity, allowed calls) beside the Deployment 3. Apply A GitOps controller reconciles the chart through admission A credential that writes to the agents namespace Admission refuses an agent without limits, without egress policy, or with the service account token mounted 4. Register and authorize Declares who the agent is and what it may call The registry and the policy store No web-service equivalent. For an agent, this stage is the product 5. Verify Smoke-tests the agent, reads the record Read access to the audit trail The test asserts what the agent cannot do; the evidence comes from enforcement points ![Diagram: five pipeline stages from merged pull request to governed pod (build, publish, apply, register, verify), what each stage holds worth stealing, and what an AI agent adds at each stage](https://www.tigera.io/app/uploads/2026/10/From-Merged-PR-to-Governed-Pod-1.png)Figure 1: The deploy half of the lifecycle. Each stage holds a credential worth stealing, and the fourth has no web-service equivalent. Now translate that into questions an engineering team has to answer: - **Can the agent’s behavior change without a reviewed commit?** If the prompt, the tool list or the model name can be edited in place, the review gate is decoration. - **What can the pipeline’s credential do, and for how long?** A stored personal access token with write scope is what moved 76 tags in March. A token minted for one run, scoped to one namespace and dead when the job ends is worth nothing to a memory dump. - **What does the cluster refuse?** If a chart drops its NetworkPolicy, mounts the service account token or runs as root, does anything say no? Hugging Face’s [post-mortem](https://huggingface.co/blog/agent-intrusion-technical-timeline) of its July intrusion put the alternative in one line: “we had no admission policy rejecting privileged or hostPath pods.” One agent makes each of those an afternoon’s work. Ten agents, built by three teams on two SDKs, make it a spreadsheet nobody updates. Two hundred agents, each with its own pipeline and its own idea of where the key lives, make it a question with no owner, and the pipeline the attacker finds first is the one that answers it. ## What must each stage enforce when the workload is an AI agent? Take the stages above and ask two things of each: what went wrong in a 2026 incident, and what the pipeline has to enforce so that the answer stops depending on anyone remembering. **The stage** **What went wrong in 2026** **So the pipeline must enforce** Workflow configuration Trivy’s February break-in came through a `pull_request_target` workflow running untrusted code with elevated permissions; Cline’s came through an issue title fed to an AI triage agent Actions pinned to a commit SHA, no untrusted checkout under a privileged trigger, untrusted text kept out of shells and prompts, and any AI agent in the pipeline on a read-only token with no shared cache Pipeline credentials A token stolen in February survived a rotation that “wasn’t atomic” and moved 76 tags in March Short-lived credentials federated through OpenID Connect to the cloud and the cluster, nothing long-lived in repository secrets, rotation rehearsed as a runbook Artifact integrity 76 of 77 tags pointed at malicious commits for about twelve hours Images and charts signed at build, referenced by digest, verified at admission; immutable releases Admission Hugging Face’s intruder went from a sandbox to node-level root within three days, with no admission policy rejecting privileged or hostPath pods An admission policy that refuses an agent pod without resource limits, with the service account token mounted, running as root, or with no egress policy selecting it Runtime credentials and egress Pods that “could reach the instance metadata service,” one credential shared across clusters, and in [the May evaluation incidents](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) a route to the internet nobody intended Default-deny egress shipped in the chart, model keys held outside the pod and attached at an enforcement point Registration and authorization Nothing declared who the agent was or what it could call, so the only check was the model’s judgment Identity and allowed calls declared as resources in the same chart, reviewed in the same pull request, evaluated on every request by something the agent cannot edit Evidence Transcripts read weeks later; Trivy’s consumers learned from the advisory which secrets to assume stolen A record written by the enforcement points at the time, and a smoke test that asserts a forbidden call is refused before the release is marked good ![Diagram: a Helm chart with registration and authorization files flows through a GitOps controller, admission and a governed pod to an enforcement point, while a pod applied with kubectl from a laptop is found from the node rather than admitted](https://www.tigera.io/app/uploads/2026/10/From-Merged-PR-to-Governed-Pod-3.png)Figure 2: The permissions ship in the chart. Admission refuses what the chart forgot, and the agent that skipped the pipeline is found rather than trusted. Read column three again. Nothing in it is new technology. SHA pinning and OpenID Connect federation are in [GitHub’s hardening guide](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions). Signing is [cosign](https://docs.sigstore.dev/cosign/signing/overview/); verification at admission is a [Kyverno](https://kyverno.io/docs/policy-types/cluster-policy/verify-images/) rule or Kubernetes’ own [ValidatingAdmissionPolicy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/), generally available since v1.30 in April 2024. The agent-specific part is two rows: the one that treats a prompt as code, and the one that ships the agent’s permissions as a resource. Neither can be delegated to the agent, because [controls the agent can override are not controls](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/), and neither is covered by [the building blocks most clusters already have](https://www.tigera.io/blog/the-ai-agent-accountability-gap-why-network-policies-api-gateways-and-rbac-are-not-enough/), which see pods, addresses and roles rather than agents. Run March through the table and notice what the payload was looking for. It hunted for Kubernetes tokens because a kubeconfig in a pipeline is the shortest path to a cluster. A pipeline whose only cluster credential is minted for the run and dead at the end of it gives a memory dump nothing to carry away, and a cluster whose admission policy refuses a privileged pod gives whatever is carried away nothing to do. Row two protects the pipeline. Rows four to six protect the cluster from the pipeline. In practice the workflow side is short: the job grants itself an OpenID Connect token (`id-token: write`) instead of storing a cloud key, references every action by full commit SHA, signs the image with cosign and pushes the chart to the same registry as an OCI artifact, by digest. The chart side is where the agent differs, because the permissions sit beside the Deployment and a reviewer sees both in one diff: ``` `charts/support-agent/templates/ deployment.yaml # non-root, limits, probes, no service account token service.yaml networkpolicy.yaml # deny all egress, then DNS and the enforcement point serviceaccount.yaml # the identity the agent presents registration.yaml # who the agent is and what it serves authorization.yaml # what it may call; absent means nothing` ``` The cluster then refuses what the chart forgot. A validating admission policy bound to the agents namespaces rejects, in three CEL expressions, a pod that mounts the service account token, sets no resource limits or runs as root. The one check it cannot make is whether an egress NetworkPolicy selects the pod, because it sees only the object being admitted. That needs an engine that can look across resources, which is where Kyverno earns its place, and it is the check that would have closed the door in May. ## What happens when it is done properly? Here is what a governance layer like [Tigera Lynx](https://www.tigera.io/blog/why-we-built-lynx-bringing-control-to-the-age-of-ai-agents/) does for the table above, and what it leaves to you. Both halves matter. Done properly, the last three rows stop being a ticket and become files in the chart. Every agent, MCP server and LLM provider is a Kubernetes custom resource, so the agent’s registration, its identity (SPIFFE, OIDC, or a pod-owner binding for an agent you cannot modify) and the policy that says what it may call are YAML in the same chart as its Deployment, reviewed, applied and rolled back with the code. Authorization runs at a gateway the agent does not control: default deny, evaluated on every request, with the caller’s identity, the target and the operation as context, and for MCP traffic the tool name and its arguments. A fresh install permits nothing until a policy says otherwise, so a chart that forgets its authorization file ships an agent whose calls are refused, which is the right failure. Provider credentials are held at the gateway, referenced from one Secret and injected after the policy check passes, so the model key need not appear in the image, the chart or the pod, and each token the gateway mints is addressed to one destination. The pipeline itself can be registered as a service identity, so the smoke test in stage five calls the agent through the gateway as a named caller. A sandbox policy, enforced in the kernel, names the paths, binaries and destinations a workload may use, and applies to a running workload without a redeploy. Workloads nobody registered are detected from the node itself and classified as sanctioned, shadow or unknown. And every request lands in the Agent Trail with the caller, the target, the policy decision and the model that served the call, written by the enforcement plane rather than narrated by the agent. Now the other half. None of that is automatic, and the first four rows of the table are not Lynx’s job at all. Lynx does not pin your actions, federate your CI to your cloud, sign your images or write your admission policy; that is work you do before the first agent resource is applied, and a governance layer behind a pipeline that still holds a long-lived kubeconfig is a well-governed cluster with an open front door. A policy that permits everything proves nothing, and someone has to write the one that does not; the pull request that adds a `permit` line needs a reviewer who reads it as carefully as the code, because the chart has made permissions reviewable, not reviewed. The gateway governs the traffic that reaches it, and closing the other roads is NetworkPolicy work in your chart; Peter Kelly’s [multi-layer policy post](https://www.tigera.io/blog/multi-layer-policy-for-securing-ai-agents/) covers how the gateway and kernel layers fit. The detector finds the agent that arrived by `kubectl` from a laptop, but a person decides whether it is sanctioned. What the infrastructure provides is the layer the pipeline quietly assumes exists: the ability to say, with evidence, which agents you have, what each one may call, and what each one did. Put in properly, the agent’s permissions reach production the way its code does: in a commit, with a reviewer’s name on it, and with a rollback one revert away. Put in badly, the pipeline is automated, the permissions are a ticket, and the agent is live before the ticket is. ## Frequently asked questions - **What is the AI agent deployment lifecycle on Kubernetes?** It is the path from a merged commit to a pod serving traffic under policy: build the image, sign and publish it with its chart, let a GitOps controller apply the chart through admission control, register the agent’s identity and allowed calls, and verify the result against a record written by the enforcement points. What makes it agent-specific is that the prompt, tool list and model are versioned with the code, and the permissions ship in the same chart as the Deployment. - **Can I run a coding agent inside my CI pipeline safely?** Only with the pipeline’s authority cut down to what the agent needs: a read-only token, no access to a job that holds publishing or cluster credentials, no Actions cache shared with a release job, and no untrusted text such as an issue title or a pull request body in its prompt unless it is treated as hostile. Clinejection is the worked example of every one of those being skipped. Coding agents that run outside the pipeline but touch your clusters raise the same questions; [Peter Kelly’s post on Claude Code sessions](https://www.tigera.io/blog/managing-claude-code-sessions-through-lynx/) covers putting them behind the gateway. - **Should the agent’s system prompt and tool list go through the same pipeline as its code?** Yes. For an agent the prompt and the tool list are most of the behavior, so an edit to either gets the same review, tests and rollback path as a code change. Keep them in the repository, build them into the image or the chart, and treat a live edit to a ConfigMap as drift to revert rather than as configuration. - **What should admission control refuse for an AI agent pod?** At minimum: the service account token mounted, no resource limits, a root user, a privileged security context or a hostPath mount, an unsigned image, and an image referenced by a mutable tag. Then add a check that an egress NetworkPolicy selects the pod. - **Is the pipeline’s record enough evidence for an auditor or a regulator?** It is the part they ask for first: who approved the change, which commit built the image, what policy the agent was given. It is not the whole record. Whether it satisfies a particular regime, HIPAA, the EU Cyber Resilience Act or your own sector’s rules, is a question for your compliance team and, where liability is involved, for a legal opinion on your own case. The other half is a record of what the agent did at runtime, written by the enforcement points; we mapped what [the CRA’s 24-hour clock](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) asks of it. ## Whose pipeline is it? The people who built Trivy’s release automation were thinking about shipping a scanner, and for years it shipped. The attackers in February were thinking about the automation, and they found a workflow trigger documented as unsafe for untrusted code running untrusted code with a token that could rewrite the repository. The second time, in March, they did not need a new way in. The first rotation had left one of their keys valid. Nothing in that story is specific to AI agents, and that is why it matters for them: agents arrive in clusters through pipelines built for web services, and the pipeline’s blind spots become the agent’s. What differs is what the agent does with its freedom once it is there, and that is what the pipeline can now ship: an identity, a list of allowed calls, an egress policy, a sandbox, in the same commit as the code. So ask the question now, while it is cheap, and ask it of a named person. A pipeline nobody owns is maintained by whoever opens the next pull request. **If you are the CISO, the VP of Engineering or the head of platform**, your question is about the fleet. How many agents reached production this quarter, through how many pipelines, and how many of those pipelines hold a credential that would still work tomorrow if it were dumped from a runner today? The honest answer has two numbers in it, and the second one was never in the plan. **If you are the platform or security engineer who runs the cluster**, your question is about one chart. If the next release of this agent dropped its NetworkPolicy, mounted the service account token and changed its system prompt, which of the three would the cluster refuse, which would a reviewer catch, and which would be live before anyone noticed? “The pipeline is automated” answers none of them. **If you built the agent**, your question is about what you put in the chart. Where is the model key, which endpoints and tools did you declare, and which of those can change without a pull request with your name on it? The value you pasted into a ConfigMap to get the demo working is the one that ships. If any of those answers starts with “we would need to check,” the check is what to build. In February and March the pipeline was the way in. Built properly, it is also the one place to say no before the agent ever runs. *Lynx is Tigera’s security and governance platform for AI agents on Kubernetes: identity, policy, detection, and audit for every agent in your cluster. Read [How Lynx Works](https://www.tigera.io/blog/how-lynx-works-a-technical-walkthrough/) or request early access at [tigera.io/demo/?product=lynx](https://www.tigera.io/demo/?product=lynx).* [Best Practices](https://www.tigera.io/tags/best-practices/)[AI Agent Security](https://www.tigera.io/tags/ai-agent-security/)[How-To](https://www.tigera.io/tags/how-to/) ## Related posts [![Gemini Never Left the Sandbox. The Sandbox Had a Door.](https://www.tigera.io/app/uploads/2026/10/gemini-featured.png)](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) #### [Gemini Never Left the Sandbox. The Sandbox Had a Door.](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 7, 2026 In short, in May 2026 a Gemini model under evaluation by the AI security firm Irregular reached the systems of three real companies, and the incident has been reported as a breakout. By Google’s own... [Read more](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) [![EU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clock](https://www.tigera.io/app/uploads/2026/10/EU-Cyber-Resilience-Act-AI-Agents-featured.png)](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) #### [EU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clock](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 5, 2026 In short, the EU Cyber Resilience Act (CRA) puts binding cybersecurity requirements on any software sold as a product in the EU, and it does not carve out AI agents. Since 11th September 2026, any... [Read more](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) [![HIPAA Wasn’t Written for AI Agents. It Applies to Them Anyway](https://www.tigera.io/app/uploads/2026/09/HIPAA-Wasnt-Written-for-AI-Agents-featured.png)](https://www.tigera.io/blog/hipaa-wasnt-written-for-ai-agents-it-applies-to-them-anyway/) #### [HIPAA Wasn’t Written for AI Agents. It Applies to Them Anyway](https://www.tigera.io/blog/hipaa-wasnt-written-for-ai-agents-it-applies-to-them-anyway/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 2, 2026 In short, healthcare is adopting AI agents faster than almost any other industry. More than 85% of Epic’s customers already use Epic AI, Epic’s Agent Factory will let every health system build agents of its... [Read more](https://www.tigera.io/blog/hipaa-wasnt-written-for-ai-agents-it-applies-to-them-anyway/)