Cast AI Agent Security Risks

Platform Operations Agents cast.ai Humble Providers
AI RISK QUADRANT POSITION DEFENSE CONTROLS (5) ATTACK SURFACE (4.8) EXPOSED GIANTS FORTIFIED LEADERS HUMBLE PROVIDERS TIGHT OPERATORS
AIRQ Score
4.3
High
Attack Surface
4.8
Medium
Blast Radius
5
High
Defense Controls
5
High
About The Agent

Cast AI is a cloud-hosted Kubernetes optimization platform that deploys agentic AI into operator clusters to autonomously detect performance issues, reason about remediation strategies, and execute multi-step recovery workflows across node scaling, workload rightsizing, container live migration, and security drift correction. The same service-account identity that collects cluster telemetry in read-only mode can be promoted to full automation authority over pods, nodes, and RBAC resources, with changes gated by configurable scaling policies rather than per-action approval prompts.

About the AI Risk Quadrant

Humble Providers placement reflects a moderate attack surface held below the upper bands by the absence of agent-specific demonstrated exploits, paired with a moderate blast radius constrained by opt-in automation gates and namespace-scoped defaults. Defense controls contribute meaningfully through configurable action approval and comprehensive audit logging, but the absence of input guardrails and output filtering on the AI decision layer prevents the agent from reaching the fortified band despite strong compliance certifications.

1 Key Risks

The most critical security risks an operator inherits when deploying this agent in its documented default configuration. Cast AI concentrates risk at the boundary between its AI decision engine and the Kubernetes control plane it manages, where broad infrastructure authority meets absent input and output filtering on the default configuration.

Key Input Risks
Untrusted Kubernetes cluster state including workload manifests, container registry metadata, and Git repository content reaches the AI reasoning engine without documented prompt-level filtering. No input guardrails exist to detect adversarial manipulation of cluster metadata that could steer agentic decisions. [5][10]
Key Execution Risks
The agent can modify any cluster resource when granted full automation authority — the cluster-controller receives a cluster-admin ClusterRoleBinding for self-management, and research demonstrates that platform agents with read-only node telemetry permissions can escalate to full pod command execution via WebSocket kubelet API abuse. [6][1][4]
Key Action Risks
Once Phase 2 automation is enabled, agentic runbooks execute multi-step remediation workflows autonomously on triggers without per-action operator approval, including node provisioning, pod eviction, and workload mutation. Agentic systems with unchecked permissions represent a recognized excessive agency pattern. [14][9][2]
Key Output Risks
Agent outputs flow to cloud provider APIs, Git repositories as pull requests, and the operator's Kubernetes cluster as live mutations without documented output-level DLP or exfiltration controls. Pre-analysis scrubbing operates on inputs, not on outbound payloads. [5][9]
Key Monitoring Risks
Audit logging covers platform operations with 90-day retention and API export, but no documented behavioral anomaly detection monitors the AI engine's own reasoning or flags agentic decisions that deviate from historical baselines. [7][13]

2 AIRQ Scores

The four headline scores quantify how exposed the agent is, how damaging a successful attack would be, and how much the agent’s own controls reduce that risk. Cast AI sits at the lower boundary of the Humble Providers quadrant with the trifecta floor active, reflecting meaningful infrastructure authority gated by configurable controls but lacking input and output filtering on the agentic reasoning layer.

AIRQ Metrics

The agent's attack surface sits just below the upper threshold with the trifecta floor active, blast radius at the midpoint reflecting scoped-but-real cluster authority, and defense contributing through action controls and monitoring while input and output guardrails remain absent.

Each axis captures a distinct dimension of operational risk: attack surface out of ten measures ingestion breadth, blast radius out of ten measures compromise reach, and defense out of fifteen measures vendor-implemented safeguards.

Metric Score Comments
AIRQ Score 4.3 Composite reflects meaningful infrastructure authority partially offset by configurable approval gates and audit logging.
Blast Radius 5 / 10 Scoped authority over Kubernetes resources including nodes, pods, and RBAC, bounded by opt-in Phase 2 enablement.
Attack Surface 4.8 / 10 Moderate ingestion surface elevated by the trifecta floor — cluster metadata, registry content, and Git repos all feed the reasoning loop.
Defense Controls 5 / 15 Action controls and audit logging provide meaningful gates while no validation layer exists between cluster metadata and the AI engine and no payload inspection operates on outbound mutations.

3 Attack Surface

Attack surfaces are the entry points and interaction patterns through which adversarial input can reach the agent’s reasoning loop and steer its behavior. The dominant exposures are the unfiltered cluster-state ingestion pipeline, the configurable-but-broad automation authority the AI engine inherits in Phase 2, and the absence of a prompt shield between external metadata and agentic reasoning.

