Architecture is a claim. Validation is the evidence.

The problem

Enterprise segmentation often begins inside one technology domain. The harder problem appears when a user, device, or workload crosses from a traditional campus into SD-Access, a BGP EVPN/VXLAN fabric, SD-WAN, Meraki, the data center, or a cloud-connected environment. Each domain carries identity, distributes policy, and enforces decisions differently.

How do you preserve one segmentation intent while allowing each domain to use its own control plane and enforcement mechanism?

Role and reach

I designed a unified identity and policy approach across infrastructure domains, developed and presented proof-of-value environments, and produced a six-part Cisco Learning Network series with written guidance and embedded technical demonstrations. The work also became BRKENS-2823, presented at Cisco Live in Las Vegas and Melbourne in 2024.

Decisions that mattered

1. Separate intent from implementation. Cisco ISE and Security Group Tags provide a common policy vocabulary while each domain keeps its native control plane.
2. Design the boundaries first. Every handoff names where identity enters, how context propagates or translates, and which device enforces policy.
3. Include brownfield networks. Traditional Catalyst environments remain part of the architecture instead of becoming a migration prerequisite.
4. Treat cloud connectivity as part of the policy path. The design follows identity and enforcement beyond a campus-only frame.
5. Publish the implementation path. Reusable architecture requires configuration, validation, and troubleshooting guidance, not only a diagram.

Validation approach

• Verify endpoint classification and the expected Security Group Tag at authentication.
• Confirm that identity context survives each domain boundary.
• Check policy distribution separately from data-plane enforcement.
• Exercise explicit permit and deny cases across representative groups.
• Inspect the actual enforcement point and logs when behavior differs from intent.
• Repeat tests through WAN and cloud-connected paths.

What I carried forward

Multi-domain segmentation changed how I think about policy architecture. The policy itself is usually not the hardest part. The difficult work is preserving identity and intent while traffic crosses systems designed to make decisions differently. Every boundary needs an explicit translation, propagation, enforcement, and validation story.

Public proof

The problem

A prompt that tells an agent to be careful is not an enforceable security boundary. Infrastructure agents cross model behavior, credentials, tools, APIs, network devices, and operating processes. Failure at any one layer can turn a plausible recommendation into an outage.

How can an agent collect useful operational evidence and participate in action without treating confidence, permission, or prompt compliance as proof?

The architecture

I designed two complementary safety mechanisms. The first is a read-only orchestration contract enforced at the tool and connector boundary. The second is a Verify-Before-Act gate that identifies the fact on which a high-impact action depends, distinguishes verified facts from inference, and requires authoritative confirmation before execution.

Decisions that mattered

1. Enforce authority outside the model. Tool manifests, credentials, and interfaces define what the agent can do.
2. Make gaps first-class evidence. Partial domain failures remain visible instead of being converted into fluent certainty.
3. Separate permission from correctness. An agent can be authorized and still be wrong about the state that makes an action safe.
4. Require authoritative verification. The action gate checks the critical assumption against the system of record.
5. Design for refusal. A trustworthy operational system needs a clear stop state, not only a success path.

Validation approach

• Reject unlisted and state-changing tools outside the model.
• Introduce partial failures and verify that evidence gaps remain explicit.
• Construct adversarial cases where the model has permission but the critical assumption is wrong.
• Compare behavior across models so the control is not dependent on one model's prompt compliance.

Measured result

The published Verify-Before-Act evaluation reports that, across five models, the gate caught 41 of 41 harmful actions with no false alarms, operated at near-zero cost, and prevented a measured network outage on live hardware.

Public proof

The problem

Enterprise teams evaluating on-premises AI need more than compatible products. AI and retrieval-augmented generation workloads cross boundaries owned by different teams: GPU compute, storage, Kubernetes, the data-center fabric, workload security, model security, observability, and SecOps.

How do you build an enterprise AI platform in which every layer has a clear responsibility, enforcement point, observation path, and honest validation state?

System decisions that mattered

1. Treat the platform as a layered control system. Application, runtime, model protection, Kubernetes, compute, and network layers each have a defined responsibility.
2. Separate AI workload roles. Security-classifier workloads and user inference operate across inspectable cluster boundaries.
3. Build segmentation below workload identity. VXLAN-EVPN overlays establish infrastructure isolation while Cilium adds namespace, pod, and service policy.
4. Make model inspection a required path. Prompt and response inspection belongs at an enforced architectural chokepoint.
5. Preserve shared identity across operating planes. SRE and SecOps evidence can correlate without collapsing into one undifferentiated telemetry stream.
6. Record the boundary of proof. Validated, deployed, partial, known-issue, and roadmap states remain distinct.

Validation approach

• Validate the VXLAN-EVPN fabric, OpenShift platform, GPU runtime, and service advertisement independently before end-to-end tests.
• Verify model services are deployed and serving inference on the GPU platform.
• Test model inspection surfaces and retain failed or incomplete tests as visible findings.
• Verify workload identity, flow visibility, and runtime events across OpenShift security controls.
• Maintain a matrix that separates tested, deployed, partial, and future controls.

What the case proves

The public Cisco case study documents a lab-validated on-premises platform integrating GPU compute, OpenShift, NVIDIA AI Enterprise, Nexus VXLAN-EVPN, identity-based workload controls, model protection, and security analytics. Its most transferable lesson is that a validated design gains credibility by showing where proof stops.

Public proof