Agent Sentinel Open SDK — Design Document
Path: /runtime/open-sdk-design.md · v0.1 (design draft) · 2026.05
The portfolio's stance toward coding-assistant vendors is publicly adversarial. The Open SDK is the operational counter-move: it gives vendors a path to participate by self-instrumenting and emitting structured signals consumable by Agent Sentinel. The SDK reframes the relationship from adversarial detection to collaborative instrumentation, without softening the empirical claim.
A vendor who self-instruments earns three things: (1) better Sentinel signal quality on their own product (because they expose more state than passive observation can recover), (2) a public Calibration Badge tying their product to the open conformance suite, and (3) standing in the conversation about CCD without having to dispute the construct.
The Open SDK is the option the vendor would accept if there were one. This document is the design for that option.
What the SDK does
An SDK that ships in two layers:
Layer 1 — Emitter API
For coding-assistant runtimes (Kiro, Cursor, Continue, Aider, Claude-CLI, GitHub Copilot, etc.) to emit structured signals into a local socket or file that Sentinel consumes. The emitter exposes:
agent_session_start(session_id, model, vendor).agent_turn(session_id, turn_id, role, content, attached_files).agent_claim(session_id, turn_id, component_id, claim_kind, claim_text)— for the vendor to label specific utterances as completion claims.agent_artifact(session_id, turn_id, file_path, sha, intent)— for the vendor to label generated artifacts with their intent (e.g.,documentation,runtime,scaffold,mockup).agent_runtime_check(session_id, component_id, check_outcome, evidence)— for the vendor to surface its own internal completion-verification logic (where any exists).agent_session_end(session_id, end_reason).
The emitter is fire-and-forget. No telemetry leaves the user's machine. Sentinel reads from the local socket.
Layer 2 — Consumer integration
A small library (sentinel-consumer) that:
- Listens on the local emitter socket.
- Normalizes events into Sentinel's Interaction shape.
- Runs PROACTIVE / configured detectors against the live event stream.
- Surfaces detections back to the runtime via a callback API.
Layer 2 lets the runtime (the IDE, the CLI, the agent loop) show Sentinel's signal in its own UI, without the user installing a separate Sentinel client.
Why a vendor would adopt this
Three reasons, each load-bearing:
1. Better signal quality on the vendor's own product
Passive observation sees text and files. Active instrumentation sees the vendor's intent. The same generated file is treated very differently by Sentinel depending on whether the runtime labels it scaffold (legitimate template), documentation (legitimate plan), or runtime (claimed working code). Without instrumentation, Sentinel must infer. With instrumentation, the vendor controls the framing.
This is the same logic by which a vendor would prefer to self-publish a security advisory rather than have one published about them.
2. The Calibration Badge
A vendor whose runtime emits SDK signals can participate in the standard evaluation harness. Their product's detector results are then reported on the conformance dashboard with their own labels. The Calibration Badge becomes a product-marketing asset.
A vendor that does not participate is also evaluated, but with all the inferential ambiguity that passive observation imposes.
3. Standing in the conversation
The empirical claim about CCD will continue to be discussed in safety venues regardless of vendor preferences. A vendor who has instrumented their product is in the conversation as a participant. A vendor who has not is in the conversation as a subject. The SDK exists so vendors can choose the first.
What adoption costs the vendor
Honest accounting:
- Engineering cost. An emitter integration for a typical coding-assistant runtime is 1–3 engineer-weeks. The reference emitter is open-source and MIT-licensed.
- Surface-area cost. The SDK adds a small public surface (the emitter API) that the vendor commits to maintain.
- Reputational cost. A vendor that integrates and then exhibits CCD in the wild will have a more legible failure than a vendor that did not integrate. We argue this is a benefit, not a cost — legibility is what behavioral safety means — but a vendor's PR team may not see it that way.
- Operational cost. Logging events to a local socket is approximately free; the runtime user controls all data.
No vendor lock-in. The emitter API is open and stable; a vendor that integrates and later wants to stop can deprecate emitter calls without affecting their product.
What adoption does not commit the vendor to
- Adopting Sentinel's detection conclusions.
- Endorsing the polemic.
- Funding the program.
- Releasing model weights, training data, or any proprietary information.
- Joining the advisory board.
- Allowing Sentinel into their model's serving infrastructure.
The SDK is a one-way emitter API. Anything beyond it is a separate conversation.
Design constraints
Local-first by construction. Emitter writes to a local socket; consumer reads from it. No cross-machine telemetry. A vendor whose security model forbids any telemetry-shaped feature can still emit to a no-op consumer if needed.
Consent-honored. The user controls whether the consumer is running. Without a consumer, the emitter's writes go nowhere; no data is retained.
Standard-shaped. The emitter API uses OpenTelemetry-style event shapes where possible, so the vendor's existing observability infrastructure can read the events for the vendor's own purposes.
Minimal feature surface in v1. Six emitter methods. Each is necessary. Each can be added to a runtime in a single afternoon of engineering work once the contracts are understood.
Reference implementations planned
sentinel-emitter-python— Python emitter for Claude-CLI, Aider, Continue.sentinel-emitter-typescript— Node/TS emitter for Cursor, VS Code-based runtimes.sentinel-emitter-rust— Rust emitter for any low-level integrator who prefers it.sentinel-consumer-python— the consumer library.
All MIT-licensed. All shipped together at v1.
What the SDK is not
- Not a behavioral evaluation framework for the vendor's R&D team. (Different problem; vendors have their own.)
- Not a competitor to vendor-internal observability stacks. (The SDK emits to whatever observability the vendor already has, in addition to Sentinel.)
- Not a precondition for using Sentinel. (Sentinel works against passive observation. The SDK improves the signal but is optional.)
The first three integrations
Aspirational, conditional on $480k funding tier and pilot relationships:
- A friendly small-vendor integration first. Aider or Continue (open-source, lower switching cost, faster to ship and reference) as the first emitter integration.
- A research-lab integration second. A safety-team-internal coding-assistant runtime at one of the major labs. (We have no agreement; we have a hypothesis that one of them would value a research-shaped engagement.)
- A commercial-vendor integration third. Cursor or Continue at a commercial-grade integration; this is the one whose value the SDK is ultimately measured on.
Public timeline: 2027 Q1 first integration RFC; 2027 Q2 first shipping integration.
RFC status
This is a design document, not a frozen interface. The emitter and consumer APIs may change substantially during the first three vendor conversations. The freeze target is v1.0 at 2027 Q1.
Implementer feedback is welcome. The most valuable feedback at this stage is "this would not survive contact with my runtime because X."
A note on the polemic
This SDK exists because the work intends to succeed at safety, not to succeed at the polemic. The polemic is the recruiting mechanism for readers who care; the SDK is the operational pathway for vendors who, having read the work, decide to participate.
A vendor that integrates the SDK does not endorse the polemic. The author retains the polemic. The SDK is the place where the work and the vendor can meet without either party giving up its register.