Information-defense application
Protection that reports what is actually protected.
Citadel coordinates network and endpoint defenses around an approved information journey, keeping configured architecture, observed state, deployment, and qualification separate.
IBERION PORTFOLIOCitadelInformation-defense application
Reduce single-control and single-route security dependence
Make defense state observable by responsibility
Preserve containment, recovery, and incident evidence
The system in context
Information defense architecture.
What it delivers
Capability, made specific.
ADDR private destination mapping
Abuse defense and bounded containment
Privacy-minimized evidence logging
Obscura screen and device privacy
Two-Hop ingress and egress separation
Signature technology · Two Hop
One customer connection. Two independently defended network positions.
Citadel’s optional Two-Hop mode separates the gateway that receives the customer connection from the gateway that presents public Internet egress. The client still uses one approved tunnel—there is no second client VPN to manage.
Customer deviceOne encrypted tunnel
Encrypted
Citadel ingressCustomer-facing gatewayAuthenticates peers and selects the governed route
Inter-hop
Citadel egressInternet-facing gatewayRing 8 defense, forwarding, NAT, and public egress
Protected
DestinationInternet service
The entry gateway owns authenticated peer admission, route-class selection, continuity state, and the encrypted inter-gateway path.
The second gateway owns forwarding, public egress, aggregate data-plane evidence, and infrastructure-level containment.
Separating ingress from egress reduces an ordinary single-position observer’s ability to reconstruct the complete route. It is not a promise of absolute anonymity or legal untraceability.
Citadel Ring 7 · Obscura
Protection that continues after information reaches the screen.
Obscura reduces unauthorized screen copying and information leakage on protected Android and Android TV surfaces. It complements Citadel’s network journey; it is not another VPN layer.
Citadel Ring 9 · ADDR
Name the destination privately. Let Citadel make the connection.
ADDR—the Anonymous Destination Domain Register—lets you use a private trigger name for a destination you choose. Inside a Citadel-integrated client, that private name is translated to the real destination before the connection opens.
Your private trigger never goes to public DNS.The outside world sees the connection it must handle, not the private name you used to request it.
You control the destination map.The mapping is governed inside Citadel instead of becoming a public browsing label.
01 · You enterPrivate trigger nameMeaningful to you
02 · Citadel ADDRTrusted mappingPrivate trigger stays inside
03 · Connection opensReal destinationNormal DNS and TLS continue
Private trigger → never submitted to public DNS
ADDR is implemented across the canonical server and Android client. Integrated-client correction, authenticated smoke testing, rollback proof, and device qualification remain open. It minimizes disclosure and correlation outside the trusted boundary; it is not a claim of absolute anonymity or untraceability.
Deployment and commercial shape
Fit the operating environment.
Embedded network and endpoint defense
Standalone one-gateway mode
Optional two-hop deployment
Backend/platform or managed-service form
Current evidence boundary
What can be said now.
Evidence is assigned ring by ring. ADDR is implemented, with deployment qualification still in progress; other rings retain their own deployment or qualification boundaries. Citadel must not be described as wholly deployed, universally qualified, or independently certified.
Portfolio publications
Written about the system, in public.
These are the existing Iberion and Meridian articles most directly related to this capability. They establish the portfolio’s published problem framing and architectural thesis; they are first-party publications, not independent certification.
Iberion / Meridian public writingWeek 9: Why AI Needs Governance LayersRuntime AI governanceRead article ↗Iberion / Meridian public writingWeek 12: The System Nervous System — When Platforms Learn to SteerSensing, coordination, and operational feedbackRead article ↗Iberion / Meridian public writingWeek 16: Platform IntelligencePlatform-intelligence maturityRead article ↗Iberion / Meridian public writingWeek 18: Your AI Stack and YouEnterprise AI stack architectureRead article ↗
Standards and external context
Independent sources behind the problem space.
These standards, official references, and research sources provide external context. They do not independently verify Iberion implementation, deployment, performance, or qualification.
NISTNIST SP 800-207 — Zero Trust ArchitectureDefines zero-trust principles centered on users, assets, resources, authentication, authorization, and explicit trust decisions.Read publication ↗NISTNIST Cybersecurity Framework 2.0Provides a taxonomy of cybersecurity outcomes for understanding, assessing, prioritizing, and communicating risk management.Read publication ↗Android DevelopersAndroid Hardware-Backed Key AttestationExplains how to verify device-backed keys, attestation chains, security levels, signatures, and revocation status.Read publication ↗
Continue exploring