Share this post
The volume of AI-generated code landing on enterprise infrastructure is not going to slow down. The people building it are not platform engineers, they are not checking their dependencies against CVE databases, and they are not thinking about what the container image their AI tool chose actually contains. The governance model that protects your organization has to work without depending on those people to do any of that correctly... which means it has to be layered, automatic, and operating independently of the business builder's actions.
Portainer Run's governance story runs across three layers: the repository, the runtime, and the access model. Each one catches something the others miss.
The repository layer: what happens to the code after it lands
When a business builder submits their files through Portainer Run, those files are committed to a sanctioned Git repository your platform team designates at setup time. That commit happens before anything is deployed, which means the repository is the permanent, auditable record of what entered your infrastructure and when.
GitHub Dependabot scans that repository continuously, comparing every dependency manifest (package.json, requirements.txt, and their equivalents across languages) against the GitHub Advisory Database. When it finds a match, it raises a vulnerability alert against the specific file and the specific package, with severity classification and a direct link to the CVE. In our own testing environment, an expense tracker application deployed through Portainer Run triggered a moderate-severity Dependabot alert for the uuid package (a missing buffer bounds check present in versions 3, 5, and 6) within minutes of the commit landing. The business builder who deployed the app did not need to do anything, and the alert was waiting for the repository administrator before the next daily stand-up.
Dependabot can be configured to auto-generate a pull request updating the vulnerable dependency to a patched version. When that PR merges, Portainer's GitOps sync picks up the change and redeploys. The whole remediation cycle completes without a platform team ticket and without the business builder understanding what a CVE is.
For organizations running GitHub at the enterprise or organization level, GitHub Advanced Security extends this to static code analysis using CodeQL (GitHub's own query engine for code-level vulnerability patterns) and compatible third-party SAST integrations. Code scanning runs on every push to the sanctioned repository and can be configured to block merges when findings exceed a severity threshold. This sits above the dependency layer and catches logic-level vulnerabilities that a clean dependency tree will not surface.
The runtime layer: what happens to the container image in your cluster
Dependency scanning covers the application code. It does not cover the operating system packages, runtime binaries, and system libraries inside the container image the application runs in. A base image that was clean at build time can have a CVE published against it 30 days later, and a dependency scan will not surface that.
The Trivy operator from Aqua Security addresses this inside your Kubernetes cluster. Deployed as a Kubernetes operator (available via Helm), Trivy runs in two modes simultaneously. As an admission controller, it scans every container image at the point of scheduling and can deny admission if the image exceeds your configured severity threshold, meaning the workload never starts. On a configurable schedule, it re-scans every running workload against an updated vulnerability database, so a container that was clean on day one and has a published CVE on day 31 surfaces as an alert without waiting for a new deploy cycle.
The scan results are stored as Kubernetes custom resources inside your cluster (VulnerabilityReport objects, visible through standard cluster tooling and through the Portainer environment view). Your platform team sees the runtime security posture of every deployed workload in one place, without querying containers individually.
The access layer: what the business builder can and cannot do
The third layer operates at the point where the business builder tries to act. Every user in Portainer Run authenticates with their Portainer credentials and operates under the RBAC role they have been assigned by your administrator. They do not receive cluster credentials or a kubeconfig file. They cannot interact with the Kubernetes API directly.
Portainer RBAC is scoped to environments (your cluster endpoints) and to project spaces (namespaces within those clusters). A user who has not been granted access to an environment does not see it. A user who has access to an environment but not deployment permissions in a specific namespace cannot deploy there, and the error they receive at the deploy step is explicit: it tells them which namespace they cannot access and instructs them to select a different one or contact their administrator. No deployment is attempted, no manifest is generated, and nothing is committed to Git.
Your administrator sets this scoping once. Every deployment that user makes, across every app they build with every AI tool they use, inherits those constraints automatically.
Three controls, set once, operating across every app
The business builder does not interact with any of these layers. They do not know Dependabot is running. They do not know Trivy is scanning their container. They do not know what Kubernetes RBAC is. The governance is somebody else's job, and it runs whether or not the person deploying understands it exists. That is the point. Your platform team sets the rules once, and every app that lands through Portainer Run lives inside them.
.png)