Attack Surface Metrics

The agent's surfaces span validated API channels, cluster-state ingestion, agentic reasoning over workload metadata, and closed-loop automation within configurable RBAC boundaries. No surface reaches the upper bands given the absence of agent-specific demonstrated exploits; the trifecta floor applies because all three exfiltration preconditions are met on the documented default.

Each row scores the architectural exposure of one interaction pattern through which adversarial input could reach the agent's reasoning loop and steer its behavior.

Surface Score Comments
User Input 2 / 4 Multiple validated channels — SaaS console, REST API, Terraform provider — with schema validation but no prompt-level injection detection for the AI reasoning engine. [5][11]
External Data 2 / 4 Ingests Kubernetes cluster state, container registry metadata, and Git repository content from operator-specified sources. Environment variable values are scrubbed before analysis, but structural metadata including workload names, labels, annotations, and image references passes through to the reasoning engine without transformation. [10][5]
Memory 1 / 4 Operational telemetry retained for compliance rather than conversational persistence; no cross-session memory poisoning vector documented. [5]
Reasoning 2 / 4 Multi-step agentic reasoning constrained to declared task scope — detect, analyze, remediate, verify — with proprietary Cast AI Engine decisions not externally auditable. [9][14]
Planning 2 / 4 Agentic runbooks plan multi-step remediation autonomously but stage changes for human review via pull requests before applying code-level fixes. OWASP ASI10 is cited as class-level framing for the autonomous remediation pattern rather than agent-specific evidence. [9][3]
Tool Execution 2 / 4 Kubernetes API access scoped by Phase 2 RBAC grant; cluster-controller can receive cluster-admin binding for self-management operations. Research demonstrates that read-only K8s permissions can escalate to RCE via WebSocket exec. [6][8][1]
Orchestration 2 / 4 Closed-loop automation with scheduled scanning and event-driven triggers; operator configures which policies run autonomously versus requiring manual approval. [14][15]
Inter-Agent 1 / 4 Internal component orchestration only — Operator manages agent, controller, kvisor lifecycle with no external agent communication or marketplace integration. [8][18]
Output Processing 1 / 4 Outputs are structured API responses and Kubernetes mutations; no rich rendering, markdown exfiltration channels, or URL auto-fetch documented. [5]
Configuration 2 / 4 Configuration via validated Helm charts, Terraform provider, and console UI; no auto-loaded project-directory config files or community plugin marketplace. [8][6]

The Lethal Trifecta is triggered when an agent processes untrusted content, accesses private data, and communicates externally in the same session — the three conditions that turn an isolated prompt injection into full-chain exfiltration. Cast AI ingests third-party cluster metadata and registry content, reads workload configurations across the operator's infrastructure, and transmits telemetry plus mutations through cloud provider APIs and Git integrations in the absence of a system-level output filter.

Lethal Trifecta · Complete (3 of 3)

Cast AI exhibits all three of these conditions in its documented default configuration:

  • Untrusted input — Container registry images, Kubernetes manifests, and Git repository content authored by parties other than the operator feed the agentic reasoning loop. [5][10]
  • Sensitive data — The agent reads workload configurations, namespace topology, and resource utilization patterns across the operator's entire cluster fleet. [5][6]
  • External egress — Cluster snapshots transmit to the SaaS control plane, pull requests land in external Git repositories, and mutations flow to cloud provider APIs. [9][5]

4 Blast Radius

The blast radius is what an attacker who controls the agent can reach — which systems they touch, which credentials they read, and which actions they take without operator approval. Compromise of the Cast AI agent grants scoped but real authority over the operator's Kubernetes infrastructure — node lifecycle, workload placement, and resource allocation — bounded by the Phase 2 RBAC grant and configurable scaling policies.

Blast Radius Metrics

All six factors sit at the midpoint band, reflecting meaningful cluster authority that is architecturally scoped by namespace isolation and opt-in automation rather than unrestricted host access.

Each row ties the agent's documented capability to the Kubernetes resource scope and cloud-provider interaction surface it reaches on the opt-in Phase 2 configuration.

