Pentagon Nears ‘Supply Chain Risk’ Designation for Anthropic in AI Use Clash

The U.S. Department of Defense is reportedly close to formally cutting business ties with Anthropic, the AI company behind the Claude language model, and may designate it as a “supply chain risk” — a severe classification usually reserved for foreign adversaries — amid a deepening dispute over how AI can be used by the U.S. military.

What’s Happening

According to Axios, senior Pentagon officials say Defense Secretary Pete Hegseth is nearing a decision to label Anthropic a supply chain risk, a move that would effectively force all U.S. defense contractors to sever ties with the company if they wish to continue working with the military.

This escalation stems from a standoff over usage restrictions that Anthropic has placed on Claude. While the Pentagon wants the flexibility to employ AI for “all lawful purposes,” including in classified military operations and battlefield decision-making, Anthropic has resisted broad use authorizations that could see its technology tied to mass surveillance of Americans or autonomous weapon systems.

Why It Matters

A supply chain risk designation is more than symbolic. It would legally require companies that do business with the Defense Department to certify they are not using Anthropic’s technology — meaning the Pentagon’s widest pool of contractors could potentially drop Claude from their systems. That outcome could reverberate far beyond military procurement: Anthropic has said Claude is in use at eight of the ten largest U.S. companies.

Importantly, Claude remains the only AI model currently cleared for use on some of the Pentagon’s classified networks, where it has been integrated as part of broader systems via contractors such as Palantir. The model was also reportedly used in a classified U.S. military operation earlier this year, though details remain limited and have been recently disputed in public statements.

Anthropic’s Stance

Anthropic has publicly emphasized its commitment to ethical guardrails — opposing uses of AI for mass civilian surveillance or for developing weapons that operate without human oversight. The company has indicated a willingness to negotiate on terms, but only where it can maintain safeguards aligned with its responsible-use principles.

Despite the friction, negotiations between the company and the Pentagon are reported to be ongoing, even as defense officials press for broader permissions.

Broader Implications

This dispute crystallizes a broader tension at the intersection of national security and AI ethics: military agencies seek expansive access to powerful AI tools in pursuit of operational advantage, while leading AI developers insist on guardrails to mitigate risks related to civil liberties, autonomous weapons, and unchecked surveillance.

Experts have long warned that the integration of AI into warfare and intelligence systems carries profound strategic, ethical, and legal consequences — spanning everything from command decision-making to civilian harm prevention. This standoff may mark a watershed moment in who ultimately shapes the rules governing AI’s role in national defense: tech companies, defense institutions, or lawmakers and regulators yet to act.

What Comes Next

At present the Pentagon has not publicly confirmed a final decision, and discussions continue behind closed doors. However, if a supply chain risk designation is finalized, it could dramatically reshape the landscape for AI companies and defense partnerships — with ripple effects across industry and government alike.

https://www.axios.com/2026/02/15/claude-pentagon-anthropic-contract-maduro

Designing a Metadata-Driven SharePoint Project Library with Automated Document Set Structure

Designing a Metadata-Driven SharePoint Project Library with Automated Document Set Structure.

1. Why Start with Metadata (Not Folders)

Most SharePoint project libraries fail for one reason:

They start with folders instead of metadata.

Folders solve navigation.
Metadata solves governance.

For a scalable project portfolio library, the structure must be driven by:

  • Project ID
  • Project Year
  • Portfolio Category
  • Project Type
  • Project Status
  • Client
  • Risk Level
  • Stage Gate

This allows:

  • View filtering (Active, Closed, Government, By Year)
  • Reporting
  • Automation
  • Lifecycle management
  • Future Power BI integration

Folders alone cannot do that.


2. Core Architecture

Site

Tanolis Projects

Library

Projects

Content Type

Document Set (for each project container)


3. Core Metadata Design

Create these site columns:

ColumnType
Project IDSingle line of text
Project YearChoice
Portfolio CategoryChoice
Project TypeChoice
Project StatusChoice
ClientSingle line
Risk LevelChoice
Stage GateChoice
Start DateDate
Target End DateDate

Attach these columns to the Document Set content type, not individual files.

This ensures:

  • Each project container carries structured metadata
  • Views operate on project-level attributes
  • Documents inherit metadata if configured

4. Why Document Set (Not Just Folder)

A Document Set is:

  • A special content type
  • A container with metadata
  • A logical project object

It behaves like a folder but supports:

  • Custom metadata
  • Welcome page
  • Shared columns
  • Governance workflows

A normal folder cannot do that.


5. Required SharePoint Configuration

Enable Document Sets

Site Settings → Site Collection Features
Activate Document Sets

Then:

Library Settings → Advanced Settings
✔ Allow management of content types

Add Document Set to the library.


