Software vendors rarely serve every enterprise customer through the same infrastructure model. Cogward keeps agent identity, control, lifecycle, and evidence consistent while the physical deployment boundary changes.
Three deployment models cover the range from vendor-operated SaaS to disconnected, tightly controlled infrastructure. Each preserves the same runtime contract; what differs is where the physical boundary of execution, state, and evidence sits.
Run Cogward inside the software vendor's SaaS or dedicated cloud environment, with tenant-scoped execution, identity, state, policy, and evidence.
Use for
Properties
Deploy the runtime inside the enterprise customer's cloud account while preserving the same agent contract and operating model.
Use for
Properties
Run inside self-hosted, disconnected, or tightly controlled infrastructure where execution, enforcement, state, and evidence must remain local. Self-hosted and air-gapped operation are the same model at different points on one connectivity spectrum, not separate commercial tiers.
Use for
The physical boundary changes. The control contract does not.
Across every deployment model, the runtime carries the same contract. The infrastructure underneath it can be a shared SaaS region, a customer cloud account, or disconnected on-premise hardware without changing how the agent is identified, authorized, controlled, and recorded.
The control contract
Where the runtime lives and who operates it are independent choices. Customer-owned describes the trust boundary, not necessarily the operating model.
What problem is being solved. A software vendor serves the software-vendor environment, the enterprise customer account, and self-managed environments from one product. Each has a different owner, a different set of connectivity constraints, and a different set of rules about what may leave it. The deployment architecture has to keep one agent contract intact across all three without moving sensitive execution or evidence outside the environment that owns it.
What the trust and failure boundary is. The trust boundary is the selected environment: the software-vendor cloud, the enterprise customer account, or self-managed infrastructure. Execution and enforcement run on the execution plane inside that boundary. A control plane coordinates registration, policy distribution, and upgrades; its reachability is not on the path of a governed action, so loss of that connection is a failure of management convenience, not of enforcement.
Which architectural primitives are used. Control-plane and execution-plane placement are separated so the execution plane can run where the data lives. Sensitive payloads, tenant state, credentials, and evidence remain local; only bounded operational and evidence metadata may leave the environment, and only when the trust-boundary owner permits it. Identity integrates with the customer's IAM; keys are customer-owned through the customer's KMS; network connectivity is scoped, and disconnected operation is supported. Upgrades and policy are distributed as signed bundles that are validated locally before they take effect. Evidence is exported on the owner's terms rather than held in a vendor dashboard.
What happens during failure or attempted bypass. If external management connectivity fails, the execution plane continues to enforce the current policy and record evidence locally; operational continuity does not depend on reaching the control plane. Policy and upgrade bundles that fail local signature validation are not applied. No path routes execution, enforcement, sensitive state, or evidence outside the selected boundary to recover a lost connection.
Which data and control elements remain local. Execution, enforcement, sensitive state, and evidence stay inside the selected environment. Customer keys, tenant data, and credential custody remain local. What may leave, subject to the owner's policy, is limited to the operational and evidence metadata needed for coordination and export.
How it integrates with the rest of the runtime. The deployment boundary is the outermost frame around the same runtime the other pages describe: the durable session, the execution-control path, execution identity and delegation, lifecycle authority, and the evidence model all operate unchanged inside it. Moving between deployment models changes where those mechanisms run, not what they do.
The operating party may vary, but execution, enforcement, sensitive state, and evidence remain within the selected trust boundary.
Bring an agent, its deployment target, and the production questions your customers or security team are asking. We will walk through the runtime, control boundary, deployment model, and evidence architecture.