Readiness & Claims Matrix
WorkAgent OS adheres to strict engineering honesty: no unsupported claims, no fabricated benchmarks. Every capability below is a design target (SPEC) — readiness targets, not guarantees. Production implementation and verification evidence have not been published with this website.
Public Product Claims Matrix
Traceability matrix linking every architectural claim to its implementation target, planned verification approach, and specification reference. No claim below has been verified in production.
| Capability & Suite ID | Implementation Architecture | Automated Verification Test | Evidence & Verification Metadata | Status |
|---|---|---|---|---|
Strict Tenant Isolation SEC-ISO-001 (proposed) | Implementation target: PostgreSQL Row-Level Security (RLS) bound to session tenant_id, pgvector metadata isolation, S3 directory prefixes, Redis tenant namespaces. | Planned: automated cross-tenant data retrieval attack test suite executed on every commit. | No production verification artifact published. Owner: Security Engineering•Verified: Not verified | SPEC |
Action Integrity & Canonical Hashing ACT-HASH-004 (proposed) | Implementation target: deterministic canonical JSON formatting (sorted keys, UTF-8 encoded) with SHA-256 payload hashing prior to human approval. SHA-256 provides integrity binding — it is not approver authentication or a digital signature. | Planned: hash mismatch and parameter tampering simulation test suite. | No production verification artifact published. Owner: Platform Core•Verified: Not verified | SPEC |
Human-in-the-Loop Approval Gates HITL-POL-002 (proposed) | Implementation target: policy engine pauses the execution DAG on actions with Risk Score > 50, requiring hash-bound human approval. | Planned: approval bypass regression tests and replay resistance verification. | No production verification artifact published. Owner: Identity & Policy•Verified: Not verified | SPEC |
Prompt Injection & Untrusted Content Firewall INJ-SEC-008 (proposed) | Implementation target: strict authority hierarchy (System > Tenant > User > External Tool Data) with input sanitization firewalls. | Planned: indirect injection and adversarial tool payload test suite. | No production verification artifact published. Owner: AI Safety & Governance•Verified: Not verified | SPEC |
MCP-Compatible Tool Gateway MCP-GW-012 (proposed) | Implementation target: bi-directional tool connector gateway with schema validation, tenant credential isolation inside Vault, and idempotency control. | Planned: MCP protocol compliance tests, schema validation suites, credential leakage tests. | No production verification artifact published. Owner: Integrations & Tools•Verified: Not verified | SPEC |
State Verification & Recovery REC-VAL-005 (proposed) | Implementation target: post-execution read-back of external system state comparing actual entity values against planned schema before commit. | Planned: simulated partial external failure, schema drift, and network partition test suites. | No production verification artifact published. Owner: Reliability Engineering•Verified: Not verified | SPEC |
Tamper-Evident Audit Log AUD-CHN-003 (proposed) | Implementation target: append-only event store with sequential hash chaining connecting execution and approval events, so retroactive modification is detectable. | Planned: audit chain verification scripts detecting retroactive modification or deletion. | No production verification artifact published. Owner: Compliance & Audit•Verified: Not verified | SPEC |
Idempotency & Duplicate-Write Suppression IDM-KEY-007 (proposed) | Implementation target: deterministic idempotency keys on every mutating tool call. Same key + same canonical payload returns the existing result; same key + a different payload is rejected. No universal exactly-once delivery is claimed — connector provider behavior varies. | Planned: duplicate dispatch and retry replay test suite against idempotency store. | No production verification artifact published. Owner: Integrations & Tools•Verified: Not verified | SPEC |
Connector Verification & Recovery Capabilities SPEC
Design examples for independent read-back verification, retry, compensation, and reconciliation across key enterprise connectors. Provider behavior must be verified per connector and deployment — nothing here is a deployed default.
| Connector | Read Verification Strategy | Retry Strategy | Rollback Capability | Compensation Mechanism | Reconciliation Audit |
|---|---|---|---|---|---|
| Google Calendar | GET event by ID verify status === 'confirmed' and start/end matches | Proposed: exponential backoff (3 attempts, max 10s) | Compensating | Compensating action: delete created event ID or restore previous event payload snapshot | Etag comparison against audit log snapshot |
| Gmail | Verify draft ID exists or sent message ID in sent folder | Proposed: linear retry on 429 / 503 (max 2 attempts) | None (Manual) | Irreversible external send; pre-execution hash approval required; send follow-up cancellation if configured | Message-ID and thread-ID logged in append-only audit chain |
| Jira / Linear | GET issue by issue_key verify fields, status, and assignee | Proposed: exponential backoff on 429 rate limit (3 attempts) | Partial / Compensating | Transition issue to 'Cancelled' or revert custom fields to cached pre-execution state | Changelog API diff comparison against execution intent |
| Slack | conversations.history by message ts verify text and attachments | Proposed: exponential backoff with jitter on HTTP 429 | Compensating | Compensating action: chat.delete by channel and ts or chat.update with redaction notice | Message timestamp and channel ID mapped in execution store |
| Salesforce / CRM | SOQL query by record ID verify updated field values and SystemModstamp | Proposed: exponential backoff on transient network / lock errors (3 attempts) | Partial / Compensating | Revert updated fields to snapshot state captured in pre-execution context | Field history tracking cross-checked against audit store |
Enterprise Data Handling & Security FAQ
Direct, unambiguous answers to the most critical security, privacy, and sovereignty questions required by Enterprise InfoSec review teams.
01.Does customer data train frontier AI models?
The design intent is that tenant data, conversational history, and document embeddings are never used to train or fine-tune third-party foundation models, and that inference uses stateless API modes. Actual provider training and retention terms depend on the exact provider contract and deployment — see the provider handling matrix in the Trust Center.
02.How are third-party credentials and OAuth tokens protected?
By design, credentials reside exclusively within a dedicated vault with tenant key derivation. The reasoning LLM is intended to receive only opaque tool identifiers and sanitized JSON schemas — never raw API tokens, database credentials, or secret keys.
03.Where is tenant data stored and can we restrict residency?
The specification targets tenant-scoped schemas with PostgreSQL Row-Level Security (RLS) across relational records, vector embeddings, and object artifacts. Regional residency options are a roadmap capability — specific regions and guarantees are not yet deployment-verified; see the residency matrix in the Trust Center.
04.How does WorkAgent OS prevent indirect prompt injection?
The specified authority hierarchy is System Policy > Tenant Policy > Delegated User Prompt > External Tool Data. External content (e.g. emails, web documents) is designed to be sanitized by the untrusted content firewall and must never grant itself permissions or alter tool scopes. This is a design constraint under specification, not a verified guarantee.
05.What prevents parameter tampering before an approval is executed?
In the design, actions requiring human approval are canonicalized into sorted UTF-8 JSON and hashed using SHA-256. The hash binds the approval to the exact payload — it provides integrity binding, not approver authentication. If any parameter drifts prior to execution, the kernel is specified to halt.
06.How does state verification differ from checking HTTP response codes?
HTTP status codes only confirm the remote server accepted the packet. The specified verification approach is an active read-back: querying the remote API (e.g. Jira, CRM) post-execution to verify that the entity state and schema attributes match the expected plan.
Risk Scoring Specification
SPECIllustrative scoring model — policies, tenant configuration, and scope checks can still deny low-scoring actions. The canonical formula multiplies five normalized factors:
| Factor | Range | Meaning |
|---|---|---|
| Impact | 0.0 – 1.0 | Blast radius of the action if executed wrongly |
| Irreversibility | 0.0 – 1.0 | Cost/difficulty of undoing the effect |
| Externality | 0.0 – 1.0 | Effect on parties/systems outside the tenant |
| Sensitivity | 0.0 – 1.0 | Data-classification level touched |
| Uncertainty | 0.0 – 1.0 | Model/policy confidence margin |
| Score | Tier | Behavior |
|---|---|---|
| 0 – 20 | Auto Execution | Eligible for autonomous execution in the illustrative model — still subject to policy, tenant, and scope checks. |
| 21 – 50 | ABAC / Policy Check | Policy evaluation before execution. |
| 51 – 80 | Human Approval Gate | Requires hash-bound human approval. |
| 81 – 100 | Deny / Elevated Approval | Denied or routed to elevated approval. |
Ready to Inspect the Technical Architecture?
Explore our 6-Layer Platform Architecture, test the interactive execution simulator, or read the full master specification.