6. The Problem: Auto-Creating Subfolders Inside Each New Project

Goal:

When I create:

2026-003_ClientZ_NewApp

Power Automate should automatically create:

01-Contract Governance
02-Planning Design
03-Execution Delivery
04-Financials
05-Admin Closeout

Inside that Document Set.

No duplicate containers.
No root-level folder creation.
No accidental “Shared Documents” folder nesting.


7. The Correct Trigger (Important)

Use:

When a file is created (properties only)

Why?

Because:

  • A Document Set inside a document library is treated as a file/folder object.
  • “When an item is created” is for SharePoint lists.
  • Using the wrong trigger causes null content type errors and template failures.

Lock this in.


8. The Final Working Flow Design

Step 1 – Trigger

When a file is created (properties only)
Library: Projects


Step 2 – Condition

Check:

Content Type
is equal to
Document Set

No expressions.
No startsWith.
No ContentTypeId hacks.

Keep it clean.


Step 3 – Initialize Folder Array

Initialize variable:

Type: Array

[
"01-Contract Governance",
"02-Planning Design",
"03-Execution Delivery",
"04-Financials",
"05-Admin Closeout"
]

Step 4 – Apply to Each

Loop through the folder array.

Inside the loop:

Create new folder.


9. The Critical Folder Path Expression

This is where most implementations fail.

Correct expression:

concat(triggerOutputs()?['body/{Path}'], triggerOutputs()?['body/{FilenameWithExtension}'], '/', item())

Why this works:

From trigger output:

{Path} = Shared Documents/
{FilenameWithExtension} = foo set

Final path becomes:

Shared Documents/foo set/01-Contract Governance

Which means:

Folders are created inside the Document Set container — not in the root.


10. Common Mistakes (And Why They Fail)

❌ Using only Filename

concat(triggerOutputs()?['body/{FilenameWithExtension}'],'/',item())

Result:
Creates duplicate root folder or wrong nesting.


❌ Using ContentTypeId startsWith

Leads to:

startsWith expects string but got null

Because wrong trigger context.


❌ Using “When an item is created”

Causes:

  • Null content type
  • Condition failures
  • Inconsistent behavior

11. Handling Race Conditions

Sometimes folder creation hangs because:

The Document Set is not fully provisioned when the flow runs.

Solution:

Add a small Delay (5 seconds minimum on consumption plan).

Or use retry policy.


12. Optional Enhancements

You can extend this design to:

  • Auto-assign permissions based on Portfolio Category
  • Notify PM when project is created
  • Trigger approval workflow at Stage Gate change
  • Auto-create Teams channel per project
  • Sync metadata to Dataverse

13. Architectural Pattern Summary

What you built is:

✔ Metadata-first design
✔ Document Set container model
✔ Automated structural provisioning
✔ Governance-ready foundation

This scales to:

  • 10 projects
  • 100 projects
  • 1,000 projects

Without structural drift.


14. Final Design Philosophy

Folders are operational.
Metadata is strategic.

Document Sets give you both.

Power Automate enforces consistency.

Designing a Secure Home Lab with VLAN Segmentation and TLS Subdomain Separation Using Traefik

Modern home labs and small hosting environments often grow organically. New services are added over time, ports multiply, and TLS certificates become difficult to manage. Eventually, what started as a simple setup becomes hard to secure and maintain.

Over the last few years, I gradually evolved my lab environment into a structure that separates workloads, automates TLS, and simplifies routing using Traefik as a reverse proxy.

This article summarizes the architecture and lessons learned from running multiple Traefik instances across segmented networks with automated TLS certificates.


The Initial Problem

Typical home lab setups look like this:

service1 → host:9000
service2 → host:9443
service3 → host:8123
service4 → host:8080

Problems quickly appear:

  • Too many ports exposed
  • TLS certificates become manual work
  • Hard to secure services individually
  • Debugging routing becomes messy
  • Services mix across trust levels

As services increase, maintenance becomes harder.


Design Goals

The environment was redesigned around a few simple goals:

  1. One secure entry point for services
  2. Automatic TLS certificate management
  3. Network segmentation between service types
  4. Clean domain naming
  5. Failure isolation between environments
  6. Minimal ongoing maintenance

High-Level Architecture

The resulting architecture separates services using VLANs and domain zones.

Internet
    ↓
DNS
    ↓
Traefik Reverse Proxy Instances
    ↓
Segmented Service Networks

Workloads are separated by purpose and risk profile.

Example:

Secure VLAN → internal services
IoT VLAN → containers and test services
Application VLAN → development workloads

Each network segment runs its own services and routing.


Role of Traefik

Traefik serves as the gateway for services by handling:

  • HTTPS certificates (Let’s Encrypt)
  • Reverse proxy routing
  • Automatic service discovery
  • HTTPS redirects
  • Security headers

