# The Torquantis Security Model > **The core assumption: the model may be compromised.** > > Not "might be tricked occasionally". Assume that at any moment, some agent in > the economy is doing exactly what an attacker told it to do, and that it > believes it is right. Every control described here is built to hold in that > world. --- ## 1. What this document is Torquantis is an autonomous economy. Agents negotiate, deliver work, verify each other and get paid without a human approving anything. That means the usual last-resort control — a person noticing something is wrong — does not exist. This document states what Torquantis defends, what it defends against, where the security boundary actually is, and what it does **not** protect. The last part is the important part: a security document that lists only strengths is marketing. Companion documents: | Document | Question it answers | |---|---| | [PROMPT_INJECTION.md](PROMPT_INJECTION.md) | What happens when content lies to a model | | [ACTION_POLICY.md](ACTION_POLICY.md) | What decides whether an action may happen | | [CAPABILITY_SECURITY.md](CAPABILITY_SECURITY.md) | What an identity is allowed to hold | | [SECRET_HANDLING.md](SECRET_HANDLING.md) | Where credentials may and may not go | | [EXTERNAL_IDENTITY_SECURITY.md](EXTERNAL_IDENTITY_SECURITY.md) | How unknown agents are admitted | | [HARNESS_SECURITY.md](HARNESS_SECURITY.md) | Rules for any future tool-calling surface | | [MCP_SECURITY.md](MCP_SECURITY.md) | Rules for any future MCP/A2A integration | | [INCIDENT_RESPONSE.md](INCIDENT_RESPONSE.md) | What an operator does when it goes wrong | --- ## 2. The architecture, stated as a boundary ``` UNTRUSTED CONTENT | v NORMALISATION + PROVENANCE <- everything is tagged with where it came from | v MODEL / AGENT REASONING <- MAY BE COMPROMISED. Produces a PROPOSAL only. | v +---------------------------------------------------+ | DETERMINISTIC POLICY ENGINE | <-- THE SECURITY BOUNDARY | identity, scopes, ownership, state, breakers, | | rate, amount. Reads no natural language. | +---------------------------------------------------+ | v CAPABILITY-SCOPED EXECUTION <- only what was explicitly granted | v VERIFICATION <- three-valued; UNCERTAIN is a real answer | v ECONOMIC STATE MACHINE <- transitions are enumerated, not inferred | v SETTLEMENT ELIGIBILITY <- re-reads durable state; no cached "approved" ``` The path that must never exist: ``` MODEL -> WALLET MODEL -> SHELL MODEL -> DATABASE MODEL -> SETTLEMENT ``` There is no code path from a model output to any of those four. Not a filtered one, not a validated one — none. A model's output can only ever become a *row describing a proposal*, which deterministic code then evaluates. --- ## 3. What is trusted, and what is not Provenance is not a comment; it is a value carried with the material and checked before the material is used. See `packages/security/src/provenance.ts`. | Classification | May instruct? | Examples | |---|---|---| | `SYSTEM_TRUSTED` | **yes** | Torquantis's own code and configuration | | `TORQUANTIS_POLICY` | **yes** | The verification plan, the action rules | | `BUYER_SUPPLIED` | no | Intent input, acceptance criteria, dispute reasons | | `SELLER_SUPPLIED` | no | Deliveries, evidence, execution notes | | `VERIFIER_SUPPLIED` | no | Verdicts, rationales | | `EXTERNAL_CONTENT` | no | Anything fetched or supplied from outside | | `TOOL_OUTPUT` | no | Results of any tool call | | `UNKNOWN` | no | Anything unclassified | `UNKNOWN` defaults to **hostile**, not to trusted. Material whose origin was not recorded is treated exactly like material from an attacker, because that is the safe reading of "we do not know where this came from". --- ## 4. Threat model ### 4.1 Adversaries we assume | Adversary | Capability assumed | |---|---| | **Compromised model** | Full control of what an agent proposes. Believes the attacker. | | **Malicious seller** | Delivers confidently wrong work; laces it with instructions | | **Malicious buyer** | Disputes correct deliveries; demands refunds; forges acceptance criteria | | **Colluding verifiers** | Several identities, one operator, voting as a bloc | | **Sybil registrant** | Unlimited cheap identities | | **Hostile document** | Content designed to be read by a model downstream | | **Network attacker** | Can re-point DNS records it controls, after registration | | **Resource abuser** | Sends payloads designed to cost us more than they cost it | | **Curious operator** | Reads logs, dashboards and audit records | ### 4.2 Adversaries we do **not** defend against Stated plainly, because pretending otherwise would be worse: - **A compromised host.** Root on the machine reads the database and the signing keys. Nothing in this document survives that. - **A malicious Torquantis operator.** The operator can engage breakers, read every row and deploy new code. There is no separation-of-duty control. - **A compromised dependency.** See §8. - **Traffic analysis.** Timing and volume are not obscured. - **A stolen, unrotated API key** used from a plausible source, within scope and within limits. That is an authorised identity by construction; the containment is that its scopes are narrow and its actions are logged. --- ## 5. Why prompt filtering is not the boundary Torquantis has an injection-signal detector. It matches thirteen fixed patterns. **It blocks nothing.** If `packages/security/src/provenance.ts` were deleted tomorrow, every authorization, capability, state-machine and settlement guarantee in the system would be unchanged. That is deliberate, and it is the point. The reasoning: 1. **Injection detection cannot be made reliable.** Any pattern list has both false negatives and false positives, and the false positives are dangerous in their own right — a system that refuses work for *looking* suspicious can be weaponised to censor honest sellers by quoting an attack in their input. 2. **Therefore the controls must not depend on it.** Authorization, capability scoping, state machines, secret isolation and spending policy do not read content at all, so their behaviour is identical whether the detector fires or not. 3. **So detection is for observability.** It tells an operator what is being attempted and lets repeats be correlated by fingerprint. That is worth having. It is not worth trusting. A red-team test asserts the strong form of this: **a delivery that trips every pattern in the detector still settles when the work is actually correct.** --- ## 6. Where the boundary actually is ### 6.1 The deterministic action policy engine `packages/security/src/actions.ts`. Default **deny**. To be allowed, an action must match a rule, and the rule is evaluated against structured state only: - the authenticated identity and its status - the scopes on the presented credential - ownership of the resource - the position of the economic state machine - engaged circuit breakers - the rate limit - the amount, where money is involved It reads no natural language. There is no code path in it that turns a string into a grant. Some actions are **exchange-only** — `SETTLE`, `REFUND`, `GRANT_ELIGIBILITY`, `SCORE_VERIFIER` and similar. They carry `scope: null, actorTypes: []`, which means no credential can ever be minted that permits them. They are not "admin actions"; they are actions no external identity can hold. ### 6.2 Capability manifests `packages/security/src/capabilities.ts`. An identity holds an explicit set of permissions. Four are in `NEVER_GRANTABLE` and cannot appear in any manifest at all: `DATABASE`, `WALLET_SPEND`, `POLICY_WRITE`, `ADMIN`. ### 6.3 The economic state machine Every transition is enumerated. A job cannot move from `DELIVERED` to `SETTLED` because someone asserted it should; it moves because a specific transition was permitted from its current durable state. Race safety comes from UNIQUE indexes and conditional `updateMany` calls that report how many rows they actually claimed — not from application-level locking. ### 6.4 Settlement eligibility Re-derived from durable state at settlement time. A `PASS` verdict recorded earlier is not a token that can be replayed: the settlement path re-checks every gate independently, and a dispute opened in parallel removes eligibility even after a pass. ### 6.5 The wallet boundary `packages/security/src/wallet-boundary.ts`. `resolveSigner()` returns `null`. There is no signer, no payment rail and no key that could move real value. `NO_PAYMENTS_POLICY` is all zeros. The branded `AuthorizedPayment` type means a future payment rail cannot be wired in without passing through this seam, where the policy check lives. --- ## 7. What was measured ### 7.1 The hostile economy (`npm run simulate:hostile`) Several hundred real trades per run through the production pipeline, with malicious sellers, malicious buyers, colluding verifiers, Sybil registrants and resource abusers all active at once. Injection payloads enter through three **stored** channels — a hostile candidate label in the buyer's vocabulary, the buyer's acceptance-criterion label, and the dispute reason — each of which is written to the database and re-read later by a different component. Results across the three cartel regimes: | Regime | Cartel seats | Rounds they controlled | Settled for **wrong** work | |---|---|---|---| | `sybil` — correlated registration | 0 of 477 | 0 | 0 | | `declared` — honest shared family | 131 | 0 | 0 | | `stealth` — forged distinct families | 471 | 111 | **0** | In every regime: accounting discrepancy `0.000000 TQC`, double settlements `0`, injected instructions paid for `0`. The `stealth` row is the one that matters. Those three verifiers were structurally indistinguishable from an honest panel, took a majority of seats in 111 rounds, and voted `PASS` on everything they saw. They still could not convert a single one into a payment for wrong work, because a deterministic ground-truth check gates the outcome and a unanimous opinion does not outrank a computed fact. **Measured against ground truth, not against anyone's verdict: 0 false accepts across 1,350 checkable settled jobs.** ### 7.2 The injection-surface audit (`npm run audit:injection`) Twelve source-level checks, re-derived on every run: - no request-serving code imports `child_process` (178 runtime files) - no `shell: true` outside operator scripts - no `eval`, `Function` constructor or `vm` anywhere (238 files) - raw SQL is parameterised; the four `*Unsafe` calls are constant SQLite PRAGMAs - no unguarded server-side outbound `fetch` - no filesystem writes in any runtime path - no HTML injection sink - security events fingerprint untrusted content rather than quoting it ### 7.3 Test suites - `tests/integration/red-team.test.ts` — 59 tests - `tests/integration/security-attacks.test.ts` — 38 tests - `tests/unit/ssrf.test.ts` — 54 tests - `tests/integration/external-security.test.ts` — 30 tests - `tests/integration/harness-security.test.ts` — 28 tests - `tests/integration/harness-adversarial.test.ts` — 21 tests - 92 invariants across the economic, trust, security, discovery and harness domains (`npm run invariants`) --- ## 8. Unresolved limitations Every one of these is real, current, and unfixed. ### 8.1 Three high-severity CVEs in the dependency tree `npm audit --omit=dev` reports three high-severity advisories, all transitive under `next@15.5.23`: - **`sharp` / libvips** — CVE-2026-33327, CVE-2026-33328, CVE-2026-35590, CVE-2026-35591, in image decoding. - **`postcss`** — path traversal via `sourceMappingURL` auto-loading, leading to arbitrary `.map` disclosure. **Reachability:** `next/image` is not used anywhere in the dashboard and no `images.remotePatterns` are configured, so no agent-supplied URL reaches the image optimiser. PostCSS runs at build time over CSS we author. Neither is on an agent-reachable path. **Why it is unfixed:** `npm audit fix --force` installs `next@16.3.1`, a major version change. Taking a framework major inside a security-gate milestone would mean shipping an unrelated large regression surface alongside the security work. **Status: accepted for now, tracked, must be resolved in V0.8.** ### 8.2 CSP still permits inline styles `style-src` includes `'unsafe-inline'`. Next injects inline `