CLAiR — Coordination & security findings

Completion is not
acceptance.

When multiple agents work the same codebase, the coordination truth has to live somewhere they can’t lie about. CLAiR is that runtime — claims, leases, gates, merges, evidence — structured, authenticated, event-sourced, and accountable.

That principle now governs vulnerabilities too. CLAiR’s OPTRS extension turns penetration-test findings into governed remediation and retest work — and a finding does not close because someone merged a fix.

For engineering leaders, platform teams, security leads, and compliance officers running agentic delivery in regulated environments.

See CLAiR coordinating real agents against a real repo. No deck.

Why CLAiR exists

Coordination truth shouldn’t live inside the agents.

Multiple agents on one repo is a distributed systems problem, not a prompt-engineering problem. CLAiR is the runtime that holds them honest — with the receipts.

01 · The reality

Agents collide on the same code.

Two agents pick up overlapping work. One agent abandons a branch mid-flight. Another claims something it isn’t scoped to touch. With no live coordination authority, the codebase pays the cost — in races, lost work, and quiet conflicts.

02 · The status quo

Completion gets confused with acceptance.

An agent reports done. A reviewer skims. The change merges. Nobody can later show what gate was satisfied, what evidence was attached, or who authorized the release. “The agents finished” is not the same sentence as “we shipped something the auditors can sign off on.”

03 · The CLAiR answer

Claims, leases, gates — with evidence.

CLAiR brokers every claim, enforces every gate, projects every event into a queryable graph. Events are truth, denials are structured, mutations require authenticated principals. The agents stay focused on code; the runtime keeps the receipts.

What CLAiR owns

  • Claims and leases with TTLs, renewals, voluntary release, and expiry.
  • Arbitration across competing agents, stale-work cleanup, retry and reassignment policy.
  • Blackboard coordination with scope-aware visibility rules.
  • Orchestration flows — stages, gates, release conditions, acceptance state.
  • Source-control authority — branch leases, merge queues, conflict-as-work-item.
  • Security findingsFinding is a first-class domain entity with its own identity, severity, status, and lifecycle — not metadata bolted onto a work item.
  • Target leases — time-boxed, rules-of-engagement-gated authority to act against an asset, URL, CIDR, or tenant, held separately from branch leases.
  • Compliance gate hooks — requirements, evidence, exceptions, matrix.
  • Agent identity — authentication, scoped authorization, structured error responses for every denial.
  • Bo intake — structured handoff envelopes from the planning provider become CLAiR operations.
  • Graph projection — durable state writes into BogDB so upstream orchestrators like ASE can query history.

What CLAiR is not

CLAiR's scope is narrow on purpose. It is not a general-purpose workflow engine, not a code editor, not a build system, not a CI pipeline, not a version control system, not a model host. If a capability doesn't directly serve coordinating multi-agent work with repo-aware, branch-aware, artifact-aware semantics, it doesn't belong in CLAiR.

The security extension inherits the same discipline. CLAiR is not a scanner runner, not an exploitation framework, not an asset inventory, not a credential vault, and not a report renderer. It coordinates authorized findings and the work that closes them. Offensive tooling, when it runs at all, runs behind explicit adapters with rules-of-engagement gates, target scopes, and credential isolation — never inside the coordination runtime.

That focus is what makes it composable. Temporal can still run your business workflows. Your CI/CD can still ship your builds. Your scanners stay your scanners. CLAiR holds the line on coordination, and everything else stays free to evolve.

Security findings · the hardening loop

A vulnerability isn’t closed because someone merged a fix.

CLAiR’s OPTRS extension ingests OWASP Penetration Test Reporting Standard reports and turns each finding into governed remediation and retest work. The scanner finds it. CLAiR holds it. A hardening agent closes it. The evidence proves it.

finding closed = remediation accepted AND retest accepted

Enforced by the work-item runtime, not by convention. Retest work is created blocked on its remediation item and only becomes claimable when that remediation is accepted. Importing a report that already says resolved marks nothing accepted.

01 · Import

An OPTRS report arrives from your scanner, your pentest vendor, or an intake agent. CLAiR validates it against the OPTRS v1 schema and normalizes engagements, scope entries, findings, affected assets, media, and artefacts — preserving every field, including ones it doesn’t map.

