What “without overreach” means technically
A virtual network without overreach constrains access, observation, inference, intervention, retention, and policy power to the minimum scope needed for the stated purpose. It makes exceptional authority visible and reversible rather than treating security as permission to inspect everything.
VNWO does not deploy these controls. It publishes civic and architectural guidance that implementers can use when selecting, configuring, documenting, and reviewing their own systems.
Four recurring dimensions of overreach
Access overreach
A successful login or network position grants broader reach than the stated task requires. The safer pattern is per-resource, per-request, time-bounded authority.
Observational overreach
Monitoring collects payloads, metadata, identity links, or behavioral traces that are not necessary for the operational purpose.
Governance overreach
One operator can change policy, escalate monitoring, deanonymize participants, or widen privileges without visible review.
Retention and reuse overreach
Data gathered for one purpose becomes a durable dossier, training source, reputation label, or secondary analytics feed without renewed scope.
Reference decision and evidence flow
The public rule surface should map to a bounded technical flow. Each stage can stop, refuse, narrow, escalate, or revoke without silently widening the next stage.
- Actor and workload identityDisclose who or what is acting and who controls it.
- Policy decisionEvaluate resource, purpose, context, risk, scope, and expiry.
- Policy enforcementPermit only the requested resource and action; deny lateral reach.
- Minimal observabilityCollect the least revealing event or flow data needed for operations.
- Review and repairExpose decisions, escalation, error, appeal, and correction records.
- Revocation and exitDisable authority, account for retained evidence, and preserve portability.
Architecture patterns
Identity-aware access
- Minimum implementation
- Evaluate identity, resource, device or workload state, and declared purpose for each protected request.
- Stronger implementation
- Use short-lived, strongly bound user and workload credentials with explicit audience, scope, expiry, and revocation.
- Evidence to keep
- Access-policy record, token or certificate lifetime, decision log, revocation result.
Local feature extraction
- Minimum implementation
- Prefer local event or flow feature extraction instead of shipping raw payloads to a central observer.
- Stronger implementation
- Aggregate or redact locally, disclose feature classes, and keep an escalation path separate from default collection.
- Evidence to keep
- Telemetry inventory, data-flow map, feature list, retention schedule.
Metadata minimization
- Minimum implementation
- Treat identity, destination, timing, location, association, and endpoint metadata as sensitive.
- Stronger implementation
- Use split knowledge, purpose-limited identifiers, rotation, aggregation, and correlation barriers where feasible.
- Evidence to keep
- Metadata inventory, correlation analysis, identifier rotation policy.
Staged observability
- Minimum implementation
- Begin with the least revealing telemetry that can answer the operational question.
- Stronger implementation
- Use a monitoring ladder with time-bounded escalation, human approval, expiry, review, and explicit retirement.
- Evidence to keep
- Monitoring level, approval record, incident scope, expiry and deletion or retirement record.
Compartmentalized authority
- Minimum implementation
- Separate policy definition, enforcement, telemetry, key custody, and review roles.
- Stronger implementation
- Require multi-party approval for deanonymization, payload inspection, emergency privilege, or policy exceptions.
- Evidence to keep
- Role matrix, separation-of-duties policy, approval trail.
Exit-aware architecture
- Minimum implementation
- Design credentials, logs, memory, endpoints, and delegations so they can be exported, revoked, retired, or explained at exit.
- Stronger implementation
- Generate an exit packet that accounts for active authority, retained evidence, endpoint grants, agent delegation, and forkability.
- Evidence to keep
- Exit packet, revocation log, retention explanation, export manifest.
Technical threat-model worksheet
Use this worksheet before selecting controls. It separates the stated purpose from the authority, observation, inference, retention, escalation, repair, revocation, and exit powers the design would create.
| Field | Question | Evidence to keep |
|---|---|---|
| Actor | Who or what acts, and who is accountable for it? | Disclosure profile and responsible-party record. |
| Resource and purpose | Which exact resource and action are needed for which stated outcome? | Resource inventory and purpose statement. |
| Authority | What may the actor do, delegate, publish, or change? | Authority envelope, expiry, and approval triggers. |
| Observation and inference | What can be seen or inferred, including metadata and correlation? | Telemetry and metadata inventory. |
| Retention and reuse | How long does evidence persist, and can it be reused elsewhere? | Retention schedule and secondary-use prohibition. |
| Escalation and repair | Who may widen visibility or authority, and how can an affected participant challenge error? | Escalation receipt, reason code, appeal and correction record. |
| Revocation and exit | How are authority, credentials, memory, endpoints, and evidence ended or exported? | Revocation result, exit packet, and retained-evidence explanation. |
Three worked cases
These cases show how the same civic rule becomes a bounded technical record. They are examples, not proof that VNWO deployed or audited the system.
Contractor access to one application
A contractor receives a short-lived credential for one inventory application. Unrelated subnets, exports, administrative functions, and behavioral scoring remain unavailable.
Open contractor access caseLocal agent with file memory
A disclosed local agent may review a bounded file handoff and call two scoped tools, but it cannot publish, access credentials, widen endpoint scope, or retain unexplained memory.
Open local agent caseCommunity incident observability
A community begins with aggregate health signals, escalates to incident-scoped flow fields after approval, and retires elevated evidence when the case closes.
Open incident observability caseWhat to centralize and what to compartmentalize
| Usually benefits from consistency | Usually creates overreach risk when centralized |
|---|---|
| Policy vocabulary, assurance levels, refusal codes, evidence fields, review deadlines. | Raw payloads, universal identity correlation, unrestricted telemetry, deanonymization keys. |
| Schema definitions and public rule versions. | Permanent behavioral dossiers and cross-context reputation labels. |
| Audit requirements and claim boundaries. | Single-party control of policy, enforcement, monitoring, appeals, and key custody. |
Technical architecture QA checklist
- Every access path names the resource, actor, purpose, scope, duration, and revocation path.
- Default observability does not require routine payload inspection.
- Metadata collection is inventoried, purpose-bound, retained briefly, and protected against unnecessary correlation.
- Policy changes and exceptional escalations leave visible, reviewable evidence.
- Workload identities and human credentials are short-lived rather than ambient and permanent.
- The design preserves repair, appeal, exit, and forkability rather than treating security as unilateral control.
- Public copy says these are architecture patterns, not a VNWO implementation, audit, certification, or compliance guarantee.
Long-term research sources
The complete technical reports are retained as source evidence. They inform this page but are not automatically adopted as VNWO doctrine.