Zero-Trust Architecture

Trust Nothing on the Network

Network perimeters that assume internal traffic is trusted are a design choice adversaries have learned to exploit. Zero trust is the counter-design — and it is not a product. No single technology, product, or service achieves a zero-trust architecture; it is a set of principles, codified in NIST SP 800-207 and the CISA Zero Trust Maturity Model, that must be engineered into infrastructure and workflows across every pillar of the enterprise: identity, devices, networks, applications and workloads, and data. Wilkes & Liberty applies zero trust that way — across the network fabric, the identities that authenticate to it, the devices that connect to it, the secrets that protect it, the AI agents that increasingly act on it, and the operational and compliance disciplines that keep it defensible over time. This is not a product recommendation; it is how we run our own production estate, and every control we implement for you is one we operate ourselves.

The Tenets We Engineer To

NIST SP 800-207 defines seven tenets, and they are worth taking literally. Every data source and computing service is a resource. All communication is secured regardless of network location — internal traffic earns no exemption. Access is granted per session, decided by dynamic policy rather than standing entitlement, and authentication and authorization are strictly enforced before access is allowed, never after. The integrity and security posture of every owned and associated asset is continuously monitored and measured, and the enterprise collects as much information as it can about the state of its assets, infrastructure, and communications — then uses it to improve its posture. In most strategy documents these tenets read as aspirations. In our practice, each one resolves to a specific control with a specific owner. The sections below show where.

What We Implement

• Deny-by-default network policy as code — encrypted mesh networking with explicit, group-based access grants managed in version-controlled Terraform, validated by policy tests before every apply, so no device reaches a service without a reviewable rule saying it may — and no traffic, internal included, moves unencrypted.
• Boundary and segment isolation — split DNS that keeps internal service names unresolvable from outside the boundary, public ingress confined to hardened reverse proxies in a separate segment, and VLAN segmentation that blocks lateral movement between trust zones, including egress-only zones for untrusted devices — across IPv4 and IPv6 alike.
• Continuous device inventory and posture — a dynamic inventory of every asset that can touch the network, including its hardware, software, firmware, configurations, and associated vulnerabilities as they become known, with continual patching rather than intermittent remediation.
• Layered authorization — network-level access control, identity-aware proxy gates that evaluate group claims per host, per-environment authentication clients, and local credentials, so a single compromised layer does not grant access.
• Secrets under your key material — full-lifecycle secrets management with encryption machine-enforced before commit, runtime-only decryption, and push-blocking secret scanning in the delivery pipeline.
• Governed agent access — least-privilege, auditable control over what AI agents may read, write, and never do inside your systems of record.

Identity That Enforces Least Privilege

Network controls govern how traffic flows; identity governs who may authenticate and what they may reach once connected. Without secure, enterprise-managed identity, adversaries take over accounts and gain a foothold — which is why the federal strategy directs agencies to consolidate identity systems so protections and monitoring apply consistently, and why its objective is worth stating plainly: the right access to the right resources at the right time for the right purpose, without excessive standing privilege, for people and non-person entities alike. We design identity and access-management architectures on customer-controlled OIDC infrastructure with multi-factor enforcement, group-based authorization evaluated at the proxy layer, and strict per-environment client isolation — a credential issued for staging is structurally useless against production. Because clients are isolated and secrets are rotated on defined procedures, revocation is a routine operation rather than a crisis: retiring a client invalidates every credential ever issued against it. Security and usability work together in support of the mission — single sign-on makes the compliant path the convenient one.

Devices You Can Account For

A device is any asset that can connect to your network — servers, workstations, printers, mobile phones, IoT hardware, networking equipment, and the bring-your-own devices of employees, partners, and visitors. Zero trust requires each to be identified, inventoried, authorized, and authenticated on a regular basis, not vetted once and trusted thereafter. We maintain that discipline at the fabric: managed devices hold explicit, revocable grants; devices that are authorized but not enterprise-controlled are risk-managed with constrained access; and unrecognized devices are confined to egress-only zones where they can reach the internet but nothing of yours. Because the inventory is dynamic — tracking configuration and vulnerability state as it changes, not as it was last audited — patching is a continuous function rather than a periodic event.

Secrets Under Your Key Material

