This guide turns your .NET app from watching AI agents into acting on them. Every request is checked against your Cedar policy, and agents that need permission are sent to a consent screen.

This is for .NET middleware. Agents that cooperate get sent to your consent screen; the rest are blocked. For sensitive routes that must never be bypassed (like payments), also put the Gateway in front of your app.

Use the latest version: 1.6.0. All four .NET packages move together, so you only ever change one number. (This number updates itself from the source code, so it's always current.)

Set it up

Four steps. The policy you deploy in the dashboard does the work — your app just reads it.

1. Install the package

Add KyaOs.Checkpoint — it pulls in the other three packages for you.

<PackageReference Include="KyaOs.Checkpoint" Version="1.6.0" />

<package id="KyaOs.Checkpoint" version="1.6.0" targetFramework="net462" />

2. Connect it to your project

Add your ProjectId and ApiKey (from the dashboard). If you already run the .NET middleware, these are set — skip ahead.

builder.Services.AddCheckpoint(options =>
{
    options.ProjectId = builder.Configuration["Checkpoint:ProjectId"]!;
    options.ApiKey    = builder.Configuration["Checkpoint:ApiKey"]!;
});

<add key="Checkpoint:ProjectId" value="your_project_id" />
<add key="Checkpoint:ApiKey" value="your_api_key" />

3. Deploy your Cedar policy

Open the Policy tab for your project (/dashboard/{orgId}/{projectId}/policy) to see your policies; create one from Policy → Compose (/dashboard/{orgId}/{projectId}/policy/compose). Your app reads the deployed policy automatically — nothing to add in code.

Tell your app where the consent screen lives. When the policy decides an agent needs permission, it's sent here.

options.AuthorizationHostUrl = "https://kya.vouched.id";

<add key="Checkpoint:AuthorizationHostUrl" value="https://kya.vouched.id" />

Brand the screen — logo, name, and scope wording — with the consent-config API (PUT /api/v1/bouncer/projects/{projectId}/consent-config). See Consent Flows.

That's it. Open a protected route as an agent and watch the dashboard show the action (allow, block, or challenge).

Advanced settings

You don't need these to get started. By default, a policy challenge verdict already sends agents to consent. The options below upgrade that to the standards-based delegation challenge, limit it to specific routes, and make it friendly to AI agents that can't read a blocked page.

Turn on the standards-based challenge

Emits the spec delegation challenge (instead of the legacy step-up) and lets you gate it to specific scopes.

options.EnableDelegationChallengeWire = true;
options.DelegationChallengeScopes = ["payment:process", "data:export"]; // which actions require it
options.ResourceOrgDid = "did:web:acme.com"; // your org's identity — binds the signed proof

<add key="Checkpoint:EnableDelegationChallengeWire" value="true" />
<add key="Checkpoint:DelegationChallengeScopes" value="payment:process,data:export" />
<add key="Checkpoint:ResourceOrgDid" value="did:web:acme.com" />

Choose how strict to be

Some AI agents can't read a page once it's blocked, so they never see the consent link. Negotiated makes sure cooperative agents still get the link, while everything else stays blocked.

options.DelegationChallengeMode = DelegationChallengeMode.Negotiated;

<add key="Checkpoint:DelegationChallengeMode" value="Negotiated" />

Mode	Behaviour
`Negotiated` (default)	`200` for a cooperative agent, `401` for everything else. Recommended.
`Spec401`	Always the spec `401`. Cooperative AI fetchers may miss the body.
`Always200`	Always the `200` envelope. Most permissive.

All settings in one place

{
  "Checkpoint": {
    "ProjectId": "your_project_id",
    "ApiKey": "your_api_key",
    "EnableComposedPolicy": true,
    "EnableDelegationChallengeWire": true,
    "DelegationChallengeScopes": "payment:process,data:export",
    "DelegationChallengeMode": "Negotiated",
    "AuthorizationHostUrl": "https://kya.vouched.id",
    "ResourceOrgDid": "did:web:acme.com"
  }
}

<appSettings>
  <add key="Checkpoint:ProjectId" value="your_project_id" />
  <add key="Checkpoint:ApiKey" value="your_api_key" />
  <add key="Checkpoint:EnableComposedPolicy" value="true" />
  <add key="Checkpoint:EnableDelegationChallengeWire" value="true" />
  <add key="Checkpoint:DelegationChallengeScopes" value="payment:process,data:export" />
  <add key="Checkpoint:DelegationChallengeMode" value="Negotiated" />
  <add key="Checkpoint:AuthorizationHostUrl" value="https://kya.vouched.id" />
  <add key="Checkpoint:ResourceOrgDid" value="did:web:acme.com" />
</appSettings>

What You Learned

How to install KyaOs.Checkpoint and connect it to your project with ProjectId + ApiKey
That your app enforces the Cedar policy you deploy in the dashboard — no rules live in code
How to point cooperative agents at a branded consent screen with AuthorizationHostUrl
How to upgrade the built-in challenge verdict to the standards-based delegation challenge with EnableDelegationChallengeWire, scope it with DelegationChallengeScopes, and bind it to your org with ResourceOrgDid
How DelegationChallengeMode (Negotiated / Spec401 / Always200) controls whether cooperative fetchers get a body-readable 200 or the spec 401

The .NET middleware emits the spec delegation challenge itself (via its composed-policy engine), so a CHALLENGE verdict becomes a real 401 step-up rather than falling back to a redirect. Challenge support varies by SDK — see Policies.

Next Steps

Goal	Where to go
Detect-only .NET setup first	.NET Integration
Fine-tune the policy verdicts	Policies
Brand the consent screen	Govern: Consent

.NET Integration — Base middleware, install, and detection
Policies — Authoring Cedar and the verdict reference
Govern: Consent — Consent flows and screen configuration

Enforce: .NET Cedar Policy + Consent