Factor Score Comments
Code execution 2 / 4 Cluster-controller executes Kubernetes API operations including pod eviction, node cordoning, and container live migration within the granted RBAC scope. Research confirms nodes/proxy GET permissions enable arbitrary command execution. [6][8][4]
File system access 2 / 4 Reads workload manifests and pod specifications via Kubernetes API; APA reads Dockerfiles and YAML from Git repositories for PR generation. [9][5]
Network access 2 / 4 Domain-restricted outbound to api.cast.ai SaaS control plane and cloud provider endpoints; no documented unrestricted outbound or SSRF exposure. [5][10]
Credential access 2 / 4 In Phase 1 read-only mode, holds Kubernetes service account tokens and Cast AI API keys; vendor states no access to Secrets or ConfigMaps; environment variables scrubbed before analysis. Phase 2 credential exposure depends on the specific ClusterRole granted by the operator. [5][10][17]
Autonomous action 2 / 4 Agentic runbooks fire autonomously on triggers once Phase 2 automation is enabled; operator configures scope through scaling policies and approval settings. [14][15]
Deployment access 2 / 4 Can provision and decommission cloud nodes, trigger workload scaling, and generate infrastructure-as-code PRs for operator review. [9][18]

5 Defense Controls

Defense controls are what the agent’s own architecture does to detect, contain, and report attacks before they reach the operator’s systems. The vendor publishes configurable action approval and comprehensive audit logging as default-on controls, while input filtering for the AI reasoning layer and output-level DLP remain undocumented and presumably absent.

Defense Controls Metrics

Higher scores indicate stronger vendor-implemented safeguards; the midpoint total reflects meaningful action-layer and observability controls offset by absent input and output filtering.

Each component scores what the vendor implements and documents at the default configuration, with opt-in hardening noted separately.

Component Score Comments
Input Guardrails 0 / 3 No documented prompt shield, injection detection, or content filtering between external cluster metadata and the AI reasoning engine. [5][10]
Execution Isolation 1 / 3 Phase 1 agent runs in dedicated namespace with scoped read-only RBAC; Phase 2 controller can escalate to cluster-admin for component management. Information security policy documents ISMS governance over deployment boundaries. [6][8][19]
Action Controls 2 / 3 Configurable scaling policies with automation toggle (manual vs automatic); APA generates PRs for human review; no documented single-step bypass. SOC 2 Type II examination scope covers the action-approval governance. [15][9][12]
Output Guardrails 0 / 3 Pre-analysis data scrubbing removes sensitive environment variables from inputs before the AI engine processes them; this is explicitly an input-side pre-processing step with no documented DLP, credential redaction, or exfiltration blocking on outbound payloads. [5][10]
Monitoring 2 / 3 Comprehensive operational audit logging with 90-day retention, API-accessible events, correlation IDs, and open-source exporter for external SIEM integration. Kvisor provides runtime anomaly detection via eBPF for customer workloads, though no equivalent behavioral layer monitors the AI engine's own decision patterns. [7][13]

6 Hardening Tips

Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. Operators should prioritize deploying input validation between cluster metadata and the AI reasoning engine, restricting the cluster-controller RBAC grant to the minimum required scope, and forwarding audit logs to a SIEM for behavioral anomaly detection.

Input Guardrails

Input guardrails intercept adversarial content before it reaches the reasoning loop.

Input Guardrails
  • Policy Require security review of all Kubernetes namespaces whose metadata feeds Cast AI before onboarding clusters — counters unfiltered cluster-state ingestion.
  • Configuration Restrict Cast AI agent namespace access to only the namespaces requiring optimization using Kubernetes NetworkPolicy — counters broad metadata ingestion surface.
  • Engineering Deploy a validating admission webhook that inspects and sanitizes workload labels and annotations before they reach the Cast AI data pipeline — counters absence of input guardrails.

Execution Isolation

Execution isolation contains what a compromised agent can do on the host.

Execution Isolation
  • Policy Mandate that Cast AI cluster-controller never receives cluster-admin and operates with a custom scoped ClusterRole — counters documented escalation path to broad privileges.
  • Configuration Enable Kubernetes NetworkPolicy restricting castai-agent namespace egress to only api.cast.ai on port 443 — counters potential lateral movement from compromised agent.
  • Engineering Deploy OPA Gatekeeper or Kyverno policies that block RBAC escalation requests from Cast AI service accounts beyond the documented minimum — counters cluster-admin binding path.

Action Controls

Action controls govern which tools and actions the agent can invoke autonomously.

Action Controls
  • Policy Require manual approval mode on all scaling policies for production namespaces — counters autonomous action without per-change operator review.
  • Configuration Set all scaling policies to deferred apply type with manual optimization toggled off for critical workloads — counters immediate autonomous modifications.
  • Engineering Integrate Cast AI audit events with a GitOps reconciliation loop that reverts unapproved mutations within minutes — counters autonomous changes that bypass PR review.

Output Guardrails

Output guardrails inspect what the agent sends to other systems and users.