Instead of accessing services by ports, everything is exposed through HTTPS:

https://sonarqube.example.com
https://portainer.example.com
https://grafana.example.com

Traefik routes traffic internally to the correct service.


TLS Strategy: Subdomain Separation

Instead of creating individual certificates per service, services are grouped by domain zones.

Example zones:

*.dk.example.com
*.pbi.example.com
*.ad.example.com

Each zone receives a wildcard certificate.

Example services:

sonarqube.dk.example.com
traefik.dk.example.com
grafana.dk.example.com

Benefits:

  • One certificate covers many services
  • Renewal complexity drops
  • Let’s Encrypt rate limits avoided
  • Services can be added freely
  • Routing stays simple

Each Traefik instance manages certificates for its own domain zone.


Why Multiple Traefik Instances?

Rather than centralizing everything, multiple Traefik gateways are used.

Example:

  • Unraid services handled by one proxy
  • Docker services handled by another
  • Podman workloads handled separately

Benefits:

  • Failure isolation
  • Independent upgrades
  • Easier experimentation
  • Reduced blast radius during misconfiguration

If one gateway fails, others continue operating.


Operational Benefits Observed

After stabilizing this architecture:

Certificate renewal became automatic

No manual certificate maintenance required.

Service expansion became simple

New services only need routing rules.

Network isolation improved safety

IoT workloads cannot easily reach secure services.

Troubleshooting became easier

Common issues reduce to:

404 → router mismatch
502 → backend unreachable
TLS error → DNS or certificate issue

Lessons Learned

Several practical lessons emerged.

Use container names instead of IPs

Docker DNS is more stable than static IP references.

Keep services on shared networks

Ensures routing remains predictable.

Remove unnecessary exposed ports

Let Traefik handle public access.

Back up certificate storage

Losing certificate storage can trigger renewal rate limits.

Avoid unnecessary upgrades

Infrastructure components should change slowly.


Is This Overkill for a Home Lab?

Not necessarily.

As soon as you host multiple services, segmentation and automated TLS reduce maintenance effort and improve reliability.

Even small environments benefit from:

  • consistent routing
  • secure entry points
  • simplified service management

Final Thoughts

Traefik combined with VLAN segmentation and TLS subdomain zoning has provided a stable and low-maintenance solution for managing multiple services.

The environment now:

  • renews certificates automatically
  • isolates workloads
  • simplifies routing
  • scales easily
  • requires minimal manual intervention

What started as experimentation evolved into a practical architecture pattern that now runs quietly in the background.

And in infrastructure, quiet is success.

Traefik Reverse Proxy Troubleshooting Guide (Docker + TLS + Let’s Encrypt)

Traefik is an excellent reverse proxy for Docker environments, providing automatic TLS certificates and dynamic routing. However, when something breaks, symptoms can look confusing.

This guide summarizes practical troubleshooting steps based on real-world debugging of a production home-lab setup using Traefik, Docker, and Let’s Encrypt.


Typical Architecture

A common setup looks like:

Internet
   ↓
DNS → Host IP
   ↓
Traefik (Docker container)
   ↓
Application containers

Traefik handles:

  • TLS certificates
  • Reverse proxy routing
  • HTTPS redirect
  • Service discovery

Most Common Error Types

1. HTTP 404 from Traefik

Meaning:

Request reached Traefik
but no router matched the request.

Common causes:

  • Host rule mismatch
  • Wrong domain name
  • Missing router configuration
  • Missing path prefix rules

Check routers:

curl http://localhost:8080/api/http/routers

Fix:
Ensure router rule matches request:

rule: Host(`app.example.com`)

2. HTTP 502 Bad Gateway

Meaning:

Router matched
but backend service unreachable.

Most common cause: wrong backend IP or port.

Test backend directly:

curl http://localhost:9000 -I

If this works but Traefik gives 502, fix service URL:

Bad:

url: "http://172.x.x.x:9000"

Good:

url: "http://sonarqube:9000"

Use container names instead of IPs.


3. Dashboard returns 404

Dashboard requires routing both paths:

/dashboard
/api

Fix router rule:

rule: Host(`traefik.example.com`) &&
      (PathPrefix(`/api`) || PathPrefix(`/dashboard`))

Also ensure trailing slash:

/dashboard/

4. TLS Certificate Not Issued

Check ACME logs:

docker logs traefik | grep -i acme

Verify:

  • DNS challenge configured
  • Secrets mounted correctly
  • acme.json writable

Permissions should be:

chmod 600 acme.json

5. TLS Renewal Concerns

Traefik automatically renews certificates 30 days before expiry.

Check expiry:

