11 Inside the product
See DCS Connector OS.
Connector OS decides which action an AI agent may run, under which identity, permission and approval. R-Series turns that action into a receipt anyone can check. Together they connect permission to action, and action to evidence you can verify.
Which action may run, for which identity, under which permission and with whose approval. The agent asks; Connector OS decides, calls the provider and checks the result.
Each executed action becomes a receipt: one exact byte form, one hash, a classical and a post-quantum signature, chained to the run. Anyone with the public keys can check it offline.
The rule that allowed an action and the evidence of what the action did sit in one chain. Nothing runs without a decision, and nothing that runs goes unrecorded.
Most integration platforms can connect an AI agent to a CRM or a payment system. What they do not give a company is proof: a record of what the agent did, who allowed it, under which rule and what came back.
With Connector OS, every action through every connector leaves an R-Series receipt that the company, its auditor or a regulator can check on their own, that the platform cannot quietly edit, and that still holds years later. When it cannot produce that receipt, it refuses to act.
The connectors are the reach. R-Series is the trust.
Not logs you have to trust. Evidence you can check.
Six stages sit between an agent and a real system. The agent never touches a provider directly.
The request carries a declared intent, such as “reconcile last month’s failed payments”. Every action is checked against it.
Agents observe, diagnose and plan with declared capabilities. They never hold raw provider credentials.
Sensitive actions pause for a human. Approvals are tied to the plan, single-use, and they expire.
Connector OS makes the call with scoped credentials. The agent never touches a provider directly.
A timeout after a write is marked unknown and reconciled before any retry. Nothing is assumed.
R-Series hashes the fact, signs it with Ed25519 and ML-DSA-65, and chains it to the run. The receipt is stored with the action.
GitHub is the first of the five V1 connectors. A GitHub test run through the V1 staging integration was signed with the R-Series hybrid suite. Hybrid signing does not wait for V2.
| In the GitHub test build | Used |
|---|---|
| Classical signature | Ed25519 |
| Post-quantum signature | ML-DSA-65 (FIPS 204) |
| Signing suite | hybrid-ed25519-mldsa65 |
| Verification rule | Both signatures must be valid. A receipt with either one missing or wrong is rejected. |
Connector OS produces the facts. R-Series turns each fact into evidence. This is what a receipt for a GitHub action records.
| Field | What it records | Why it matters |
|---|---|---|
| Who | The agent, and the person who approved | Every actor, human or machine |
| Intent | What the agent was asked to do | Catches actions that do not match the ask |
| What | The connector, its version and the exact operation | No doubt about which call was made |
| Rule | The policy that allowed it | Shows the decision, not just the outcome |
| Payload | Hashes of what went in and what came back | Proves content without exposing it |
| Outcome | The result at the provider, reconciled | Tied to the real effect, not the request |
| Chain | The receipt before it in the same run | Rebuilds multi-step work end to end |
| Signature | Ed25519 + ML-DSA-65, both required | Independent, long-lived verification |
How proof works walks through the byte form, the hash and the two signatures. Verify lets you sign and check a sample receipt in your browser.
If evidence cannot be produced, Connector OS does not perform the write.
If the provider acted but evidence was interrupted, a durable obligation finishes it later.
Altered evidence, or a receipt signed with the wrong key, fails every verifier.
When a provider is down, a coverage receipt records the exact window. Silence is never mistaken for no activity.
Receipts are designed to be checked with the verifier and the issuer’s public keys, with the platform switched off. Independent offline verification of the first GitHub receipts is the next step.
Request, intent, policy, approval, provider effect and reconciliation, rebuilt from the chain.
Each connector page documents capabilities, authentication, permissions, webhooks and the provider’s official documentation. Runtime verification is published per connector as it is earned.
First five connectors in V1
Figures from os.dcsai.ai, checked 27 Oct 2026.
| Typical integration platform | DCS Connector OS with R-Series |
|---|---|
| Activity log in the vendor’s database | Signed receipt per action, chained |
| Trust the vendor | Verify independently and offline |
| Logging can fail silently | No receipt, no write; gaps are recorded |
| Records what happened | Records why, who allowed it, and what changed |
| Credentials as configuration | Credential grant, refresh, scope and revoke as evidence |
| Connector updates are invisible | Every connector version carries a signed passport |
| Evidence ages with today’s cryptography | Hybrid post-quantum signatures from R-Series |
Connect a system once; every call is evidenced. Debug with the exact chain of what the agent did.
A verifiable record of every machine action and credential event, with proof of least privilege.
Signed evidence instead of screenshots and exports, for audit and data-protection requests.
Agents that can be trusted with writes, because every write is approved, recorded and reversible.
A defensible answer to “what did our AI do with our money and our customers’ data”.
Disputes resolved with proof: a refund or a record change shown exactly as it happened.
| Stage | What it means | State |
|---|---|---|
| Done so far | Integrated and proven end to end against simulated providers. | In development |
| Now | V1 in private staging verification with design partners. First five connectors: GitHub, Slack, Notion, Gmail (drafts) and Stripe (test mode). Hybrid Ed25519 + ML-DSA-65 receipts are part of it. | Staging |
| Not yet | Not yet verified with real providers. Runtime verification is published per connector as it is earned; none are runtime-verified today. | In development |
| Next | V2, with the public API and SDKs, is planned for Q2 2027. | Planned |
The product site has the connector catalogue, how receipts work and the roadmap. Request early access there, or talk to us about enterprise and sovereign deployment.
Want the full technical picture? Architecture, live demonstrations and detailed status are shared in a private technical briefing, under NDA. Write to hello@dcslabs.ai.
Request a technical briefing