Platform capabilities

Runtime and execution

A production execution environment agents run inside

Capability	What Cogward provides	Why agents need it
Isolated agent runtime Available	Each agent runs inside an isolated execution sandbox with infrastructure-enforced resource and tenant boundaries, from millisecond responses to multi-day autonomous work.	Agents choose actions dynamically and can run for days, so execution must be isolated and recoverable.
Durable sessions Available	Long-running work is checkpointed so a session can recover and continue after an interruption, keeping its tenant, user, version, and approval context.	An agent carries multi-step work that cannot simply be retried from the start.
Tenant isolation at the runtime Available	Workspace, memory, session state, and IAM are boundaried per tenant at the infrastructure layer, beneath application code.	Many agent frameworks provide no infrastructure-level multi-tenant isolation, so that boundary must sit beneath the framework.
Resource ceilings Available	Per-run CPU, memory, and session limits are enforced at the execution layer, and idle sessions are reclaimed.	An agent can consume unbounded compute, so the runtime has to cap it.
Budgets and circuit breakers Planned	Spend budgets, loop detection, and automatic circuit breakers that halt a runaway run at the broker.	A tracked overage still completes; a circuit breaker stops the loop first.
Agent density and efficiency Available	Many sessions share the underlying compute: each borrows a worker only while active and releases it when idle, with warm restore on the next turn.	Agents spend most of their life waiting, so dedicating capacity to each idle session wastes resources at fleet scale.
Framework- and model-independent control Available	The same governance layer supports multiple harnesses (Claude Agent SDK and deepagents/LangGraph today) with per-run model selection, without embedding control into the agent.	Teams build on different frameworks and providers, so control has to be framework-independent.

Identity and delegated authority

Every action traceable to a distinct actor and the authority it carried

Capability	What Cogward provides	Why agents need it
Run-scoped identity Available	Every run receives a unique machine identity issued by the Cogward control plane and recorded on each governed action, never a borrowed user account or a shared service key.	An agent acts on its own initiative, so every action must trace to a distinct actor.
Dual attribution Preview	Every governed action records the acting agent today; attribution of the authorizing human is in preview as the delegated-authority path is wired.	Agents act on a person's behalf, so the record must show both who acted and under whose authority.
Delegation chain Planned	Multi-agent hand-offs where authority narrows at each boundary and the chain is recorded. A single human-to-agent exchange exists today; multi-agent chains are planned.	Agents delegate to other agents, and privilege must never expand along the chain.
Least-privilege, short-lived credentials Preview	A token broker mints short-lived credentials scoped to only what the run needs. It is live for governed connectors today, with per-run scoping for the agent identity rolling out.	A lingering, broadly-scoped agent credential is a standing breach.
Registry as authority of record Available	One place where every agent is declared, versioned, and governed, with identity issued at registration and the release authority for the estate.	The fleet fragments across teams; without one control tower, the weakest local setup sets the posture.

Policy, tools, and access

One governed path to models, tools, APIs, networks, and data

Capability	What Cogward provides	Why agents need it
Runtime enforcement point Preview	Model, tool, MCP, and outbound network calls are routed through runtime enforcement points below the framework. Blocking is enforced today at the connector and network planes; the unified per-action decision point records verdicts and is moving from shadow to enforce.	An agent decides its own actions at runtime, so they cannot be enumerated in advance.
Credential custody Preview	The runtime custodies upstream credentials and attaches them per approved destination. This is live for governed tool and MCP connectors, and is extending to the model path.	If the agent never holds the key, it cannot route around the enforcement point to use it.
Per-call policy enforcement Preview	Every call is evaluated against the agent's declared contract and the decision is recorded today; blocking enforcement is enabled per tenant in preview.	Agent behavior drifts without a code change, so the permitted set has to be checked continuously, not fixed once at deploy.
Fine-grained entitlements Preview	Per-tool-verb entitlements are enforced at the gateway today; per-resource and per-model-capability scopes are in preview.	An agent needs exactly the access its task requires, and no broader.
Governed model access Preview	Per-tenant model gateways route and isolate model traffic today; contract-based model allow-listing and per-tenant spend and rate caps are rolling out.	An agent chooses models at runtime and can send sensitive data to the wrong one.
Governed tool and MCP connectors Available	Tools are attached from a governed catalog, entitlements are enforced at the gateway, and tool definitions are pinned so a changed tool is caught.	Agents pick tools dynamically and external MCP servers can silently change what a tool does.
Tool-call validation Planned	Beyond pinning the tool definition, each call's arguments are checked against the tool's schema at the broker, so a permitted tool cannot be invoked with out-of-schema or smuggled inputs.	Injection and tool-poisoning usually ride in through arguments, not the call itself.
Bring-your-own guardrails Planned	Third-party content guardrails (prompt-injection, PII, toxicity) plug into the policy path as a callout, with their verdict enforced and recorded.	Content safety is a fast-moving specialist market you should stay free to choose and swap.
Per-user connected accounts Preview	A person connects their own account to an external tool via OAuth and the agent acts under that grant. It is live as a GitHub canary today; broader support is in preview.	An agent often needs to act as the specific human it works for, not one shared bot account.
Governed network egress Available	Outbound access is deny-by-default per agent and per tenant: each reaches only the hosts its contract allows, the runtime holds the credentials, and every allow or deny is recorded.	Without runtime restrictions, agent code may attempt outbound access beyond the destinations required for its task.
Human-in-the-loop checkpoints Available	High-risk tools are marked to require approval; the action holds durably for a human decision that is recorded as evidence.	Agents take actions that change something autonomously, so the pause has to live below the agent.