Credentials embedded in repositories or passed as plaintext are a persistent source of risk. We implement secrets management across the full credential lifecycle using SOPS with AGE encryption — a self-hosted, vendor-independent pattern that requires no third-party vault or cloud key-management service and keeps encrypted secrets under key material you hold. Encryption is machine-enforced before a secret can enter version control, runtime decryption keeps plaintext off disk and out of configuration at rest, secret scanning with push protection prevents credentials from entering the repository, and defined key-lifecycle procedures govern generation, access, rotation, and compromise handling.

Applications That Assume a Hostile Network

Applications can no longer rely on perimeter protections to guard against unauthorized access — the working assumption, per the federal strategy, is that every application is internet-accessible from a security perspective, whether or not it is today. So users log into applications, not networks: identity-aware gates evaluate authorization per request, and security controls sit close to the application, the workload, and the data rather than at a distant perimeter. Workloads — including containers and virtual machines in cloud environments — are continuously monitored and secured, and delivery follows DevSecOps and CI/CD best practice with immutable workloads where possible, enforced through our DevSecOps practice. We also scrutinize applications the way adversaries do: adversaries test your security continuously, so in addition to robust internal testing, real-world evaluation deserves independent perspectives and a coordinated path for vulnerability disclosure.

Data on a Need-to-Know Basis

Data is the asset every other pillar exists to protect — structured and unstructured, live and backed up, on-premises and virtual, along with its metadata. Protection starts with knowing what you hold: we help you inventory, categorize, and label data so that isolation becomes possible and access can be granted on a genuine need-to-know basis, whether the requester is a person or a workload. Data is encrypted at rest and in transit, mechanisms are deployed to detect and stop exfiltration, and data-governance policies are crafted and reviewed so lifecycle security is actually enforced across the enterprise — not just written down.

Zero-Trust for AI Agents

AI agents are a new class of privileged actor, and most organizations grant them more access than they would ever grant a contractor. We extend zero-trust to the agent plane: agents authenticate with scoped, revocable OAuth credentials; per-role policy profiles gate every operation against entity allowlists and field-level redaction; publishing and other one-way-door actions remain structurally reserved for accountable humans; and every agent action is recorded in a tamper-evident, hash-chained audit log whose integrity can be verified on demand. We build and maintain this governance tooling as open source, and it runs in production on our own platforms — the systems we deliver are the systems we depend on. Our Agentic AI Development capability covers the delivery side of the same discipline.

Security as an Operational Condition

A defensible posture is an operational condition, not a project state. We establish an honest baseline of what is actually running and where the gaps are, execute hardening by priority — configuration, patching, access-control tightening — with documented evidence, and run vulnerability management as a continuous function with defined remediation windows, including same-day response for critical advisories. Incident-response readiness is engineered, not assumed: severity-tiered playbooks, triage procedures operators can execute under pressure, and structured exercises that validate the response before an incident makes the gaps visible.

This is also where the CISA model's three cross-cutting capabilities live. Visibility and analytics: the observable artifacts of your environment, collected and analyzed to inform policy decisions, speed response, and build a risk profile before an incident rather than after one. Automation and orchestration: security response functions connected across products and services, so defenses orient in real time — with human oversight retained where it matters. Governance: the policies, procedures, and enforcement that keep the right people, process, and technology aligned to mission, risk, and compliance objectives across every pillar.

Compliance You Can Hand an Assessor

Federal work requires a documented, defensible posture an assessor or contracting officer can evaluate at any point. We translate NIST 800-171 and CMMC requirements into durable artifacts — a System Security Plan mapped to your actual environment, a Plan of Action and Milestones with owners and realistic timelines, CUI handling procedures, and a tested incident-response plan — authored to withstand scrutiny and maintained as living documents as your environment and contract portfolio evolve. For agencies, we map implementation directly to the Federal Zero Trust Strategy (OMB M-22-09) and to maturity stages in the CISA Zero Trust Maturity Model, so progress stays legible to the people who measure it. We maintain this same artifact set for our own operations, so the templates you receive are instruments we keep current, not deliverables we generate once.

Start With the Baseline

Implementing a zero-trust architecture takes time and the deliberate integration of technologies, services, and products — the Federal Zero Trust Strategy gives agencies a place to start, and the first tenet gives everyone the same instruction: know what you have. The architecture above runs on infrastructure you control — see our Private Infrastructure practice for the environments beneath it. Contact us to scope an assessment of your current posture and the sequence that hardens it.