From the Backlog to the Build Log

Week of July 31 - August 6, 2026

AI-Assisted .NET Security That Proves Itself

This week I used DevNitro for AI-assisted .NET security work that proves the rules still hold. That is part of Intelligent Engineering. A rule in a document can drift. A check in the build or test suite fails when the code no longer follows the rule.

I added global authentication fallback canaries across GCT, BlankSite, and DevNitro. Each canary leaves off both [Authorize] and [AllowAnonymous] on purpose. The tests then prove that an anonymous request still gets blocked. If someone removes or weakens the fallback policy later, the test tells us.

This matters because the fallback is the last line of defense when a developer forgets an auth attribute. A normal endpoint test cannot prove the global rule still works. The canary has no local protection, so it tests the exact gap the fallback policy must close.

I also added build-time checks for two Blazor CSS isolation mistakes. One catches styled markup built outside Razor, where Blazor never adds the scope attribute. The other catches :deep(), which is Vue syntax, instead of Blazor's ::deep. Both errors can compile while the styles do nothing, so the build now flags them with clear error codes.

These are not security bugs, but they fail in the same quiet way. The code builds. The page loads. The rule does nothing. Moving the check into the build turns a late visual bug into a fast, clear failure.

The payment work started with a real warning. I found signs that someone had tried to use a production site as a credit card validity oracle. In plain terms, they were testing cards to learn which ones might be valid.

The site did not give them the answer they wanted, but only because one feature had not been enabled on that client's app. That was just chance, not a safeguard. If that feature had existed, the same attempt could have exposed a real hole.

I used the incident to build reusable payment safeguards in GCT: rate limits, per-user and global session invalidation, card verification rules, stable decline codes, safer logs, and billing-address updates for saved cards. I made sure client apps could act on the details while neither network traffic nor client-facing error messages exposed information that card checkers could use to determine card validity.

What the AI Did Well

The AI agent handled the cross-repo work well. It applied the auth canary pattern to each test host while respecting the differences between GCT, BlankSite, and DevNitro. It also added tests rather than treating the config change as enough proof.

On payments, it built the shared parts in GCT instead of leaving one-off fixes in an app. The work covered zero-amount card checks, AVS and CVV parsing, config-driven verification policy, and guard logic that checks whether a card already has a settled payment. It also improved 422 responses so callers keep the machine-readable rule code.

What Needed Correction

The hard part was not writing each change. It was keeping the framework boundary clean while several parts touched one another. I had to check that shared rules stayed in GCT and that app-specific behavior stayed out of it.

Error handling also needed care. A human-readable message is not a safe program contract, so the client had to preserve the rule code from a 422 response. Address failures and CVV failures also needed separate paths. Asking someone to edit an address will not fix a bad security code.

What Shipped

The auth canaries, CSS isolation linting, stronger fabricated tool-result detection, and payment safeguards all landed in source with tests. I did not confirm a production deployment this week, so I am not calling them live.

The result is less room for silent drift. A missing auth fallback, dead scoped CSS, or lost payment rule code now has a check that can fail close to the change that caused it.

The Numbers

Category	Hours
Content	12h 46m
Product / Features	7h 29m
Testing	6h 13m
Business	0h 29m
Total	26h 57m

Content took the largest block this week. Product and testing still totaled 13h 42m, which fits the main theme: the security work and the proof for it took almost equal weight.

Where This Fits in Intelligent Engineering

The point is not to ask the AI to remember every rule. Put key rules where the AI and the team cannot skip them: in builds, tests, and stable contracts. That is how software becomes easier to trust, support, and scale as more work runs through AI.

AI-assisted .NET security gets more useful when breaking a key rule also breaks a test.

Curious how this site was built?
Watch the 5-minute walkthrough on YouTube →

August 7, 2026 Build Log: Security Rules That Prove Themselves