Server Security

Seven independent security layers — from transport encryption to jurisdiction enforcement. No centralized identity provider. No transitive trust chains. Every boundary crossing is cryptographically verified, structurally constrained, and fully auditable.

Design Philosophy

Most agent platforms bolt security on after the fact — add an OAuth scope here, a role check there. Weblisk takes the opposite approach: security is the architecture. Every protocol decision, from identity to data routing, was made with a single principle in mind — trust nothing you can't cryptographically verify.

• Self-sovereign identity — agents own their keys, not an external provider
• Non-transitive trust — A↔B and B↔C does not imply A↔C
• Fail-closed by default — missing data contracts, unknown fields, and unverified signatures all result in rejection
• Defence in depth — seven independent layers, any one of which can stop a threat

The Seven Security Layers

Each layer operates independently. A failure or bypass at one layer does not compromise the others. This is fundamentally different from token-based systems where a single compromised credential grants full access.

Self-Sovereign Identity Model

Traditional agent platforms delegate identity to a centralized identity provider (IdP). An agent authenticates with the IdP, receives a token, and presents that token to other agents. Weblisk eliminates this dependency entirely.

vs OIDC Federation

OIDC federation (as used in Google's Agent-to-Agent protocol, Microsoft Entra federated identity, and most enterprise SSO systems) relies on a centralized IdP issuing JWT tokens that agents present to each other. Trust is delegated to the IdP, and authorization is derived from scoped OAuth tokens.

Weblisk replaces this with a self-sovereign identity model using Ed25519 key pairs and custom WLT tokens. Here's how they compare:

vs OAuth 2.0 / Scoped Tokens

OAuth 2.0 is the de facto standard for API authorization. It works well for user-to-service delegation ("let this app read my calendar"). But it was never designed for autonomous agent-to-agent communication across organizational boundaries.

vs Zero Trust Architecture

Zero Trust ("never trust, always verify") is a security philosophy, not a protocol. Weblisk implements Zero Trust principles at the protocol level — and goes further.

vs mTLS / Service Mesh

Service meshes (Istio, Linkerd, Consul Connect) use mutual TLS to verify service identity at the transport layer. This is valuable — and Weblisk requires it too. But mTLS alone answers only one question: "Is this connection from a verified service?"

The Key Insight

Every comparison above reveals the same pattern. Traditional security systems answer one question:

"Is this agent allowed to talk to that agent?"

Weblisk answers that plus five more:

1. What data can cross this boundary? — Data contracts with field-level enforcement
2. Has this agent changed since we trusted it? — Manifest fingerprinting and behavioural classification
3. Is the data allowed in this jurisdiction? — Protocol-level residency checks before routing
4. Will the data be purged after processing? — Mandatory retention windows with automatic expiry
5. Can we cryptographically prove the entire exchange chain? — Dual Ed25519 signatures on every cross-boundary message

The data contract system in particular — required, permitted, and forbidden field sets with fail-closed enforcement — has no equivalent in OIDC, OAuth, or any mainstream service mesh. It makes data leakage structurally impossible rather than policy-dependent. That's a fundamentally harder guarantee than scoped tokens can provide.

Enterprise Standards Alignment

Weblisk's security architecture maps directly to the controls required by major enterprise compliance frameworks. The difference is that these controls are enforced at the protocol level, not bolted on as policy.

Security Best Practices

Key Management

• Rotate Ed25519 key pairs on a regular schedule — the protocol supports seamless key rotation without downtime
• Store private keys in hardware security modules (HSMs) or secure enclaves in production
• Never embed private keys in agent manifests or source code
• Use separate key pairs for different environments (development, staging, production)

Data Contracts

• Start with maximum restriction — use forbidden for all fields, then explicitly permit what's needed
• Review data contracts when agent capabilities change — behavioural integrity will flag breaking changes, but permitted field sets should be reviewed proactively
• Document the business justification for every permitted field in cross-organization contracts

Federation

• Audit federation peering agreements regularly — trust should be time-bounded, not permanent
• Monitor manifest fingerprint changes from federated partners — even benign changes deserve review
• Set retention windows to the minimum required for the business function
• Test jurisdiction enforcement with synthetic data before federating across regulatory boundaries