Agentprivacy armor progression

PVM-V4 Skill — Armor Progression

Source: Privacy Value Model V4 + First Person Spellbook Target context: Browser agent designers, progressive trust architects, capability gating systems, Sybil resistance engineers Architecture: agentprivacy.ai · Sync: sync.soulbis.com · Contact: [email protected]

---

What this is

The four-tier trust escalation protocol: Blade → Light → Heavy → Dragon. Not a feature unlock system. A conditional promise chain where each tier requires demonstrated sovereignty behaviour before the next becomes available. The progression itself is a trajectory through the sovereignty lattice — vertical transitions that activate new dimensions.

Referenced by every template but currently defined only inside swordsman_browser. This skill extracts the progression into a standalone protocol.

The four tiers

🗡️ Blade (Tier 0) — Zero trust. Starting position. The Swordsman has no relationship with any site. Every interaction is adversarial by default. The cursor becomes a chronicle — every click generates a log entry. No delegation. No cooperation. Pure observation.

Equation mapping: P = minimal (boundary exists but is raw), A(τ) = 0 (no verified history yet), T(π) = base (no transitions recorded). The agent exists but has done nothing.

Lattice position: Stratum 0 or 1. One dimension active at most (Protect only).

🛡️ Light (Tier 1) — Site coordination. The Swordsman recognises a single site as a cooperation partner. MyTerms negotiation begins — the agent proposes consent terms, the site responds. If terms are accepted, a bilateral relationship forms. Cookie management becomes selective rather than adversarial. The first VRC may be created.

Equation mapping: P increases (enforced consent terms), C > 0 (terms are verifiable), A(τ) begins accumulating (first attested transitions). First vertical transition: Protect + one additional dimension.

Lattice position: Stratum 2. Two dimensions active. The agent has begun to move.

Sybil resistance: Requires genuine site cooperation. A Sybil farm cannot generate real MyTerms acceptances from real sites. Time-gated — the progression from Blade to Light requires a minimum duration of demonstrated Blade-level behaviour.

⚔️ Heavy (Tier 2) — Multi-party locks. The Swordsman coordinates with multiple sites simultaneously. Association sets form — groups of sites that recognise each other's terms. Two-of-three locks become available (the Ancient Rule from FPS Act 8): three parties each hold a key, any two can authorise an action, but no single party can act alone.

Equation mapping: Network term activates (multiple coordinating agents), Φ(Σ) begins to be measurable (cross-force relationships emerge), R(d) becomes relevant (reconstruction resistance matters when multiple parties hold partial information).

Lattice position: Stratum 3–4. Three or four dimensions active. The agent is at or near the combinatorial midpoint — maximum network contribution weight.

Sybil resistance: Multi-party locks require real counterparties. A Sybil army cannot maintain consistent multi-site coordination over time without being detected by association set verification.

🐉 Dragon (Tier 3) — Ecosystem trust. Full sovereignty. The Swordsman operates as a recognised trust anchor in the wider ecosystem. Guild membership. VRC chains spanning multiple counterparties. The agent's trajectory T(π) is a verifiable credential in itself. Cross-chain operations via chain signatures. The agent can delegate to other agents (Mage-class) through VRC-mediated channels.

Equation mapping: All terms active. Full Φ(Σ) measurement. T(π) reflects a complex trajectory with both vertical and lateral transitions. The agent contributes maximum network weight at stratum 3–5.

Lattice position: Stratum 4–6. The agent has traversed multiple strata and its edge value T(π) is high.

Sybil resistance: Dragon-tier agents have deep, verifiable histories with diverse counterparties. The time investment and relationship breadth required make Sybil farming economically irrational.

The progression as conditional promise chain

Promise Theory framing: each tier is a conditional promise.

• "I promise Light behaviour if you demonstrate sustained Blade behaviour." (+/− polarity: the system offers the next tier, the agent accepts through demonstrated action.)
• "I promise Heavy capabilities if your Light relationships are attested and counterparties verify."
• "I promise Dragon recognition if your Heavy coordination history is verified across multiple association sets."

No tier can be purchased. No tier can be granted by authority. Each tier is earned through demonstrated promise-keeping, verified by cryptographic attestation. The promise chain is the architectural Sybil defence — you cannot fake time, and you cannot fake bilateral relationships.

Mapping to the equation

The progression activates equation terms in sequence:

Tier	Primary terms activated	New dimensions
Blade	P (raw)	Protect only
Light	P (enforced), C, A(τ) begins	+ one force (typically Project via consent terms)
Heavy	Network, Φ(Σ), R(d)	+ Reflect (temporal integral of Light decisions)
Dragon	T(π), full Φ(Σ), all forces	+ Connect (network effect of Heavy coordination)

The emergence of Reflect (from sustained Protect) and Connect (from sustained Project) maps directly to the Heavy → Dragon transition. These forces are not activated by declaration — they emerge from consistent trajectory.

Design principles

1. Progression is monotonic. Tiers are never revoked for inactivity — but the temporal decay term e^{-λt} erodes the value of stale tiers. A Dragon that stops operating decays toward Blade-level value without losing the label.
2. Time gates are non-negotiable. Minimum durations between tiers prevent rush-farming. The specific durations are uncalibrated but the principle is structural.
3. Counterparty verification is bilateral. Advancing from Light to Heavy requires counterparties to confirm the relationship, not just the agent to claim it.
4. The progression is per-context. An agent can be Dragon in one domain and Blade in another. Sovereignty is not global — it is domain-specific.

BRAID deployment maturity mapping

BRAID deployment maturity (arXiv:2512.15959) maps to armor progression:

Tier	BRAID Deployment
Blade	Ad-hoc reasoning, no cached graphs, monolithic model
Light	First BRAID graphs generated and cached, basic PPD improvement
Heavy	Guild-validated graph library, split-architecture, 10–30× PPD
Full Plate	Comprehensive coverage, dynamic re-planning, Numerical Masking
Dragon	Self-sustaining graph evolution, automated validation, BRAID Parity across all operations

Open problems

1. Optimal time gates between tiers — too short enables farming, too long discourages participation.
2. Whether tier regression (Dragon → Heavy through inactivity) should be explicit or only implicit through decay.
3. Cross-domain tier recognition — how much should Dragon status in domain A accelerate progression in domain B?
4. Measurement of the actual Sybil cost at each tier level.

---

Verify: agentprivacy.ai · sync.soulbis.com · github.com/mitchuski/agentprivacy-docs