Behavior and evaluation

See how an agent behaved, beyond pass or fail

Capability	What Cogward provides	Why agents need it
Behavior traces Preview	A read-only trace of model interactions, tool use, decisions, and execution steps, tenant-scoped and correlated to the evidence record.	Whether a request succeeded says nothing about how the agent behaved to get there.
Version-aware evaluation Preview	Governed traces are the evidence base for candidate evaluation before release; scoring and shadow release-gates are in preview, with production drift detection to follow.	Agent quality degrades silently as models and prompts shift.
Cost and behavior visibility Planned	Token, cost, tool-mix, and outcome patterns attributed per agent and per tenant across production.	Agent cost and behavior vary run to run and per customer.

Lifecycle and operations

Promote deliberately, roll back in one command, at any scope

These capabilities operate as one governed lifecycle, from registration and versioning through promotion, production control, evaluation, and rollback. See the governed agent lifecycle →

Capability	What Cogward provides	Why agents need it
Versioned deployment and rollback Available	A staged path from development to production with per-tenant enablement, percentage-share canary, and atomic rollback. Each session runs to completion on the version it started under.	You promote deliberately rather than replacing the artifact and killing what was mid-flight.
Evaluation-driven release gates Preview	Promotion gated on evaluation evidence; shadow gates are in preview, with enforcing gates to follow.	Tests pass on a version that still regresses in production, so the gate has to read real behavior.
Tenant-specific version pinning Available	A tenant can remain on an approved version until it accepts a change, while other tenants move to the new one.	Regulated customers approve changes on their own schedule and cannot be force-migrated.
Kill, suspend, and drain at any scope Available	Stop a single run, a version, or an entire tenant, or drain in-flight work first, without touching what runs alongside.	A misbehaving agent must be haltable mid-flight, at precise scope.
One-command authoring and deploy Available	Scaffold, register, and deploy an agent from any repository with no direct infrastructure access.	Every team ships many agents onto the same layer, so standardized authoring keeps the fleet consistent.

Evidence and auditability

A record you can verify without the vendor in the path

Capability	What Cogward provides	Why agents need it
Tamper-evident evidence Preview	A cryptographically verifiable, append-only record of every governed action, built on hash chains and Merkle-tree structures. Verified end-to-end in development; rolling out to production on the durable substrate.	Regulators ask what an agent did and under whose authority, and expect proof it was not altered.
Two records, produced automatically Preview	An operational events journal for engineering (live) and a compliance ledger for auditors (rolling out with the durable ledger), both without extra instrumentation.	No single artifact serves both an SRE mid-incident and an auditor a year later.
Privacy by reference Preview	The ledger stores content hashes and data classifications; the content stays in the tenant boundary.	Agent inputs and outputs are sensitive, so evidence must prove what happened without copying the data out.
Independent verification Preview	A standalone verifier recomputes the ledger and checks its proofs with no live Cogward service, with a self-contained offline export; in preview as the ledger reaches production.	Auditors need to validate evidence without relying on a live vendor, or the vendor still existing.
OTel and OCSF export Preview	Evidence projected into OTel and OCSF for your SIEM. The projectors are implemented; the export pipeline ships with the ledger.	Auditors and SIEMs consume evidence in their own formats, not raw logs.
Regulation-specific evidence packs Planned	Per-regulation evidence packs (DORA and SOC 2 first) built on the anchored ledger.	Raw logs do not map to a control framework on an auditor's schedule.
Signed and digest-pinned images Available	Agent images are cryptographically signed and pinned by digest, and each session runs the exact pinned digest.	Agents pull code and dependencies from many sources, and a deploy should not trust whatever the pipeline pushed.
Fail-closed signature enforcement Planned	A gate that verifies signatures and refuses unsigned images at promotion.	A signed image only protects you if something refuses unsigned ones before they run.

Deployment control and operational sovereignty

Execution, control, and evidence inside the trust boundary you require

Capability	What Cogward provides	Why agents need it
Runs in your environment Planned	Execution, enforcement, and evidence deployed inside your own cloud, on AWS, Azure, GCP, or on-premise infrastructure.	A regulated buyer cannot relocate agent risk to a vendor they then have to audit.
Operational independence Planned	In the stricter deployment tiers, the runtime and its governance keep working with no connectivity back to Cogward.	In stricter deployment models, enforcement and evidence must keep working even when connectivity to the vendor is unavailable.
Per-tenant encryption (CMEK) Preview	Each tenant's workspace, memory, session state, and evidence are encrypted with a dedicated per-tenant key today; customer-owned (BYOK) keys are in preview.	Isolation must be provable at the infrastructure layer, not asserted in code.
Customer-owned evidence anchor Preview	The audit chain can be anchored and verified with the customer's own key, in preview as the first anchor adapter.	The record of what your agents did cannot depend on the same vendor whose product you are auditing.