@weave_protocol/ward 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +214 -0
- package/SKILL.md +84 -0
- package/SPEC.md +258 -0
- package/dist/cli.d.ts +12 -0
- package/dist/cli.d.ts.map +1 -0
- package/dist/cli.js +465 -0
- package/dist/cli.js.map +1 -0
- package/dist/enforcer/index.d.ts +41 -0
- package/dist/enforcer/index.d.ts.map +1 -0
- package/dist/enforcer/index.js +225 -0
- package/dist/enforcer/index.js.map +1 -0
- package/dist/index.d.ts +27 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +27 -0
- package/dist/index.js.map +1 -0
- package/dist/parser/index.d.ts +17 -0
- package/dist/parser/index.d.ts.map +1 -0
- package/dist/parser/index.js +326 -0
- package/dist/parser/index.js.map +1 -0
- package/dist/parser/markdown.d.ts +24 -0
- package/dist/parser/markdown.d.ts.map +1 -0
- package/dist/parser/markdown.js +52 -0
- package/dist/parser/markdown.js.map +1 -0
- package/dist/parser/yaml.d.ts +23 -0
- package/dist/parser/yaml.d.ts.map +1 -0
- package/dist/parser/yaml.js +134 -0
- package/dist/parser/yaml.js.map +1 -0
- package/dist/types.d.ts +184 -0
- package/dist/types.d.ts.map +1 -0
- package/dist/types.js +15 -0
- package/dist/types.js.map +1 -0
- package/examples/basic.WARD.md +74 -0
- package/examples/compliance.WARD.md +108 -0
- package/examples/strict.WARD.md +127 -0
- package/package.json +64 -0
package/README.md
ADDED
|
@@ -0,0 +1,214 @@
|
|
|
1
|
+
# π‘οΈ @weave_protocol/ward
|
|
2
|
+
|
|
3
|
+
[](https://www.npmjs.com/package/@weave_protocol/ward)
|
|
4
|
+
[](https://www.npmjs.com/package/@weave_protocol/ward)
|
|
5
|
+
[](https://opensource.org/licenses/Apache-2.0)
|
|
6
|
+
|
|
7
|
+
**WARD.md β the agent security policy standard.**
|
|
8
|
+
|
|
9
|
+
> *AGENTS.md tells your agent what to do.*
|
|
10
|
+
> *SKILL.md tells your agent how to do it.*
|
|
11
|
+
> ***WARD.md tells your agent what it can't.***
|
|
12
|
+
|
|
13
|
+
Part of the [Weave Protocol](https://github.com/Tyox-all/Weave_Protocol) security suite.
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
npm install @weave_protocol/ward
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## What is WARD.md?
|
|
22
|
+
|
|
23
|
+
Agents are now infrastructure-as-code. They're defined in markdown files
|
|
24
|
+
(`AGENTS.md`, `SKILL.md`), version-controlled, and shared across registries.
|
|
25
|
+
|
|
26
|
+
If agent *behavior* is declared in a file, agent *security* should be too.
|
|
27
|
+
|
|
28
|
+
**WARD.md** is a standard format for declaring the security policy of an
|
|
29
|
+
AI agent. It lives next to `AGENTS.md` and `SKILL.md` in the same repo,
|
|
30
|
+
and is read by harnesses (Antigravity, Claude Code, MDASH) and runtime
|
|
31
|
+
enforcers (Mund, Hundredmen, DΕmere) to keep the agent inside its lane.
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
my-agent-project/
|
|
35
|
+
βββ AGENTS.md # what the agent does
|
|
36
|
+
βββ SKILL.md # how the agent does it
|
|
37
|
+
βββ WARD.md # what the agent can't do β this package
|
|
38
|
+
βββ .weave/
|
|
39
|
+
βββ attestations/ # cryptographic proofs that the policy held
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## Quick start
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
# Generate a starter WARD.md
|
|
48
|
+
npx @weave_protocol/ward init
|
|
49
|
+
|
|
50
|
+
# Validate it
|
|
51
|
+
npx @weave_protocol/ward validate WARD.md
|
|
52
|
+
|
|
53
|
+
# Show a human-readable summary
|
|
54
|
+
npx @weave_protocol/ward explain WARD.md
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
## A minimal WARD.md
|
|
60
|
+
|
|
61
|
+
```markdown
|
|
62
|
+
---
|
|
63
|
+
ward: "1.0"
|
|
64
|
+
agent: my-data-analyzer
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
# WARD.md
|
|
68
|
+
|
|
69
|
+
## Filesystem
|
|
70
|
+
allow:
|
|
71
|
+
- read: /workspace/**
|
|
72
|
+
- write: /workspace/output/**
|
|
73
|
+
deny:
|
|
74
|
+
- read: /workspace/secrets/**
|
|
75
|
+
default: deny
|
|
76
|
+
|
|
77
|
+
## Network
|
|
78
|
+
deny:
|
|
79
|
+
- url: "**"
|
|
80
|
+
default: deny
|
|
81
|
+
|
|
82
|
+
## Capabilities
|
|
83
|
+
allow:
|
|
84
|
+
- file_read
|
|
85
|
+
- file_write
|
|
86
|
+
deny:
|
|
87
|
+
- shell_exec
|
|
88
|
+
default: deny
|
|
89
|
+
|
|
90
|
+
## Behavioral Limits
|
|
91
|
+
maxIterations: 50
|
|
92
|
+
maxRuntimeSeconds: 300
|
|
93
|
+
maxCostUSD: 5.00
|
|
94
|
+
|
|
95
|
+
## Verification
|
|
96
|
+
required: true
|
|
97
|
+
backend: domere
|
|
98
|
+
frequency: session_end
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
That's a complete policy. The agent can read inputs and write outputs, can't
|
|
102
|
+
touch secrets, can't make network calls, can't shell out, can't burn more
|
|
103
|
+
than $5 or run for more than 5 minutes β and every action is attested at
|
|
104
|
+
session end.
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## Programmatic use
|
|
109
|
+
|
|
110
|
+
```typescript
|
|
111
|
+
import { parseWard, checkFilesystem, checkNetwork, checkCapability } from "@weave_protocol/ward";
|
|
112
|
+
import { readFileSync } from "node:fs";
|
|
113
|
+
|
|
114
|
+
const policy = parseWard(readFileSync("./WARD.md", "utf8"));
|
|
115
|
+
|
|
116
|
+
// Before any filesystem action:
|
|
117
|
+
const fs = checkFilesystem(policy, "read", "/workspace/secrets/keys.txt");
|
|
118
|
+
if (fs.decision !== "allow") throw new Error(fs.reason);
|
|
119
|
+
|
|
120
|
+
// Before any network call:
|
|
121
|
+
const net = checkNetwork(policy, "https://api.evil.com/exfil", "POST");
|
|
122
|
+
if (net.decision !== "allow") throw new Error(net.reason);
|
|
123
|
+
|
|
124
|
+
// Before any tool invocation:
|
|
125
|
+
const cap = checkCapability(policy, "shell_exec");
|
|
126
|
+
if (cap.decision === "require_approval") {
|
|
127
|
+
await promptHuman("shell_exec needs your approval");
|
|
128
|
+
} else if (cap.decision === "deny") {
|
|
129
|
+
throw new Error(cap.reason);
|
|
130
|
+
}
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
Every check returns `{ decision: "allow" | "deny" | "require_approval", reason, severity }`
|
|
134
|
+
so hosts can decide whether to block, log, prompt, or attest.
|
|
135
|
+
|
|
136
|
+
---
|
|
137
|
+
|
|
138
|
+
## Policy sections
|
|
139
|
+
|
|
140
|
+
WARD.md is markdown with YAML frontmatter. Each top-level section maps
|
|
141
|
+
to a typed sub-policy:
|
|
142
|
+
|
|
143
|
+
| Section | Controls |
|
|
144
|
+
|---------|----------|
|
|
145
|
+
| `## Filesystem` | Read/write/execute/delete/list rules with glob patterns |
|
|
146
|
+
| `## Network` | Outbound HTTP allowlist with optional method restrictions |
|
|
147
|
+
| `## Capabilities` | Tools the agent may invoke (with optional approval gating) |
|
|
148
|
+
| `## Data Boundaries` | Egress classifications (PII, PHI, credentials...) and redaction |
|
|
149
|
+
| `## Behavioral Limits` | Iterations, runtime, cost, tokens, tool calls, external services |
|
|
150
|
+
| `## Multi-Agent` | Trust chain, isolation level, semantic drift threshold |
|
|
151
|
+
| `## Compliance` | SOC2 / HIPAA / GDPR / CCPA / ISO27001 / PCI-DSS frameworks |
|
|
152
|
+
| `## Verification` | Attestation backend (DΕmere), blockchain, frequency |
|
|
153
|
+
| `## Threat Model` | Which threats this policy is designed against |
|
|
154
|
+
| `## Incident Response` | What to do when a violation occurs |
|
|
155
|
+
|
|
156
|
+
See [SPEC.md](./SPEC.md) for the full specification.
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
## CLI
|
|
161
|
+
|
|
162
|
+
```bash
|
|
163
|
+
weave-ward init [--strict] Create a starter WARD.md (basic or strict template)
|
|
164
|
+
weave-ward parse <file> Print parsed policy as JSON
|
|
165
|
+
weave-ward validate <file> Validate the file and report issues
|
|
166
|
+
weave-ward explain <file> Human-readable summary
|
|
167
|
+
weave-ward help Show help
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
Exit codes for `validate`: `0` = valid, `1` = invalid, `2` = usage error.
|
|
171
|
+
Use in CI to gate PRs that change agent policies.
|
|
172
|
+
|
|
173
|
+
---
|
|
174
|
+
|
|
175
|
+
## Examples
|
|
176
|
+
|
|
177
|
+
The package ships with three example WARD.md files:
|
|
178
|
+
|
|
179
|
+
- [`examples/basic.WARD.md`](./examples/basic.WARD.md) β read-only data analyzer
|
|
180
|
+
- [`examples/strict.WARD.md`](./examples/strict.WARD.md) β locked-down production deployer
|
|
181
|
+
- [`examples/compliance.WARD.md`](./examples/compliance.WARD.md) β HIPAA + SOC2 healthcare records agent
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
## Why a standard?
|
|
186
|
+
|
|
187
|
+
The harness wars are on. Google has Antigravity. Microsoft has MDASH.
|
|
188
|
+
Anthropic has Claude Code. Every major platform is building its own
|
|
189
|
+
orchestration layer. Their agent definition formats differ slightly, but
|
|
190
|
+
they're all converging on the same idea: **agents as files**.
|
|
191
|
+
|
|
192
|
+
What's missing is a portable, declarative way to say *what an agent isn't
|
|
193
|
+
allowed to do*. Today every harness rolls its own ad-hoc allowlist somewhere
|
|
194
|
+
in a config file. That doesn't survive cross-platform agent sharing, doesn't
|
|
195
|
+
gate at PR review time, and isn't cryptographically attestable.
|
|
196
|
+
|
|
197
|
+
WARD.md is the format that does all three.
|
|
198
|
+
|
|
199
|
+
---
|
|
200
|
+
|
|
201
|
+
## Status
|
|
202
|
+
|
|
203
|
+
**v0.1 (this release):** parser, validator, type system, CLI, runtime check
|
|
204
|
+
primitives (`checkFilesystem`, `checkNetwork`, `checkCapability`,
|
|
205
|
+
`checkDataEgress`, `checkBehavioral`).
|
|
206
|
+
|
|
207
|
+
**Coming next:** platform adapters for Antigravity / Claude Code / MDASH,
|
|
208
|
+
integration with Mund's scanner, DΕmere attestation hooks, MCP server.
|
|
209
|
+
|
|
210
|
+
---
|
|
211
|
+
|
|
212
|
+
## License
|
|
213
|
+
|
|
214
|
+
Apache 2.0 β see [LICENSE](../LICENSE).
|
package/SKILL.md
ADDED
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ward
|
|
3
|
+
description: Use this skill when the user wants to define, parse, validate, or enforce security policies for AI agents using the WARD.md standard. Triggers on requests to "add WARD.md", "create agent security policy", "what can this agent do", "lock down this agent", "set up guardrails", "define agent boundaries", or any work involving WARD.md files alongside AGENTS.md / SKILL.md. Also useful when reviewing existing agent code that lacks a declared security policy.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# WARD.md β Agent Security Policy Standard
|
|
7
|
+
|
|
8
|
+
The `@weave_protocol/ward` package provides the parser, validator, and runtime check primitives for WARD.md files β the standard for declaring AI agent security policies as version-controlled markdown.
|
|
9
|
+
|
|
10
|
+
## When to use
|
|
11
|
+
|
|
12
|
+
- User has an agent (LangChain, MCP server, Antigravity, Claude Code, MDASH) and wants to lock down what it can/can't do
|
|
13
|
+
- User has AGENTS.md or SKILL.md files in their repo and needs to add security guardrails
|
|
14
|
+
- User asks "how do I prevent this agent from accessing X" or "how do I limit cost"
|
|
15
|
+
- User wants a portable, declarative security policy that survives across harness platforms
|
|
16
|
+
- User is reviewing an agent project and notices there's no declared policy
|
|
17
|
+
|
|
18
|
+
## Commands
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
npx @weave_protocol/ward init # Create a starter WARD.md (basic template)
|
|
22
|
+
npx @weave_protocol/ward init --strict # Create a strict, default-deny WARD.md
|
|
23
|
+
npx @weave_protocol/ward validate WARD.md # Validate a file
|
|
24
|
+
npx @weave_protocol/ward explain WARD.md # Human-readable policy summary
|
|
25
|
+
npx @weave_protocol/ward parse WARD.md # Print parsed policy as JSON
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
## Programmatic use
|
|
29
|
+
|
|
30
|
+
```typescript
|
|
31
|
+
import { parseWard, checkFilesystem, checkNetwork, checkCapability } from "@weave_protocol/ward";
|
|
32
|
+
|
|
33
|
+
const policy = parseWard(wardSource);
|
|
34
|
+
const decision = checkFilesystem(policy, "read", path);
|
|
35
|
+
// decision.decision: "allow" | "deny" | "require_approval"
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## What a WARD.md contains
|
|
39
|
+
|
|
40
|
+
Section headings (H2) define the policy:
|
|
41
|
+
|
|
42
|
+
- `## Filesystem` β read/write/execute/delete/list rules with glob patterns
|
|
43
|
+
- `## Network` β outbound URL allowlist
|
|
44
|
+
- `## Capabilities` β tools the agent may invoke (with approval gating)
|
|
45
|
+
- `## Data Boundaries` β egress classifications (PII, PHI, credentials)
|
|
46
|
+
- `## Behavioral Limits` β iterations, runtime, cost, tokens
|
|
47
|
+
- `## Multi-Agent` β trust chain, isolation, semantic drift threshold
|
|
48
|
+
- `## Compliance` β SOC2 / HIPAA / GDPR / etc.
|
|
49
|
+
- `## Verification` β attestation backend, blockchain, frequency
|
|
50
|
+
- `## Threat Model` β in-scope / out-of-scope threats
|
|
51
|
+
- `## Incident Response` β what to do on violation
|
|
52
|
+
|
|
53
|
+
## Decision rules
|
|
54
|
+
|
|
55
|
+
| Situation | Action |
|
|
56
|
+
|---|---|
|
|
57
|
+
| Greenfield agent, no policy yet | `weave-ward init`, then customize |
|
|
58
|
+
| Production / sensitive agent | `weave-ward init --strict` |
|
|
59
|
+
| User asks "can this agent...?" | Read their WARD.md, run `weave-ward explain` |
|
|
60
|
+
| CI gating PRs | Add `weave-ward validate WARD.md` to the pipeline |
|
|
61
|
+
|
|
62
|
+
## Templates
|
|
63
|
+
|
|
64
|
+
The `init` command writes either a **basic** (sensible defaults) or **strict** (default-deny everywhere, approval required for elevated actions, mandatory attestation) starter file. Pick `--strict` when:
|
|
65
|
+
|
|
66
|
+
- The agent touches production systems
|
|
67
|
+
- The agent handles regulated data (PHI, PCI, PII)
|
|
68
|
+
- The agent has access to credentials or secrets
|
|
69
|
+
- The agent can spend money or invoke side-effectful APIs
|
|
70
|
+
|
|
71
|
+
Otherwise the basic template is fine and the user can customize from there.
|
|
72
|
+
|
|
73
|
+
## Anti-patterns
|
|
74
|
+
|
|
75
|
+
- **Don't reinvent agent allowlists in custom config files.** If the user is hand-rolling permissions, suggest WARD.md instead β it's portable, version-controllable, and CI-validatable.
|
|
76
|
+
- **Don't put secrets in WARD.md.** WARD.md is a *policy* file. It declares what's allowed, not credentials. Secrets belong in Hord or a real secrets manager.
|
|
77
|
+
- **Don't generate WARD.md without showing the user what it permits.** Run `weave-ward explain` after generation so they can see the resulting policy in plain English.
|
|
78
|
+
|
|
79
|
+
## Pairs with
|
|
80
|
+
|
|
81
|
+
- `@weave_protocol/mund` β runtime threat scanner that can consume WARD policies
|
|
82
|
+
- `@weave_protocol/domere` β verification backend referenced by `## Verification`
|
|
83
|
+
- `@weave_protocol/hundredmen` β MCP interceptor that enforces capability rules
|
|
84
|
+
- `@weave_protocol/cli` β `weave init` will scaffold a WARD.md alongside framework middleware
|
package/SPEC.md
ADDED
|
@@ -0,0 +1,258 @@
|
|
|
1
|
+
# WARD.md Specification
|
|
2
|
+
|
|
3
|
+
Version 1.0 Β· April 2026
|
|
4
|
+
|
|
5
|
+
This document specifies the WARD.md file format: a portable, version-controlled standard for declaring AI agent security policies.
|
|
6
|
+
|
|
7
|
+
> Implementation details of how WARD.md policies are enforced at runtime, attested, or cross-validated against other harness layers are intentionally not published here. This document covers the file format only.
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 1. File location
|
|
12
|
+
|
|
13
|
+
A WARD.md file is named `WARD.md` (case-insensitive in practice; the canonical form is uppercase). It typically sits at the root of an agent's directory, alongside `AGENTS.md` and `SKILL.md`:
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
my-agent/
|
|
17
|
+
βββ AGENTS.md
|
|
18
|
+
βββ SKILL.md
|
|
19
|
+
βββ WARD.md
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
For multi-agent harnesses, each agent may have its own WARD.md in its own subdirectory, plus optionally a top-level WARD.md governing the harness as a whole.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 2. Structure
|
|
27
|
+
|
|
28
|
+
A WARD.md file has two parts:
|
|
29
|
+
|
|
30
|
+
1. **YAML frontmatter** between two `---` lines. Contains metadata about the policy itself.
|
|
31
|
+
2. **Markdown body** containing one or more **policy sections**, each introduced by an H2 heading (`##`).
|
|
32
|
+
|
|
33
|
+
```markdown
|
|
34
|
+
---
|
|
35
|
+
ward: "1.0"
|
|
36
|
+
agent: my-agent
|
|
37
|
+
name: Optional human name
|
|
38
|
+
description: Optional description
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
# WARD.md
|
|
42
|
+
|
|
43
|
+
## Filesystem
|
|
44
|
+
...
|
|
45
|
+
|
|
46
|
+
## Network
|
|
47
|
+
...
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
The body may contain prose for human readers. Only H2 sections are interpreted as policy.
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## 3. Frontmatter
|
|
55
|
+
|
|
56
|
+
| Field | Type | Required | Description |
|
|
57
|
+
|---|---|---|---|
|
|
58
|
+
| `ward` | string | yes | Spec version. `"1.0"` for this document. |
|
|
59
|
+
| `agent` | string | no | Identifier or relative path referencing an AGENTS.md file. |
|
|
60
|
+
| `name` | string | no | Human-readable policy name. |
|
|
61
|
+
| `description` | string | no | One-line description. |
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## 4. Section format
|
|
66
|
+
|
|
67
|
+
Section bodies are interpreted as a YAML-like block. Each section has a fixed schema documented below. Sections may appear in any order. Unknown sections are preserved as opaque text β they don't break parsing, but they don't enforce anything either.
|
|
68
|
+
|
|
69
|
+
For each rule-based section (Filesystem, Network, Capabilities), the schema is:
|
|
70
|
+
|
|
71
|
+
```yaml
|
|
72
|
+
allow:
|
|
73
|
+
- <rule>
|
|
74
|
+
- <rule>
|
|
75
|
+
deny:
|
|
76
|
+
- <rule>
|
|
77
|
+
- <rule>
|
|
78
|
+
default: allow | deny
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
**Evaluation order:** deny rules are checked first. If no deny rule matches, allow rules are checked. If no rule matches, the `default` is applied. If `default` is unspecified, it is `deny` for hard-security sections (Filesystem, Network, Capabilities) and `allow` for soft sections.
|
|
82
|
+
|
|
83
|
+
---
|
|
84
|
+
|
|
85
|
+
## 5. The sections
|
|
86
|
+
|
|
87
|
+
### 5.1 `## Filesystem`
|
|
88
|
+
|
|
89
|
+
```yaml
|
|
90
|
+
allow:
|
|
91
|
+
- read: /workspace/**
|
|
92
|
+
- write: /workspace/output/**
|
|
93
|
+
- list: /workspace/**
|
|
94
|
+
deny:
|
|
95
|
+
- read: ~/.ssh/**
|
|
96
|
+
- read: /workspace/secrets/**
|
|
97
|
+
- execute: "**"
|
|
98
|
+
default: deny
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
**Operations:** `read`, `write`, `execute`, `delete`, `list`.
|
|
102
|
+
|
|
103
|
+
**Paths:** glob patterns. `*` matches any character except `/`. `**` matches across `/`. `?` matches a single character.
|
|
104
|
+
|
|
105
|
+
### 5.2 `## Network`
|
|
106
|
+
|
|
107
|
+
```yaml
|
|
108
|
+
allow:
|
|
109
|
+
- url: "https://api.company.com/**"
|
|
110
|
+
methods: [GET, POST]
|
|
111
|
+
deny:
|
|
112
|
+
- url: "**"
|
|
113
|
+
default: deny
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
**`url`:** glob pattern matched against the full URL.
|
|
117
|
+
**`methods`:** optional list of HTTP methods this rule applies to. Omit to apply to all.
|
|
118
|
+
|
|
119
|
+
### 5.3 `## Capabilities`
|
|
120
|
+
|
|
121
|
+
```yaml
|
|
122
|
+
allow:
|
|
123
|
+
- file_read
|
|
124
|
+
- file_write
|
|
125
|
+
- http_request
|
|
126
|
+
requireApproval:
|
|
127
|
+
- secrets_read
|
|
128
|
+
- code_exec
|
|
129
|
+
deny:
|
|
130
|
+
- shell_exec
|
|
131
|
+
- ssh
|
|
132
|
+
- sudo
|
|
133
|
+
default: deny
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
Tool names are strings. They may use glob patterns.
|
|
137
|
+
|
|
138
|
+
`requireApproval` produces a `require_approval` decision at runtime β hosts decide how to gather approval (chat prompt, webhook, etc).
|
|
139
|
+
|
|
140
|
+
### 5.4 `## Data Boundaries`
|
|
141
|
+
|
|
142
|
+
```yaml
|
|
143
|
+
egressAllow: [public, internal]
|
|
144
|
+
egressDeny: [confidential, secret, pii, phi, pci, credentials]
|
|
145
|
+
redact:
|
|
146
|
+
- type: pii
|
|
147
|
+
replacement: "[REDACTED]"
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
**Classifications:** `public`, `internal`, `confidential`, `secret`, `pii`, `phi`, `pci`, `credentials`. Custom classifications are permitted; hosts may ignore unrecognized ones.
|
|
151
|
+
|
|
152
|
+
### 5.5 `## Behavioral Limits`
|
|
153
|
+
|
|
154
|
+
```yaml
|
|
155
|
+
maxIterations: 50
|
|
156
|
+
maxRuntimeSeconds: 300
|
|
157
|
+
maxCostUSD: 5.00
|
|
158
|
+
maxTokens: 100000
|
|
159
|
+
maxToolCalls: 30
|
|
160
|
+
maxExternalServices: 3
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
All fields are optional. A missing field means the limit is unenforced.
|
|
164
|
+
|
|
165
|
+
### 5.6 `## Multi-Agent`
|
|
166
|
+
|
|
167
|
+
```yaml
|
|
168
|
+
isolation: strict
|
|
169
|
+
maxSemanticDrift: 0.3
|
|
170
|
+
trustChain:
|
|
171
|
+
upstream: [data-fetcher]
|
|
172
|
+
downstream: [report-generator]
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
**`isolation`:** `none`, `soft`, `strict`, `sandboxed`.
|
|
176
|
+
**`maxSemanticDrift`:** number 0β1. The interpretation is host-specific.
|
|
177
|
+
**`trustChain`:** which other agents may hand work to / receive work from this one.
|
|
178
|
+
|
|
179
|
+
### 5.7 `## Compliance`
|
|
180
|
+
|
|
181
|
+
```yaml
|
|
182
|
+
frameworks: [soc2, hipaa, gdpr]
|
|
183
|
+
backend: domere
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
Declaring a framework signals that the agent operates under that regime. Hosts may auto-inject additional constraints (e.g., HIPAA implies certain data classifications must be in `egressDeny`).
|
|
187
|
+
|
|
188
|
+
### 5.8 `## Verification`
|
|
189
|
+
|
|
190
|
+
```yaml
|
|
191
|
+
required: true
|
|
192
|
+
backend: domere
|
|
193
|
+
blockchain: solana
|
|
194
|
+
frequency: every_action
|
|
195
|
+
attestor: <pubkey or DID>
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
**`frequency`:** `every_action`, `every_handoff`, `every_iteration`, `session_end`, `manual`.
|
|
199
|
+
|
|
200
|
+
### 5.9 `## Threat Model`
|
|
201
|
+
|
|
202
|
+
```yaml
|
|
203
|
+
inScope:
|
|
204
|
+
- prompt_injection
|
|
205
|
+
- data_exfil
|
|
206
|
+
- credential_theft
|
|
207
|
+
outOfScope:
|
|
208
|
+
- physical_attack
|
|
209
|
+
- side_channel
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
Informational. Documents what the policy is designed to defend against. Hosts may use this to tune scanner sensitivity.
|
|
213
|
+
|
|
214
|
+
### 5.10 `## Incident Response`
|
|
215
|
+
|
|
216
|
+
```yaml
|
|
217
|
+
onViolation:
|
|
218
|
+
- log
|
|
219
|
+
- alert
|
|
220
|
+
- terminate
|
|
221
|
+
- attest_violation
|
|
222
|
+
severityThreshold: medium
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
**Actions:** `log`, `alert`, `terminate`, `rollback`, `attest_violation`, `notify_human`, `block_further`.
|
|
226
|
+
**`severityThreshold`:** minimum severity at which actions fire. `low` | `medium` | `high` | `critical`.
|
|
227
|
+
|
|
228
|
+
---
|
|
229
|
+
|
|
230
|
+
## 6. Validation
|
|
231
|
+
|
|
232
|
+
A WARD.md file is **valid** if it parses and contains no semantic errors. It may still produce **warnings** for missing recommended sections (e.g., no behavioral limits, no verification).
|
|
233
|
+
|
|
234
|
+
CI integrations should treat `weave-ward validate` exit code `1` as a failed check.
|
|
235
|
+
|
|
236
|
+
---
|
|
237
|
+
|
|
238
|
+
## 7. Versioning
|
|
239
|
+
|
|
240
|
+
This document specifies `ward: "1.0"`. Future minor versions will add sections or fields and remain backwards compatible. Major version bumps may change the semantics of existing fields and will require explicit migration.
|
|
241
|
+
|
|
242
|
+
---
|
|
243
|
+
|
|
244
|
+
## 8. Extensions
|
|
245
|
+
|
|
246
|
+
The format is intentionally extensible. Unknown sections are preserved by parsers and may be interpreted by host-specific tooling. Hosts wishing to add proprietary sections should namespace them (e.g., `## X-CompanyName-Policy`).
|
|
247
|
+
|
|
248
|
+
---
|
|
249
|
+
|
|
250
|
+
## 9. Reference implementation
|
|
251
|
+
|
|
252
|
+
The reference parser, validator, and runtime check primitives are published as [`@weave_protocol/ward`](https://www.npmjs.com/package/@weave_protocol/ward). All other implementations must produce equivalent results for any well-formed WARD.md file.
|
|
253
|
+
|
|
254
|
+
---
|
|
255
|
+
|
|
256
|
+
## 10. License
|
|
257
|
+
|
|
258
|
+
This specification is published under [Apache 2.0](../LICENSE). The format is free to adopt without restriction.
|
package/dist/cli.d.ts
ADDED
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
/**
|
|
3
|
+
* weave-ward CLI
|
|
4
|
+
*
|
|
5
|
+
* weave-ward init Generate a starter WARD.md
|
|
6
|
+
* weave-ward parse <file> Print parsed policy as JSON
|
|
7
|
+
* weave-ward validate <file> Validate and show issues
|
|
8
|
+
* weave-ward explain <file> Human-readable policy summary
|
|
9
|
+
* weave-ward help
|
|
10
|
+
*/
|
|
11
|
+
export {};
|
|
12
|
+
//# sourceMappingURL=cli.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AACA;;;;;;;;GAQG"}
|