Security-sensitive enterprises should not have to rely only on a vendor's assertions about how an agent is controlled. Cogward is built so that execution, enforcement, sensitive state, and evidence stay inside the environment where the owning security team can inspect, test, operate, and verify them.
This page describes the trust architecture. See the capability map for what is available today, in preview, and planned.
Trust lives in properties the owning security team can check for itself, across every deployment.
Agents execute inside the software-vendor or enterprise trust boundary the product requires.
Security teams can inspect and test the runtime path that governs actions that change something.
Evidence can be retained and verified without depending on a vendor-hosted dashboard.
The same identity, policy, lifecycle, and evidence model can operate across deployment environments.
Each scenario below assumes the agent's behavior cannot be trusted. The runtime does not try to prove the agent will behave; it bounds the authority, reach, persistence, and blast radius available to it when it does not.
| Assume this can happen | What the runtime bounds |
|---|---|
| Prompt injection influences tool use | Runtime mediation at the execution boundary: every tool call is evaluated against policy and delegated scope before it runs, so injected content is bounded rather than trusted. |
| Agent attempts an unapproved API call | Runtime mediation and policy: only approved destinations are reachable through the governed path; unapproved calls are denied and recorded. |
| Agent sends data to an unapproved destination | Controlled network egress: data can leave only through approved routes; other destinations are not reachable from the sandboxed runtime. |
| Tool definition changes after approval | Integrity and version binding: tool identity is bound at approval, so a changed definition is re-evaluated rather than silently trusted. |
| Delegated authority exceeds the permitted scope | Delegation ceilings: authority narrows at each boundary; downstream agents cannot receive more than the upstream principal and agent contract permit. |
| One tenant's state is exposed to another | Tenant isolation: execution, state, and evidence are tenant-scoped at the runtime boundary rather than in application code. |
| Agent enters a costly loop | Resource and cost ceilings: runtime-enforced limits suspend or terminate a run that exceeds its bounds, independently of agent behavior. |
| Agent version degrades without a code deployment | Production evaluation and lifecycle authority: drift can be scored against per-version baselines and connected to gating, containment, or rollback. |
| Compromised code attempts to bypass framework hooks | Runtime boundary and credential custody: enforcement sits below the framework, and the agent's only route to models and tools is the governed path. |
| Human approval is missing or ambiguous | Approval as a first-class runtime state: actions that require approval wait at the boundary rather than proceeding. |
| Model provider behavior changes | Evaluation and evidence: behavior can be scored against baselines and recorded, so a change is attributable and can trigger a lifecycle action. |
| An agent continues after it should have been contained | Lifecycle authority: stop, suspend, contain, and roll back are runtime operations, not advisory flags the agent can ignore. |
Cogward limits authority, reach, persistence, and blast radius even when the agent's behavior cannot be trusted. It does not claim to prevent all compromise.
Cogward is the execution point where verdicts from specialist systems can be enforced and recorded. It does not reinvent the content-layer and security tools you already run.
A verdict from a content-security or classification system becomes an enforced, recorded outcome at the point where the agent actually acts.
Evidence is generated directly by the runtime, retained inside per-tenant boundaries, and structured so it can be verified independently. Records are append-only or tamper-evident. Signing or anchoring can be customer-controlled, and inclusion and consistency can be verified from the record itself. Sensitive content stays referenced rather than stored inline, so the record can be exported offline while still attributing identity, version, policy, approval, and action. The evidence stack is in preview as the ledger reaches production; the capability map carries its current status.
What problem is being solved. Operational telemetry answers engineering questions in the moment; evidence has to stay trustworthy for a security review, audit, or investigation that may happen long after the run, and possibly without the vendor in the path. The two records are separated so the evidence record can be verified on its own terms.
What the trust and failure boundary is. Evidence lives inside a per-tenant boundary, and its integrity boundary is cryptographic rather than procedural: whether a record is present, and whether history was silently rewritten, is decidable from the record and its proofs. Trustworthiness does not depend on the vendor remaining reachable.
What happens during failure or attempted bypass. Silent alteration or removal of a record is detectable through inclusion and consistency verification against a signed root. Lawful deletion is handled by redaction that removes content while preserving the structural position, so records above and below stay verifiable.
Which data and control elements remain local. Sensitive payloads remain in customer-controlled storage and are referenced by content hash and classification. Anchoring and signing keys can be held by the customer. Records stay tenant-scoped and exportable offline into the systems the organization already runs.
How it integrates with the rest of the runtime. Because evidence is produced by governed execution rather than reconstructed from disconnected logs, each record carries version, identity, policy, approval, and action attribution from the same execution boundary that enforced the control.
Named primitives
Cryptographic integrity demonstrates that recorded evidence has not been silently altered or removed without detection. It does not independently prove the truth of the original event.
Cogward produces structured controls and evidence that can support security, risk, audit, and compliance processes.
Control categories
Framework examples
On compliance
Exact control mappings depend on the customer's deployment, use case, policies, and broader control environment. Cogward provides runtime controls and evidence; it does not make an organization compliant by itself.
Export operational and evidence records into the observability, SIEM, audit, and GRC systems already used by the organization.
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.