1 Key Risks
The most critical security risks an operator inherits when deploying this agent in its documented default configuration. Komodor's default configuration combines cluster-wide Kubernetes authority with autonomous remediation and absent input guardrails, creating an exposure surface where every scored defense depends on optional operator hardening.
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. Komodor's scores reflect an architecture where cluster-wide Kubernetes authority and autonomous remediation create high blast radius, a broad attack surface spans external data ingestion, persistent memory, and inter-agent protocols, and defense controls remain largely optional.
Komodor lands in the Exposed Giants quadrant because its attack surface and blast radius both score above the midpoint thresholds while its defense controls provide minimal friction against exploitation of the agent's extensive cluster authority. The pattern reflects a platform-operations architecture where the agent's value proposition — autonomous troubleshooting and remediation across entire Kubernetes clusters — necessarily requires broad permissions, but where the vendor has not yet matched that operational scope with proportionally strong default defenses. Operators adopt a runtime whose risk ceiling is set by Kubernetes RBAC grants rather than by AI-specific containment.
The per-metric breakdown anchors each score to documented evidence. Blast radius is driven by independent RBAC permission analysis confirming cluster-wide secret access and by vendor documentation of autonomous Helm operations. Attack surface evidence spans vendor architecture pages documenting multi-agent orchestration, external data ingestion channels, and MCP integration. Defense controls evidence relies primarily on vendor security documentation and the absence of independently verified AI-specific protections.
| Metric | Score | Comments |
|---|---|---|
| AIRQ Score | 6.72 | The composite score captures an agent whose Kubernetes cluster authority produces high blast radius, whose multi-channel data ingestion and autonomous planning create a broad attack surface, and whose defense controls remain largely dependent on optional operator configuration. Independent RBAC permission analysis and vulnerability research provide the strongest evidence anchors, while vendor documentation carries the bulk of defense-posture claims without independent verification. |
| Blast Radius | 7.88 / 10 | Blast radius is anchored by independent RBAC Atlas analysis documenting 112 Critical-risk permissions including cluster-wide secret access at the maximum tier, and by vendor documentation of autonomous Helm operations, workload management, and RBAC binding creation across all namespaces. Independent research confirms that the agent's nodes/proxy GET permissions enable remote code execution via WebSocket exec to any pod in the cluster [1][2]. |
| Attack Surface | 5.3 / 10 | The attack surface score reflects broad exposure across external data ingestion, persistent memory stores, autonomous planning, multi-agent orchestration, and inter-agent protocols, where all three untrusted-input conditions are present. Vendor documentation confirms that Kubernetes cluster data, customer knowledge bases, and MCP server outputs all enter the reasoning loop, while independent research demonstrates exploitation vectors through the agent's RBAC permissions. Operator-controlled input channels prevent the surface from reaching the maximum tier. |
| Defense Controls | 5 / 15 | Defense controls reflect a posture where monitoring carries the highest score through SOC 2 Type 2 audit logging and external monitoring integration, while input guardrails have no documented implementation. Execution isolation, action controls, and output guardrails each offer specific opt-in mechanisms — VPC-based inference isolation, human-in-the-loop approval gates, and configurable data redaction — that are not enabled by default [4]. |
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. Komodor's attack surface spans all ten measured dimensions with six scoring at the architectural maximum for the documented default, driven by multi-channel data ingestion, persistent cross-session memory, autonomous planning, and inter-agent communication protocols.
The attack surface presents a uniformly elevated pattern across six of ten dimensions, with no single dominant channel but rather a broad front where external data, memory, planning, tool execution, orchestration, and inter-agent communication all score at the same tier. This pattern reflects an architecture where the AI reasoning loop draws from multiple independent input sources — Kubernetes telemetry, customer documentation, external MCP servers, and peer agents — creating parallel injection vectors rather than a single filtering point an operator could gate.
Evidence for the elevated surfaces comes primarily from vendor architecture documentation and independent research. The vendor's own product pages document multi-source data ingestion, persistent memory that accumulates remediation patterns without integrity checks, autonomous multi-step planning, and inter-agent communication via both MCP and A2A protocols. Independent vulnerability research establishes that the agent's Kubernetes RBAC permissions create execution vectors beyond what the AI reasoning loop itself exposes, anchoring the tool execution surface to a demonstrated exploitation path [1].
| Surface | Score | Comments |
|---|---|---|
| User Input | 2 / 4 | Operators interact through the web UI, KlaudiaChat, REST API with key authentication, and kubectl plugin. Input channels are authenticated and operator-controlled rather than public-facing, limiting direct injection to scenarios where the operator account is compromised or the operator unknowingly pastes adversarial content. The trust boundary sits at operator identity rather than at open internet exposure [5]. |
| External Data | 3 / 4 | Klaudia ingests Kubernetes cluster data including logs, events, configurations, and metrics alongside customer Confluence pages, runbooks, and MCP server outputs into the AI reasoning loop. Any of these sources can carry attacker-controlled content — poisoned container logs, crafted Kubernetes events, adversarial ConfigMap values — that reaches the model without documented input filtering [6]. |
| Memory | 3 / 4 | Self-Learning Memory accumulates root causes and remediation patterns automatically across sessions without documented integrity verification or poisoning detection. The Blueprint stores architectural truth and the Knowledge Base indexes customer documents via semantic search, creating persistent vectors where adversarial content planted in one investigation poisons future reasoning across all sessions [10]. |
| Reasoning | 2 / 4 | RAG-based root cause analysis correlates logs, events, configurations, metrics, and deployment history through the AI engine on vendor-managed AWS Bedrock. No documented adversarial-robustness testing or reasoning-chain integrity checks exist publicly, leaving the model's susceptibility to indirect prompt injection through the data it correlates unverified [5]. |
| Planning | 3 / 4 | Autonomous self-healing decomposes remediation into multi-step plans spanning pod restarts, config reverts, node cordons, and release rollbacks. Human-in-the-loop approval is optional and not enabled by default, allowing the planning loop to select and execute cluster-wide operations without operator checkpoint [8]. |
| Tool Execution | 3 / 4 | The agent executes pod shell access, YAML editing, resource modification, Helm operations, and RBAC management with cluster-wide authority. Independent research has demonstrated that the Helm chart's nodes/proxy GET grants allow arbitrary command execution across every pod through WebSocket channels, extending the tool surface beyond the agent's own documented invocations [11][1]. |
| Orchestration | 3 / 4 | Hundreds of specialized workflow agents and subject matter expert agents run continuously, coordinating detection, investigation, and remediation phases with event-driven orchestration and parallel execution. The multi-agent architecture amplifies the surface because a compromised reasoning chain in one agent propagates through the orchestration layer to others [6]. |
| Inter-Agent | 3 / 4 | Klaudia supports MCP integration with configurable authentication including an unauthenticated mode and the A2A protocol for agent-to-agent communication. External agents can invoke Klaudia as a subagent, creating inbound task injection vectors where adversarial payloads from a compromised peer agent reach the cluster-privileged reasoning loop [10][9]. |
| Output Processing | 2 / 4 | Investigation results and remediation actions are sent to the vendor cloud, Slack notifications, and Datadog integrations. No documented DLP or output sanitization exists for AI-generated content before it reaches external consumers, leaving a channel where adversarially steered outputs could exfiltrate cluster data through standard integration pathways [4]. |
| Configuration | 2 / 4 | The Helm chart provides capabilities flags for actions, custom resource actions, Helm operations, and RBAC management. Defaults ship with all capabilities enabled and allowReadAll set to true, requiring operators to restrict rather than enable permissions — an opt-out security model where the default attack surface is the maximum the chart supports [7]. |
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. Komodor exhibits all three of these conditions: its in-cluster agent ingests attacker-reachable Kubernetes data, holds cluster-wide RBAC permissions including secret access, and communicates outbound to the vendor cloud, external integrations, and MCP servers.
Komodor exhibits all three of these conditions in its documented default configuration:
- Untrusted input — Kubernetes logs, events, configurations, and external knowledge base content enter the AI reasoning loop without documented input validation — an attacker who controls a container's stdout or a ConfigMap value can inject adversarial payloads that reach the model [6].
- Sensitive data — The in-cluster agent holds RBAC permissions to read, create, update, and delete secrets across all namespaces, and the Blueprint and Knowledge Base store service topology and customer documentation — the agent operates with access to every sensitive resource in the cluster [4].
- External egress — The agent communicates outbound to the vendor cloud API, transmits data to Slack and Datadog integrations, connects to external MCP servers, and runs AI analysis on AWS Bedrock — every output channel constitutes an exfiltration path for cluster data steered by adversarial input [4].
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. Komodor's blast radius is dominated by credential access at the maximum tier, reflecting cluster-wide RBAC permissions that grant the agent authority over every secret, workload, and deployment in the Kubernetes environment.
The blast radius pattern is uniformly high across all six factors, with credential access at the maximum tier and the remaining five factors one tier below. This reflects a platform-operations architecture where the Helm chart grants cluster-wide authority by default — compromising the agent's reasoning loop grants an attacker the same operational scope as a cluster administrator, with the added capability of autonomous execution without human approval gates.
Evidence for the blast radius scores spans independent RBAC analysis, vendor documentation, and published vulnerability research. The RBAC Atlas analysis provides the primary anchor for credential access, documenting the full permission set. Vendor product pages and the Helm chart confirm autonomous Helm operations, pod shell access, and RBAC binding management. Independent research establishes the exploitation path from RBAC permissions to cluster-wide code execution [1][2].
| Factor | Score | Comments |
|---|---|---|
| Code execution | 3 / 4 | The agent provides pod shell access and YAML editing across all namespaces. Independent research demonstrates that the Helm chart's RBAC grants for nodes/proxy convert nominally read-only access into arbitrary command execution across every pod in the cluster [1][11]. |
| File system access | 3 / 4 | Cluster-wide read access to all resources including ConfigMaps, secrets, and custom resources with create, update, and delete permissions. The Helm chart defaults ship with allowReadAll and custom resource actions enabled, granting the agent write authority over every configuration object in the cluster [7][11]. |
| Network access | 3 / 4 | The agent maintains persistent outbound connections to the vendor cloud and integrations with Slack, Datadog, and external MCP servers. Port-forwarding capability creates additional network channels to individual pods, meaning a compromised reasoning loop gains both egress to the internet and lateral reach into any pod's network namespace [4]. |
| Credential access | 4 / 4 | Vendor security documentation confirms the agent accesses cluster resources, and independent analysis documents 112 Critical-risk permissions including core/secrets with wildcard verbs across all namespaces. The agent can create and manage RBAC bindings, enabling privilege escalation paths [2][4]. |
| Autonomous action | 3 / 4 | Self-healing operates autonomously without mandatory human approval, performing pod lifecycle management, infrastructure remediation, and Helm release operations across the cluster. Continuous detection agents run permanently, acting on findings without per-action operator confirmation [8]. |
| Deployment access | 3 / 4 | The Helm chart defaults enable install, upgrade, rollback, and delete operations on Helm releases with readonly set to false. The agent manages deployment configurations and resource specifications, holding the authority to modify the operational state of any workload in the cluster [11][7]. |
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. Komodor's defense controls rely almost entirely on optional operator hardening, with monitoring as the only component carrying documented implementation above the minimal tier while input guardrails remain entirely absent.
The defense controls pattern shows a single elevated bar at monitoring, with input guardrails at zero and the three middle components at the minimal tier. This means the runtime provides almost nothing to detect, contain, or report on AI-specific threats by default — operational audit logging exists through SOC 2 compliance, but every other defense layer depends on the operator explicitly enabling and configuring it through Helm chart values and policy guardrail settings.
Evidence for the defense posture comes primarily from vendor security documentation and the Helm chart. SOC 2 Type 2 compliance anchors the monitoring score, while the absence of documented input validation, the optional nature of human-in-the-loop approval, and the configurable-but-not-default data redaction establish the lower scores. Opt-in mitigations documented in vendor materials are not counted toward the default-posture score — they reappear as hardening tips that an operator can layer on top of the default posture.
| Component | Score | Comments |
|---|---|---|
| Input Guardrails | 0 / 3 | No documented prompt shield, ML-based injection detection, or input validation pipeline for the AI reasoning loop. Kubernetes cluster data, customer knowledge base content, and MCP server outputs enter the model without any disclosed filtering mechanism, leaving the broadest ingestion surface unprotected [5]. |
| Execution Isolation | 1 / 3 | AI analysis runs in a vendor-managed VPC on AWS Bedrock, providing network-level isolation for model inference. However, the in-cluster agent operates as a standard Kubernetes pod with no documented container-level sandboxing, resource quotas, or privilege restrictions beyond default pod isolation [4]. |
| Action Controls | 1 / 3 | Human-in-the-loop approval is available but optional and not enabled by default. Policy guardrails allow teams to scope automation boundaries, but the default configuration ships with all action capabilities enabled including autonomous self-healing without per-action approval gates [8]. |
| Output Guardrails | 1 / 3 | Data redaction capabilities are configurable in the Helm chart but not enabled by default. No documented DLP, exfiltration blocking, or content inspection exists for AI-generated outputs before they reach the vendor cloud, Slack, Datadog, or MCP server integrations [4]. |
| Monitoring | 2 / 3 | SOC 2 Type 2 compliance implies structured audit logging, and every automated action is logged per vendor documentation. External monitoring integration provides event correlation. AI-specific anomaly detection and SIEM forwarding for reasoning-loop behaviors are not documented [4][13]. |
6 Hardening Tips
Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. Komodor's default posture requires active operator hardening across all five defense components, with the most impactful measures targeting RBAC scope reduction, mandatory approval gates, and input-channel isolation.
Input Guardrails
Input guardrails intercept adversarial content before it reaches the reasoning loop.
- Policy Establish a policy requiring all MCP integration connections to use authenticated modes — counters the inter-agent input vector where unauthenticated MCP servers can inject content into the reasoning loop.
- Configuration Configure the Helm chart to restrict monitored namespaces and resource types, reducing the volume of untrusted Kubernetes data entering the AI reasoning loop — counters the broad external data ingestion surface.
- Engineering Deploy a prompt-injection detection layer between the Kubernetes data pipeline and the AI engine — counters the absent input guardrails where no filtering exists for attacker-controlled cluster data.
Execution Isolation
Execution isolation contains what a compromised agent can do on the host.
- Policy Require Pod Security Standards at the restricted level for the agent namespace — addresses the missing container-level sandboxing by enforcing privilege constraints at the Kubernetes admission layer.
- Configuration Deploy the agent in a dedicated namespace with network policies restricting egress to approved endpoints only — counters the network access blast radius where the agent connects to multiple external services.
- Engineering Deploy agent containers with a gVisor or Kata Containers runtime class to provide kernel-level isolation between agent workloads and the host — counters the execution isolation gap where the agent runs as a standard pod.
Action Controls
Action controls govern which tools and actions the agent can invoke autonomously.
- Policy Enable mandatory human-in-the-loop approval for all remediation actions through policy guardrail configuration — counters the autonomous action blast radius where self-healing fires without per-action approval.
- Configuration Create scoped RBAC roles limiting the agent service account to specific namespaces and set capabilities.helm.readonly to true — counters credential and deployment access blast radius.
- Engineering Develop a Kubernetes admission controller that validates and constrains the agent's API requests at runtime — counters the action controls gap where no runtime enforcement layer exists beyond static RBAC.
Output Guardrails
Output guardrails inspect what the agent sends to other systems and users.
- Policy Establish a data classification policy for cluster resources and configure redaction patterns for secrets, tokens, and credentials in all agent outputs — counters absent output guardrails.
- Configuration Enable Helm chart data redaction capabilities and restrict integration outputs to summary-level information without raw log content — counters the output processing surface where sensitive data reaches external consumers.
- Engineering Deploy network-level DLP inspecting outbound traffic from the agent to external endpoints for sensitive data patterns — counters the external egress dimension where multiple channels can transmit cluster data.
Monitoring
Monitoring captures what the agent did and surfaces anomalies for review.
- Policy Forward agent audit logs to an organization SIEM with alerting rules for unusual remediation patterns and privilege escalation attempts — counters the monitoring gap for AI-specific anomaly detection.
- Configuration Implement Kubernetes audit logging capturing all API calls by the agent service account at the RequestResponse level — counters the blind spot where tool invocations are not independently auditable.
- Engineering Deploy Falco or similar runtime security tooling to detect unexpected system calls and network connections from the agent pods — adds runtime behavioral monitoring absent from the default deployment.
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
- Kubernetes RCE Via Nodes/Proxy GET Permission Independent security research explicitly names komodor-agent and k8s-watcher Helm charts as granting nodes/proxy GET and LIST permissions that enable cluster-wide RCE via WebSocket exec.
Selected Research
- RBAC Atlas Analysis of komodor-agent Independent RBAC permission analysis documenting 112 Critical-risk permissions for the komodor-agent service account including cluster-wide secret access.
- When Read-Only Is Not: K8s nodes/proxy GET to RCE Independent attack research from Horizon3.ai confirming the nodes/proxy RCE vector affecting monitoring agents including Komodor.
Vendor Documentation
- Komodor Enterprise Security Readiness Vendor security page covering SOC 2 Type 2, GDPR, AWS Bedrock, VPC isolation, audit logging, and data handling claims.
- Klaudia AI-Powered Troubleshooting Vendor product page describing RAG-based root cause analysis, KlaudiaChat, AWS Bedrock architecture, and compliance.
- Klaudia Agentic AI Architecture Vendor architecture page documenting hundreds of specialized agents, multi-layered investigation, and three data stores.
- komodor-agent Helm Chart Open-source Helm chart documenting default capabilities: actions, crActions, Helm read-write, RBAC, and allowReadAll.
- Autonomous Self-Healing Capabilities Vendor blog on autonomous remediation with optional human-in-the-loop, policy guardrails, and iterative learning.
- Klaudia MCP Integration Terraform provider docs for MCP integration showing connectivity modes and auth methods including unauthenticated.
- Multi-Agent AI SRE Architecture Vendor blog on multi-agent architecture with A2A protocol, Cisco JARVIS subagent, and three-tier memory.
- Kubernetes Operations and User Management Vendor page documenting RBAC, JIT permissions, audit log, and capabilities: revert, restart, cordon, pod shell.
- Komodor Privacy Policy Vendor privacy policy on data handling, EU Standard Contractual Clauses, and retention policies.
Other Sources
- Komodor Datadog Integration Third-party integration docs on event timeline, deployment tracking, and metric linking with Datadog.