Checkpoint.AspNetCore 0.3.0

There is a newer version of this package available.
See the version list below for details.
dotnet add package Checkpoint.AspNetCore --version 0.3.0
                    
NuGet\Install-Package Checkpoint.AspNetCore -Version 0.3.0
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Checkpoint.AspNetCore" Version="0.3.0" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Checkpoint.AspNetCore" Version="0.3.0" />
                    
Directory.Packages.props
<PackageReference Include="Checkpoint.AspNetCore" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add Checkpoint.AspNetCore --version 0.3.0
                    
#r "nuget: Checkpoint.AspNetCore, 0.3.0"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package Checkpoint.AspNetCore@0.3.0
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=Checkpoint.AspNetCore&version=0.3.0
                    
Install as a Cake Addin
#tool nuget:?package=Checkpoint.AspNetCore&version=0.3.0
                    
Install as a Cake Tool

ASP.NET Core middleware for AI agent detection and policy enforcement. Drop-in middleware that detects AI agents, enforces policies from the Checkpoint dashboard, and blocks/redirects automated traffic. The .NET equivalent of @kya-os/checkpoint-express.

Product Compatible and additional computed target framework versions.
.NET net8.0 is compatible.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed.  net9.0 was computed.  net9.0-android was computed.  net9.0-browser was computed.  net9.0-ios was computed.  net9.0-maccatalyst was computed.  net9.0-macos was computed.  net9.0-tvos was computed.  net9.0-windows was computed.  net10.0 was computed.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (1)

Showing the top 1 NuGet packages that depend on Checkpoint.AspNetCore:

Package Downloads
KyaOs.Checkpoint

AI agent detection and policy enforcement for any .NET HTTP server. Install this metapackage and NuGet automatically pulls in the right adapter for your runtime: Checkpoint.AspNetCore on modern .NET (ASP.NET Core 6+), or Checkpoint.AspNet on classic .NET Framework 4.6.2+ (System.Web / IIS). Same WASM-backed Rust detection engine on both stacks — same patterns, same scoring, same updates.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
0.4.0 82 4/22/2026
0.3.3 102 4/21/2026
0.3.2 114 4/21/2026
0.3.1 108 4/18/2026
0.3.0 108 4/18/2026
0.2.9 103 4/18/2026
0.2.8 105 4/17/2026
0.2.7 101 4/17/2026
0.2.6 97 4/17/2026
0.2.5 110 4/17/2026
0.2.4 125 4/17/2026
0.2.3 111 4/17/2026
0.2.2 109 4/15/2026
0.2.1 100 4/15/2026
0.2.0 101 4/15/2026
0.1.11 88 4/13/2026
0.1.10 134 4/10/2026
0.1.9 100 4/2/2026
0.1.8 102 3/31/2026
0.1.7 91 3/31/2026
Loading failed

0.3.0 — Hang fix follow-up to 0.2.9 (CRITICAL for anyone on 0.2.4–0.2.9)

0.2.9 (#1829) added ConfigureAwait(false) and a relative-URL fix in
McpInstructBuilder. 0.3.0 builds on that with the bounded-fetch +
negative-cache + URL-validation work needed to actually prevent the
hardwareworld.com class of hang, not just the synchronization-context
amplification of it. Anyone running 0.2.4–0.2.9 should upgrade.

Changes:
* PolicyEvaluator: cap lock-wait at 2s and policy-fetch at 3s via linked
 CancellationTokenSource. Worst-case per-request policy time bounded
 regardless of HttpClient timeout or retry behavior.
* PolicyEvaluator: short (10s) negative cache after a failed/null fetch so
 one slow backend doesn't cascade into per-request retries serialised
 through the SemaphoreSlim.
* PolicyEvaluator: stale-on-failure — if a refresh fails, keep serving the
 last-known-good policy rather than dropping to local-only enforcement.
* CheckpointModule / UseCheckpoint(): pre-warm the policy cache on
 initialization so the first real request never pays the cold-cache cost.
* CheckpointApiClient: per-call retry budget (1 retry, 3s total) for
 policy fetches; telemetry endpoints unchanged.
* PolicyCacheTtlMinutes default raised from 1 → 5 to cut steady-state
 policy traffic 5×. Set lower explicitly for rapid-rollout setups.
* ConfigureAwait(false) added to all library awaits (CheckpointModule,
 CheckpointMiddleware, PolicyEvaluator, CheckpointApiClient,
 SignatureVerificationHelper) — eliminates classic ASP.NET sync-context
 amplification on the .NET Framework adapter.
* Redirect branches now reject non-absolute / non-http(s) URLs from
 policy.RedirectUrl and Checkpoint:McpServerUrl. A relative URL like
 "/connect/{projectId}" used to 302 the request back into the customer's
 own host, looping through the same module and surfacing as a hung
 connection. When neither the policy URL nor the local McpServerUrl is
 an absolute http(s) URL, the module falls through to the default block
 response and emits a Trace warning identifying which value(s) were
 malformed. UrlHelpers.TryResolveAbsoluteRedirect / IsAbsoluteHttpUrl
 added for both adapters.

Note: Checkpoint.FailOpen catches *exceptions*, not *hangs*. Before 0.2.9
a slow policy fetch never threw, so FailOpen=true did not protect the
request path. With 0.2.9 the bounded-wait CTS makes this distinction
mostly moot, but the underlying behavior is unchanged.