A New Category of Infrastructure Is Born
Last week at GTC 2026, NVIDIA launched OpenShell — an open-source sandboxed runtime for autonomous AI agents. The concept is straightforward: wrap AI agents like Claude Code, Codex, and OpenCode in kernel-level isolation, governed by declarative YAML security policies.
The policies look like this:
version: 1
filesystem_policy:
read_only: [/usr, /lib, /proc, /etc]
read_write: [/sandbox, /tmp]
process:
run_as_user: sandbox
run_as_group: sandbox
network_policies:
github_api:
endpoints:
- host: api.github.com
port: 443
protocol: rest
access: read-only
enforcement: enforce
If you’ve worked with Terraform, Kubernetes manifests, or Dockerfiles, this looks familiar. Because it is. This is Infrastructure as Code — for AI agents.
And just like every other IaC format before it, these files will be written by developers, committed to repositories, reviewed in pull requests, and deployed through CI/CD pipelines. They define security boundaries for systems that can autonomously read files, call APIs, execute code, and make decisions.
The stakes, however, are different. A misconfigured Terraform security group exposes a port. A misconfigured agent policy gives an autonomous system unrestricted access to your entire environment.
The Runtime Security Gold Rush
The industry response has been swift — and predictably focused on runtime.
Within days of the OpenShell announcement, CrowdStrike unveiled a Secure-by-Design AI Blueprint that embeds Falcon directly into the OpenShell runtime, monitoring every prompt, response, and agent action in real time. Trend Micro announced TrendAI integration with OpenShell, adding runtime enforcement and behavioral monitoring. The message is clear: the biggest names in security see autonomous AI agents as the next critical attack surface.
They’re right. But they’re only solving half the problem.
Runtime Enforcement Is Necessary — But Not Sufficient
We’ve been here before. When cloud infrastructure exploded a decade ago, the first instinct was runtime monitoring: detect misconfigurations after deployment, alert on anomalous behavior, respond to incidents in production. It worked — until it didn’t. Organizations learned the hard way that catching an open S3 bucket in production means the data has already been exposed.
The industry converged on a principle: shift left. Don’t wait for a firewall to catch a misconfigured security group. Catch it in the pull request. Scan the Terraform before it’s applied. Validate the Kubernetes manifest before it’s deployed.
AI agent infrastructure demands the same approach.
Consider what a misconfigured OpenShell policy can look like:
| Misconfiguration | Risk |
| read_write: [/] | Agent has unrestricted filesystem access — can read secrets, SSH keys, credentials |
| No network_policies section | Agent can exfiltrate data to any external endpoint |
| run_as_user: root | Agent runs with full system privileges — privilege escalation by design |
| enforcement: monitor | Policy violations are logged but not blocked — false sense of security |
| host: “*” in network rules | Wildcard allows outbound connections to attacker-controlled servers |
| Missing inference policy | Agent can route model calls to any backend — data leakage vector |
Every one of these misconfigurations would be committed to a repository, pass through a CI/CD pipeline, and reach production — unless someone is scanning the code.
Runtime enforcement catches the exploit. Static analysis catches the vulnerability.
It’s Not Just OpenShell
OpenShell is the most structured example, but it’s the tip of the iceberg. A new category of Agent Infrastructure as Code is emerging across the ecosystem:
- OpenShell policies — filesystem, network, process, and inference controls in YAML
- MCP server configurations — define which external tools and APIs agents can access
- Claude Code permissions — settings.json and CLAUDE.md files that scope agent capabilities
- Codex sandboxing rules — network and execution constraints for autonomous coding agents
- Agent tool definitions — declarative configs specifying what actions agents can take
- Agentic workflow orchestration files — multi-agent pipelines with trust boundaries and delegation rules
All of these are declarative. All are committed to version control. All define security boundaries for autonomous systems. And all are currently invisible to traditional application security tooling.
The OWASP Agentic Top 10 Confirms the Gap
In late 2025, OWASP released the Top 10 for Agentic Applications — the first industry-standard risk framework for autonomous AI systems. The list reads like a roadmap of what goes wrong when agent infrastructure isn’t secured at the code level:
- ASI02: Tool Misuse and Exploitation — agents use legitimate tools unsafely due to ambiguous or overly permissive configurations
- ASI03: Identity and Privilege Abuse — high-privilege credentials inherited by agents without proper scoping
- ASI04: Agentic Supply Chain Vulnerabilities — compromised tools, plugins, and MCP servers fetched dynamically at runtime
- ASI05: Unexpected Code Execution — agents generate and run code without proper sandboxing
Each of these risks has a configuration-level root cause. Overprivileged agent policies. Unrestricted tool access definitions. Unvalidated supply chain references. These aren’t runtime anomalies — they’re misconfigurations that exist in code, waiting to be deployed.
According to a Dark Reading poll, 48% of cybersecurity professionals now identify agentic AI as the number-one attack vector heading into 2026 — outranking deepfakes, ransomware, and supply chain compromise. Yet only 21% of executives report complete visibility into agent permissions, tool usage, or data access patterns.
The visibility gap isn’t at runtime. It’s in the repository.
What Deterministic Scanning Looks Like for Agent Infrastructure
At Cycode, we’ve spent years building the engine that scans infrastructure as code — Terraform, CloudFormation, Kubernetes, Dockerfiles, Helm charts, CI/CD pipelines — with deterministic rules that catch misconfigurations before deployment. The same approach applies directly to this new category of agent infrastructure.
Here’s what deterministic IaC and SAST scanning for AI agent configurations means in practice:
Policy misconfiguration detection — static rules that flag overly permissive filesystem access, missing network restrictions, root execution, monitor-only enforcement, and wildcard patterns in agent policy files. The same class of checks we run on Terraform security groups, applied to OpenShell policies.
Supply chain validation — when agent configs reference external sandbox images, MCP servers, plugins, or tool registries, validate that references are pinned, signed, and sourced from trusted origins. This is SCA for the agentic supply chain.
Secrets in agent configs — agent policy files and MCP configs frequently contain API keys, tokens, and credentials. The same secrets detection that catches AWS keys in Terraform catches Anthropic API keys in agent configurations.
Drift and compliance — compare committed policy files against organizational baselines. Ensure every agent deployed in production has a policy that meets minimum security requirements — just as we ensure every Kubernetes deployment has resource limits and security contexts.
CI/CD gate enforcement — block merges that introduce agent configurations without security policies, or with policies that violate organizational standards. Shift the enforcement left from runtime to the pull request.
This isn’t AI-powered scanning. It’s deterministic, rule-based static analysis — the same proven approach that secures cloud infrastructure today, applied to the infrastructure that governs autonomous AI systems.
The ADLC Needs the Same Rigor as the SDLC
The industry is coining a new term: the AI Development Lifecycle (ADLC). As organizations move from building software to building autonomous agents, the security practices that protect the SDLC must extend to cover this new lifecycle.
Runtime security vendors — CrowdStrike, Trend Micro, and others — are building the production monitoring layer. That’s critical work. But the lesson of the last decade of cloud security is unambiguous: you cannot secure infrastructure only at runtime.
The attack surface starts in the repository. The policy is written in code. The misconfiguration is introduced in a commit. The vulnerability passes through a CI/CD pipeline.
That’s where it needs to be caught.
Cycode’s Complete ASPM platform provides native IaC scanning, SAST, SCA, secrets detection, and CI/CD security across the software development lifecycle. As AI agent infrastructure becomes code, Cycode extends the same deterministic security analysis to the configurations that govern autonomous systems.
