Spec 13: Security Model
DWS Spec 13: Security Model
Digital Worker Standard — DWS Specification
Version: 1.0 Tier: 4 — Governance Status: Release Candidate Dependencies: Spec 1 (Worker Identity), Spec 3 (Skill Specification), Spec 11 (Events & Telemetry)
1. Overview
This specification defines the security model for DWS-compliant systems. It covers data classification, credential management, transport security, and the security boundary between definition-time and runtime concerns.
DWS does not prescribe specific security implementations (encryption algorithms, key management systems, authentication providers). It defines the security requirements that compliant runtimes MUST satisfy and the security metadata that worker definitions MUST declare.
2. Data Classification
All data within a DWS system is classified into one of four levels. These levels govern access control, export rules, retention policies, and event redaction.
| Level | Label | Access | Export | Retention |
|---|---|---|---|---|
| 0 | public | No restrictions. | Exportable without restriction. | Standard retention. |
| 1 | internal | Organisation members only. | Exportable within the organisation. | Standard retention. |
| 2 | confidential | Role-based access within the organisation. | Redacted on export outside authorised scope. | Extended retention per Spec 12. |
| 3 | restricted | Named individuals only. Requires explicit authorisation. | Not exportable. Must be regenerated by the recipient. | Maximum retention per regulatory framework. |
2.1 Where Classification Applies
| Artifact | Classification Field | Default |
|---|---|---|
| Knowledge entries (Spec 2) | data_classification | internal |
| Outcome artifacts (Spec 5) | retention_policy.data_classification | internal |
| Events (Spec 11) | Inherited from the artifact or context they reference. | internal |
| Guardrails (Spec 1) | data_classification on the guardrail. | No default; applies to the data the guardrail protects. |
3. Credential Management
3.1 Principle
Worker definitions MUST NOT contain secrets. No API keys, passwords, tokens, or connection strings in jobspec.json, worker descriptors, skill definitions, or any other definition-time artifact.
Credentials are a runtime concern. They are injected by the runtime at instantiation time and MUST NOT be committed to version control.
3.2 Secret References
When a worker or skill needs credentials (e.g., to access an MCP tool server), it declares a secret reference rather than a literal value:
{ "tools": [ { "tool_uri": "mcp://salesforce/api", "required": true, "credentials": { "type": "secret_ref", "ref": "salesforce-api-key", "description": "API key for Salesforce CRM access." } } ]}The runtime resolves secret_ref values from its secret store (environment variables, vault, cloud secret manager, etc.). The resolution mechanism is implementation-specific.
3.3 Credential Rotation
Runtimes SHOULD support automatic credential rotation. Workers MUST NOT cache credentials beyond a single session. If a credential expires mid-session, the runtime MUST refresh it transparently or fail the session with a clear error.
4. Transport Security
4.1 MCP Tool Connections
All MCP tool connections SHOULD use TLS 1.2 or later. Runtimes MUST NOT send credentials over unencrypted connections unless explicitly configured for local development.
4.2 Event Stream
Event streams carrying confidential or restricted data MUST be encrypted in transit. At-rest encryption is RECOMMENDED for all event data and REQUIRED for restricted data.
4.3 Knowledge Store
Knowledge entries classified as confidential or restricted MUST be encrypted at rest. Access MUST be restricted based on the entry’s classification level.
5. Worker Isolation
5.1 Runtime Isolation
Each worker instance SHOULD run in an isolated execution environment. The degree of isolation is implementation-specific, but compliant runtimes MUST prevent:
- One worker from accessing another worker’s in-progress state (unless explicitly shared via coordination protocol, Spec 7).
- Workers from accessing credentials assigned to other workers.
- Workers from modifying knowledge entries outside their declared scope.
5.2 Verification Isolation
Verification workers (Spec 8) MUST be context-isolated from execution workers. This is a security requirement in addition to being a quality requirement: a verifier with access to the executor’s state could be influenced by it.
6. Authority Enforcement
6.1 Three-Level Authority Model
DWS enforces authority at three levels:
| Level | Where | How |
|---|---|---|
| Level 1: Pre-execution | Before the worker harness is assembled. | Runtime checks the worker’s authority level against the intent. Pure policy evaluation; no model involvement. |
| Level 2: In-prompt | Injected into the system prompt by the prompt assembler. | The worker self-governs based on its declared authority. Advisory, not enforceable. |
| Level 3: Tool-call | At every tool invocation. | Runtime intercepts tool calls and checks authority before dispatching to MCP. Synchronous and enforceable. |
Level 1 and Level 3 are enforceable by the runtime. Level 2 is advisory (model-dependent). Runtimes MUST implement Levels 1 and 3. Level 2 is RECOMMENDED.
7. Threat Model
7.1 In-Scope Threats
| Threat | Mitigation |
|---|---|
| Worker exceeding authority | Three-level authority enforcement (Section 6). Boundary declarations (Spec 1). |
| Credential leakage | Secret references, never literal values. No credentials in definition-time artifacts. |
| Knowledge poisoning | Confidence scoring, decay model, data classification (Spec 2). Promotion criteria require multiple observations. |
| Prompt injection via tool results | Guardrails on tool outputs (Spec 1). Workers are instructed to treat tool results as untrusted. |
| Unverified output delivery | Verification gates (Spec 8) before delivery. Outcome success criteria (Spec 5). |
| Audit trail tampering | Append-only event store. Event sequence numbers for tamper detection. |
| Cross-worker information leakage | Coordination awareness boundaries (Spec 7). Verification isolation (Spec 8). |
7.2 Out-of-Scope Threats
DWS does not address:
- Model-level attacks (adversarial inputs, model extraction).
- Infrastructure security (network configuration, firewall rules).
- Physical security.
These are runtime and infrastructure concerns, not specification concerns.
8. References
- OWASP Top 10 for Agentic Applications (2026) — Risk taxonomy for AI agent systems.
- IETF AIMS Framework — Agent identity management for cross-boundary authentication.
- SPIFFE/SPIRE — Workload identity for runtime worker authentication.
- Spec 1: Worker Identity — Authority levels, guardrails, boundary declarations.
- Spec 2: Knowledge Schema — Data classification on knowledge entries.
- Spec 7: Coordination Protocol — Awareness boundaries between workers.
- Spec 8: Verification Framework — Context isolation requirements.
- Spec 12: Compliance & Governance — Regulatory requirements for security.