echo | openssl s_client \
-servername app.example.com \
-connect app.example.com:443 \
2>/dev/null | openssl x509 -noout -dates

Renewal happens automatically if Traefik stays running.


Debugging Workflow (Recommended)

When something fails, follow this order:

Step 1 — Is Traefik running?

docker ps

Step 2 — Check routers

curl http://localhost:8080/api/http/routers

Step 3 — Check backend

curl http://localhost:<port>

Step 4 — Check logs

docker logs traefik

Step 5 — Test routing locally

curl -k -H "Host: app.example.com" https://localhost -I

Best Practices for Stable Setup

Use container names instead of IPs

Avoid hardcoded LAN IPs.

Keep all services on same Docker network

Example:

networks:
  - traefik-public

Remove exposed ports

Let Traefik handle access.

Backup certificates

Cron backup:

0 3 * * * cp /opt/traefik/data/acme.json /backup/

Freeze Docker versions

Avoid surprise upgrades:

sudo apt-mark hold docker-ce docker-ce-cli containerd.io

Quick Diagnosis Cheat Sheet

ErrorMeaning
404Router mismatch
502Backend unreachable
TLS errorCert or DNS issue
Dashboard 404Router rule incomplete

Final Advice

Most Traefik problems are not Traefik itself, but:

  • router rules
  • backend targets
  • entrypoint mismatches
  • DNS configuration

Once routing and networks are correct, Traefik runs reliably for years.


Conclusion

Traefik simplifies TLS and routing, but clear troubleshooting patterns save hours when issues arise. Use this guide as a reference whenever routing or certificates behave unexpectedly.

The Modern .NET Developer in 2026: From Code Writer to System Builder

There was a time when being a .NET developer mostly meant writing solid C# code, building APIs, and shipping features. If the application worked and the database queries were fast enough, the job was done.

That world is gone.

In 2026, a modern .NET developer isn’t just a coder. They’re a system builder, balancing application development, cloud architecture, DevOps, security, and increasingly, AI-driven decisions.

One Feature, Many Disciplines

Consider a typical modern feature:

  • A scheduled job populates data into a database.
  • That data feeds reporting tools like Power BI.
  • Deployment pipelines push updates across environments worldwide.
  • Cloud services scale automatically under load.
  • Monitoring and security controls are part of the delivery.

One feature now touches multiple domains. Delivering it requires understanding infrastructure, automation, data, deployment, and operations—not just application logic.

The scope of the role has expanded dramatically.

Fundamentals Still Matter

Despite all the change, the core skills haven’t disappeared.

Developers still need to:

  • Build REST APIs that handle real-world load
  • Write efficient Entity Framework queries
  • Understand async/await and concurrency
  • Maintain clean, maintainable codebases

Bad fundamentals still break systems, regardless of how modern the infrastructure is.

But fundamentals alone are no longer enough.

Cloud Decisions Are Now Developer Decisions

In many teams, developers now influence—or directly make—architecture decisions:

  • Should this workload run in App Service, Containers, or Functions?
  • Should data live in SQL Server or Cosmos DB?
  • Do we need messaging via Service Bus or event-driven patterns?

These choices affect cost, scalability, reliability, and operational complexity. Developers increasingly need architectural awareness, not just coding ability.

DevOps Is Part of the Job

Deployment is no longer someone else’s responsibility.

Modern developers are expected to:

  • Build CI/CD pipelines that deploy automatically
  • Containerize services using Docker
  • Ensure logs, metrics, and monitoring are available
  • Support production reliability

The boundary between development and operations has largely disappeared.

Security Is Developer-Owned

Security has shifted left.

Developers now regularly deal with:

  • OAuth and identity flows
  • Microsoft Entra ID integration
  • Secure data handling
  • API protection and access control

Security mistakes are expensive, and modern developers are expected to understand the implications of their implementations.

AI Changes How We Work

Another shift is happening quietly.

In the past, developers searched for how to implement something. Today, AI tools increasingly help answer higher-level questions:

  • What are the long-term tradeoffs of this architecture?
  • How will this scale?
  • What operational risks am I introducing?

The developer’s role moves from solving isolated technical problems to designing sustainable systems.

From Specialist to Swiss Army Knife

The modern .NET developer is no longer just a backend specialist. They are expected to be adaptable:

  • Application developer
  • Cloud architect
  • DevOps contributor
  • Security implementer
  • Systems thinker

Not every developer must master every area—but awareness across domains is increasingly required.

The New Reality

The job has evolved from writing features to building systems.

And while that can feel overwhelming, it’s also exciting. Developers now influence architecture, scalability, reliability, and user experience at a system-wide level.

The industry hasn’t just changed what we build.

It’s changed what it means to be a developer.

And in 2026, being versatile isn’t optional—it’s the job.