Output Guardrails
  • Policy Require all APA-generated pull requests to pass a second security-focused code review before merge — counters unfiltered output reaching production infrastructure.
  • Configuration Configure branch protection rules requiring approval from a security team member on all repositories where APA generates PRs — counters direct-to-main remediation paths.
  • Engineering Build a post-mutation validator that compares Cast AI cluster changes against an allowlist of expected operations and alerts on deviations — counters absence of output-level DLP.

Monitoring

Monitoring captures what the agent did and surfaces anomalies for review.

Monitoring
  • Policy Require Cast AI audit logs to be forwarded to the organization SIEM with retention exceeding the 90-day console default — counters limited in-console retention window.
  • Configuration Enable the Cast AI audit log exporter with real-time streaming to your SIEM and configure alerting rules for unusual scaling or RBAC operations — counters passive monitoring posture.
  • Engineering Build behavioral anomaly detection rules that flag Cast AI agentic decisions deviating from historical baselines for the same workload class — counters absence of AI-layer behavioral monitoring. [13][16]

7 References

The evidence base behind every score and finding in the profile, grouped by source type so the reader can verify any claim. Numbers in brackets throughout the report (e.g. [7, 13]) refer to entries below, listed in citation order.

Selected Vulnerabilities

  1. Kubernetes nodes/proxy GET to RCE Horizon3.ai demonstrates that service accounts with nodes/proxy GET can execute arbitrary commands in any pod via WebSocket kubelet API abuse, relevant to platform agents with broad Kubernetes RBAC grants.

Selected Research

  1. OWASP LLM06 Excessive Agency OWASP framework guidance on agentic AI systems with unchecked permissions taking damaging actions in response to manipulated outputs, applicable to Kubernetes platform agents.
  2. OWASP Agentic Security Initiative Top 10 OWASP ASI Top 10 including ASI10 Rogue Agents framework for autonomous AI systems that deviate from authorized scope, applicable to closed-loop Kubernetes automation.
  3. Kubernetes nodes/proxy RCE original disclosure Graham Helton original research reported to Kubernetes Security Team demonstrating how read-only node telemetry RBAC permissions enable arbitrary command execution across cluster pods.

Vendor Documentation

  1. Cast AI Data Collection and Storage Vendor documentation of data handling architecture, retention policies, certifications including ISO 27001 and SOC 2 Type II, and security controls including pre-analysis environment variable scrubbing.
  2. Cast AI Kubernetes Permissions Vendor documentation of Phase 1 read-only and Phase 2 extended RBAC permissions including cluster-controller ClusterRoleBinding to cluster-admin for component management.
  3. Cast AI Audit Log Vendor documentation of audit logging capability with 90-day retention, event categories, filtering, and open-source exporter for external SIEM integration.
  4. Cast AI Operator Vendor documentation of the Cast AI Operator component lifecycle management, permission structure, and self-update capabilities for in-cluster agent components.
  5. Cast AI APA Overview Vendor documentation of Application Performance Automation with agentic AI runbooks that detect issues, plan remediation, and generate pull requests for operator review.
  6. Cast AI Read-Only Agent Architecture Vendor blog describing least-privilege design of the read-only agent including no secrets access, environment variable scrubbing, and limited metadata collection scope.
  7. Cast AI RBAC Vendor documentation of platform RBAC with Owner, Member, Analyst, and Viewer roles scoped to organization or individual cluster level.
  8. Cast AI SOC 2 Type II Compliance Vendor announcement of independent SOC 2 Type II examination covering AICPA Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy.
  9. Kvisor Security Agent Overview Vendor documentation of Kvisor open-source eBPF security agent providing runtime anomaly detection, vulnerability scanning, and CIS benchmark compliance checking.
  10. Cast AI Agentic Runbooks Vendor description of closed-loop agentic automation that observes cluster state, reasons about remediation, executes multi-step recovery, and verifies outcomes autonomously.
  11. Cast AI Scaling Policies Vendor documentation of configurable scaling policies with automation toggle, manual versus automatic approval modes, and assignment rules for workload optimization.

Other Sources

  1. Cast AI Kvisor GitHub Repository Open-source Go and C repository for the Cast AI Kubernetes security agent with Apache 2.0 license, 247 releases, and 30 contributors providing runtime scanning and vulnerability detection.
  2. Cast AI K8s Agent GitHub Repository Open-source repository for the Cast AI Kubernetes agent component that connects clusters to the SaaS platform for monitoring and optimization data collection.
  3. Cast AI Hosted Components Architecture Vendor documentation of the full in-cluster component architecture including Phase 1 monitoring and Phase 2 automation components with their respective responsibilities.
  4. Cast AI Information Security Policy Vendor information security policy documenting ISMS governance, ISO 27001 certification, SOC 2 criteria mapping, annual policy review, and security officer responsibilities.