02 · Findings become first-class

Each finding becomes a real CLAiR domain entity with deterministic identity — optrs:finding:{report}:{id} — carrying its own severity, status, target scopes, code areas, and artifact links. Security state is never inferred from generic work-item metadata.

03 · Work items appear

Every actionable finding produces a remediation work item and a paired retest item, deterministically keyed so re-importing the same report is idempotent. Recommendations from the report become the acceptance criteria, preserved verbatim.

04 · A hardening agent claims it

Remediation items advertise security + remediation capabilities; retests advertise security + retest. An ASE hardening constellation claims them through the ordinary ACOP path — work lease, branch lease, delivery, gates. No special-case execution path.

05 · Retest unblocks

Remediation acceptance moves the finding to RemediationAccepted and lifts the blocker on the retest item. A fresh agent re-tests the finding by its original reproduction steps. Retest acceptance moves it to Resolved — and only then.

06 · Export

CLAiR reconstructs an OPTRS-compatible report from the original snapshot plus accepted remediation state, retest evidence, risk acceptances, and reviewer decisions — keeping report identity and version lineage, and adding CLAiR provenance in extension fields. Hand it straight back to the assessor.

Two scopes, never collapsed

“What system is affected?” is a different question from “where may this agent change code?”

A remediation work item carries both. Target scopesasset:, url:, cidr:, tenant:, service:, cloud_account: — describe the affected system and gate authorization, ownership, and target leases. Source scopesrepo:, branch:, worktree: — describe where the agent is permitted to write. They are stored as structured metadata, never parsed from free text at authorization time.

Collapsing the two is how a remediation agent ends up authorized somewhere nobody intended. Target leases are time-boxed and rules-of-engagement gated, expire automatically, and stay separate from the branch leases that govern code.

Not every finding gets fixed

Some close as false positives after reviewer evidence; some as accepted risk, with decision notes and an expiry date. Both are explicit endpoints behind their own permissions, both emit a finding_status_changed event, and an accepted risk exports as accepted_risk only while the exception is unexpired. Let it lapse and the finding reopens itself in your reporting.

Evidence without the exposure

Pentest evidence is hazardous by nature — payloads, captured tokens, internal hostnames, screenshots of real data. CLAiR stores validated metadata, content hashes, and immutable references behind a redaction boundary; it rejects inline, credential-bearing, traversal, and malformed URIs at import, and sanitizes anything projected into the graph. The bytes live in controlled storage, not in the event log.

Least-privilege throughout: optrs:import, finding:read, finding:triage, finding:accept_risk, and security_artifact:read are distinct permissions, bundled into Security Viewer, Reviewer, Risk Approver, and Importer roles — each evaluated against the coordination scope on every call, not just at login.

Dashboard & reporting

CLAiR grew a face.

Findings, remediation work, retests, risk decisions, and trends are all CLAiR-owned coordination state — so the security workspace lives in CLAiR, not bolted onto something upstream. It signs you in with OIDC and PKCE and relays your token to the API, so the API stays the single policy enforcement point and the dashboard never gains a shared service identity.

The security workspace

  • Scope-bound report index — open an engagement and see only the reports that scope authorizes.
  • Finding detail with severity and status filtering, affected assets, code areas, and linked remediation work.
  • Artifact lineage — the derivation chain behind every piece of evidence, including decompilation and rebuild provenance.
  • Active retest queue across the scope, showing dependency, blocker, claim, and lifecycle state.
  • Security trends executed as scoped Cypher against BogDB, with a live-index fallback that says so when it is used.
  • Risk actions — false-positive and accepted-risk decisions, surfaced only to the roles that hold them.

The dashboard proposes; the API disposes. Every action re-authorizes server-side against the coordination scope.

Questions the graph can answer

Findings, assets, weaknesses, tools, code areas, artifacts, and remediation work all project into BogDB as nodes and edges. CLAiR ships a versioned golden query library — not example snippets, but queries with defined fixtures, parameters, expected columns, and sort order, executed against fixture graphs in CI so schema drift fails the build instead of your report.

  • Which critical findings are still open, and on which assets?
  • Which weaknesses keep recurring across engagements?
  • Which critical remediations have gone stale against their SLA?
  • Which accepted-risk exceptions expire this quarter?
  • Which assets and code areas are the real hotspots?
  • Which findings did each tool actually catch?

