SORK Cloud — System Architecture

SORK Cloud is a multi-agent AI security system. One sork scan command triggers a four-stage pipeline: content safety screening → triage → patch generation → verification. The entire flow runs against your codebase in under 10 seconds for most files.

SORK has three surfaces:

• →sork-cli — npm global package. Runs in your terminal, CI, or VS Code tasks.
• →sork-client — Next.js web dashboard at sorkcloud.space. Browse scans, apply fixes, manage keys, view reports.
• →sork-back — Hono TypeScript API on Render. Handles all pipeline logic, DB, BYOK, and analytics.

Every request flows through the same pipeline regardless of whether it originates from the CLI, the web dashboard, or a VS Code send.

Stack

Every scan request follows this exact sequence. No stage is skipped. Each stage can fail independently and returns structured JSON.

POST /api/scan
{ "code": "...", "licenseKey": "..." }

→ Safety check: score 0–100
→ threshold < 30 → BLOCKED

→ 40+ patterns across TS, JS, Py, Rust, Go, Java
→ CWE ID, confidence %, severity, fix hint
→ Returns: { issues: [...] }

→ SORK Engine generates patch (deep tier)
→ Minimal diff: only vulnerable lines
→ Hybrid memory: past fixes for this repo
→ Returns: { patch, originalLines, fixedLines }

→ Re-scan patched code
→ Original issue resolved? ✓/✗
→ New issues introduced? ✓/✗
→ Score 0–100 → threshold 80 = approved

Each pipeline stage is an independent agent. Agents are stateless functions that receive structured input and return structured JSON. They communicate through the sork-back API, not peer-to-peer.

Agent Interface

interface AgentInput {
  code: string;           // source code to analyse
  language: string;       // detected language
  issues?: Issue[];       // from previous stage (Fix + Verify)
  memoryContext?: string; // from embed tier (Fix stage only)
}

interface AgentOutput {
  stage: "triage" | "fix" | "verify";
  issues?: Issue[];
  patches?: Patch[];
  verifyScore?: number;
  safetyScore?: number;
  blocked?: boolean;
}

Default Inference Engine

All agents use the SORK Engine multi-tier router by default. Response times average 1.8s at p95. Users can override to any BYOK endpoint — the agent system routes through the same interface regardless of provider.

SORK maintains a persistent memory of your codebase using the embed tier. This means fix quality improves over time — SORK knows your coding patterns, your existing mitigations, and the history of past issues.

How it works

Memory fields

{
  userId: string,
  filePath: string,
  cweId: string,
  originalCode: string,
  fixedCode: string,
  embedding: number[],   // 1024-dim vector
  createdAt: Date,
  score: number          // verify score at time of storage
}

Pro and Pro Plus users can add their own API keys from any supported provider. SORK uses your key when your BYOK entry is active, bypassing the shared quota.

Supported providers

• →Fast tier — default inference provider
• →Custom models — connect any compatible endpoint
• →Embed provider — override the embedding tier for memory
• →OpenAI-compatible — any OpenAI-spec endpoint (local or hosted)

Security

Keys are encrypted at rest using AES-256-GCM before being written to the database. The encryption key is never logged or exposed in API responses. Only the last 6 characters are shown in the dashboard.

Live status

The dashboard shows real-time key health by issuing a minimal 1-token probe request when you open the API Keys view. Status values: ok / limited / error / inactive.

Install once globally. All commands communicate with sork-back via your license key.

npm install -g sork-cli

Commands

sork-ignore

To suppress a false positive on a specific line, add an inline annotation:

const query = "SELECT * FROM " + table; // sork-ignore: CWE-89

Or suppress an entire file via .sorkignore (same format as .gitignore).

Request authentication

CLI requests use a license key (SORK-prefixed JWT signed with JWT_SECRET). Dashboard requests use Clerk JWTs. Both are validated on every API route in sork-back.

Data handling

• →Code submitted for scanning is never persisted beyond the pipeline run. Only metadata (file path, CWE IDs, severity, scores) is stored.
• →BYOK keys are stored encrypted (AES-256-GCM). The plaintext key is decrypted only during the pipeline call and never logged.
• →Memory embeddings store code snippets of patched lines for context retrieval, not full files.

Rate limiting