What is the difference between a cloud-native agent harness and a cloud-hosted one?

A cloud-hosted harness simply runs in the cloud, while a cloud-native harness is designed around Kubernetes primitives from the start. The difference is whether isolation, workload identity, scheduling, and policy enforcement are built into the operating model or added later as wrappers.

Why This Matters for Security Teams

The distinction affects how much trust is embedded in the platform itself. A cloud-hosted harness may still be flexible, but it often inherits isolation, identity, scheduling, and policy from surrounding infrastructure. A cloud-native harness treats those as first-class design inputs, which changes how teams think about tenancy boundaries, blast radius, and enforcement consistency when agents begin acting on real systems.

That matters because agentic systems tend to accumulate privilege quickly if the harness is treated as “just another app.” When identity and policy are bolted on later, teams usually discover gaps at the exact point they need stronger control, not during initial deployment. The operating model determines whether the harness can constrain tools, workloads, and execution contexts from the start or only approximate that control after the fact. In practice, many security teams discover the difference only after an agent has already been allowed to act beyond the environment they thought was being enforced.

How It Works in Practice

A cloud-hosted harness is defined by location, not by design discipline. It may run in a cloud account, on a VM, or inside a managed service, but it can still depend on external wrappers for isolation and access control. A cloud-native harness is built around the cloud control plane itself, typically using Kubernetes primitives, service-to-service policy, workload identity, and declarative deployment patterns so that execution, networking, and authorization are governed as part of the runtime model.

That difference shows up in operational controls:

Isolation: Cloud-native designs can separate agent workloads by namespace, node pool, or cluster boundary, while cloud-hosted setups may rely on host or account-level separation.
Identity: Cloud-native harnesses usually assign workload identity to the agent runtime, which makes authorization more granular than static shared credentials.
Scheduling: Native harnesses can constrain where an agent runs and what it can touch; hosted harnesses often treat placement as an infrastructure detail rather than a security control.
Policy enforcement: Native harnesses can express admission, egress, and execution policy in the platform layer, instead of wrapping those decisions around the application.

For teams evaluating this distinction, the key question is not whether the harness is “in the cloud” but whether the cloud platform is part of the security model or merely the hosting location. The 2026 Infrastructure Identity Survey found that systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, which underscores why runtime privilege boundaries matter when agents can act autonomously. These controls tend to break down when a cloud-native label is used for software that still depends on static credentials and manual wrappers for enforcement.

Common Variations and Edge Cases

Tighter harness design often increases platform overhead, so teams have to balance security consistency against deployment complexity and Kubernetes maturity. A “cloud-native” label can also be overstated, because some products use Kubernetes for orchestration but still depend on external secret stores, shared credentials, or app-level policy code for the real control plane.

There is also an important distinction between portability and security architecture. A harness can be cloud-portable without being cloud-native, and it can be cloud-native without being deeply portable across providers. For security teams, the practical issue is whether identity, isolation, and policy remain intact when the agent scales, redeploys, or spans environments. Current guidance suggests treating any system that lacks workload identity and platform-enforced policy as hosted infrastructure, even if it runs inside Kubernetes.

Edge cases usually appear in hybrid deployments, where an agent runs in a cloud-managed environment but still calls back to external services or shared control planes. In those cases, the harness may look native from the outside while the trust model remains partially inherited from the surrounding app stack. The difference becomes material when the platform cannot prove who or what is making each action.

Risk and Threat Considerations

The main risk is misjudging where trust is enforced. If a harness is treated as cloud-native without actually binding identity, privilege, and policy to the runtime, agent actions can escape the intended blast radius. That creates exposure through over-privilege, weak tenancy separation, and inconsistent policy enforcement across redeployments or scaling events.

Failure mechanism: Attackers and misconfigured agents benefit when harnesses rely on static credentials, broad roles, or wrapper-based controls that are easy to bypass or misapply. Once an agent can reach tools, APIs, or workloads with durable privilege, compromise or misuse of that harness can turn one control gap into broad operational access.

Impact: The result can be unauthorized changes, data exposure, service disruption, or cross-environment movement through the same cloud control plane that was supposed to contain the workload.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Identity and Credential Sprawl	Cloud-native agent harnesses often hinge on workload identity and credential scope.
Recommendation — Eliminate shared credentials and scope each agent runtime to a minimal, distinct identity.
NIST Zero Trust (SP 800-207)	JEA — Dynamic Least Privilege and Continuous Verification	The question turns on runtime trust, scoped access, and policy-enforced execution.
Recommendation — Bind agent actions to continuous authorization and least-privilege policy enforcement.
CIS Controls v8	5 — Account Management	Harness design differs by how identities and access are provisioned and controlled.
	6 — Access Control Management	Cloud-native harnesses embed stronger access boundaries than cloud-hosted wrappers.
Recommendation — Inventory and restrict agent-access accounts, then remove standing access paths. Apply role-based restrictions and explicit access approvals to agent execution paths.
NIST CSF 2.0	PR.AC — Access Control	The distinction materially changes how access, isolation, and enforcement are implemented.
	PR.PT — Protective Technology	Cloud-native harnesses rely on platform-enforced isolation and policy controls.
Recommendation — Design the harness so access decisions are enforced by the platform, not only the app. Use platform controls to constrain runtime execution, network reach, and workload placement.

Practitioner Guidance

What to verify: Confirm whether the harness enforces isolation, identity, and policy at the platform layer or only through application code and surrounding wrappers. If those controls disappear when the app is moved, the design is cloud-hosted in security terms, even if it runs on Kubernetes.

Decision rule: If the agent can perform material actions, require workload identity, scoped authorization, and explicit placement boundaries before approving autonomous execution. If those controls are missing, treat the harness as a transitional hosting model and limit the action set until the platform catches up.

Practitioner takeaway: The security question is not where the harness runs, but whether the cloud platform is actively constraining the agent’s authority, or merely providing compute for it.