That last one is quietly the most useful: coverage by tool, over time, is how you find out which scanner in your stack is earning its licence.

Protocol

CLAiR implements ACOP — the Agentic Code Orchestration Protocol

ACOP is the runtime contract for multi-agent code work: register or observe an agent, ingest a work item, claim it with a lease, renew or release, attach artifacts and evidence, write blackboard entries, query actionable work, load orchestration flows, gate downstream releases, coordinate branches and merges, and return structured denials for every refused operation.

Bo produces the structured code-work evidence. BogDB stores the durable graph projection. MCP is a tool surface; A2A is message transport. CLAiR is the runtime that holds them honest — the ACOP service that turns "we asked the agents to do the work" into "we have evidence the work was done, approved, and merged according to the gates we configured."

Where CLAiR fits in the Beyond Ordinary stack

ASE is the human-facing control plane. It defines work, configures constellations, supervises runs, and reports out. ASE doesn't arbitrate live claims — it asks CLAiR.

The hardening capability is where that division of labor pays off most visibly. ASE stands up the constellation and owns the operator experience; CLAiR holds the findings, the target leases, the retest dependencies, and the evidence. Neither one has to grow into the other — and because a finding is a first-class CLAiR entity rather than an ASE concept, a scanner or an intake agent can file work into the same ledger without ASE in the loop at all.

Bo produces the deterministic code intelligence and planning artifacts. When Bo wants to hand work into the system, it sends a handoff envelope to CLAiR's /bo/intake endpoint, which normalizes it into ACOP operations.

BogDB is the durable graph projection. CLAiR's JSONL event log is the source of truth; BogDB is the queryable read model that lets ASE answer "what happened on this codebase, who approved it, and what evidence proves it."

Each boundary is a contract. Replace any of them and the rest still works.

Engineered, not sketched

  • .NET 10 minimal API — more than 40 endpoints covering ACOP, graph facade, events, branch leases, merge queue, conflicts, flows, compliance, and Bo intake
  • JSONL event store as the system of record — events are truth, read models are derived
  • Optional EF Core read-model on SQL Server / Azure SQL Edge for queryable indexes
  • BogDB graph projection — node/edge upserts on every appended event
  • Keycloak OIDC authentication (with a static-token mode for local dev)
  • Sliding-window rate limits, structured error envelope, scoped principals
  • Blazor Server dashboard — operational views over agents, work items, claims, blackboard, events, policies, and reports, plus the API-backed OPTRS security workspace
  • CLAiR.OPTRS as an optional boundary library — the core domain and application layers have no dependency on it, so security is an extension, not a fork

Proven, not promised

CLAiR is real working software. More than 490 tests run green in CI across six projects — Domain, Application, Dashboard, Graph, OPTRS, and Integration. The SQL projection is exercised on SQLite through the integration harness and runs the same code path on SQL Server and Azure SQL Edge.

The graph tests don't merely assert that queries run. The harness compares result shape and canonical rows for every golden query against a multi-engagement fixture, so a missing projection or a query-engine regression fails CI rather than quietly returning fewer findings.

Shipped today: Bo intake, the orchestration flow loader, branch leases, the merge queue, conflict-resolution-as-work-item, local Git-provider verification, the BogDB graph projection (write and read), the compliance extension with pattern-based auto-attach, and the OPTRS security extension — import, first-class findings, remediation and retest orchestration, target leases, risk decisions, artifact provenance, dashboard, trends, and export.

Live coordination, with the receipts

Turn model output into accountable work.

If you’re building agentic delivery into a regulated environment, CLAiR is the runtime layer that makes “we ran a constellation against this repo” something an auditor can read — and “we fixed the pentest findings” something you can prove. Bring a real report; we’ll run the loop. 30 minutes is enough to see it working.

Cookie Compliance

We use cookies to ensure you get the best experience on our website. By continuing to use our site, you accept our use of cookies, privacy policy and terms of service.