Security · for CISOs and platform leads

Enterprise governance, built into the merge.

Nightjar ships a coordinated fleet — reviewer, security linter, issue wrangler, fix shipper — into your enterprise repos with policy gates, an append-only audit trail, and a human in the merge seat on every change. Code and context stay inside the boundary your platform team already controls.

Join the waitlistSee the fleet
Merge gate
human
Audit trail
append-only
Data egress
none
nightjar · trust posture
revision 0.3
policy gate signed + cost-clean
merge human approval required
audit append-only · exportable
training on customer data never
rollback one command · per-agent kill switch

SOC2 readiness · 01

Readiness against the Trust Services Criteria your auditors already use.

We treat SOC2 as a readiness frame, not a badge. Nightjar’s controls are mapped to the Trust Services Criteria your auditors examine — Security, Availability, Confidentiality — with the evidence-producing artifacts generated automatically as the fleet runs.

CC6 — Access control
Per-environment policy
Dev, staging, and prod each set their own bars. The same agent that ships in dev is gated harder in prod, by policy file in your repo — not a toggle in someone else’s dashboard.
CC7 — Change management
Reviewer + human merge
Every agent-shipped diff passes the reviewer and security linter, then waits on a human merge. The PR is the change-ticket. The merge event is the sign-off. The audit trail is the receipt.
CC8 — Logging
Append-only audit trail
Every signal, every agent step, every human sign-off, and the final merge SHA — written once, exportable, and replayable on demand by your GRC team.
C1 — Confidentiality
No exfiltration by default — repos and model context stay inside the trust boundary you configure.
Nightjar does not move your code off the network boundary you set at install. We do not train shared models on customer data, and we do not pool context across tenancies. The vendor-management portion of your SOC2 program covers a vendor that operates with the same posture you would if you wrote the controls yourself.

Audit trails · 02

Eight fields on every merged PR. Nothing leaves it to memory.

Every agent-shipped PR carries the same set of audited fields — origin, ownership, security verdict, reviewer decision, projected cost, human approval, and the final SHA. The trail is append-only, exportable, and replayable, so your GRC team can reconstruct any week of fleet activity on demand.

Signed
Append-only
Exportable
  1. field 01recorded
    Origin signal

    Source alert, webhook, scheduled scan, or CI failure that produced the work item — recorded with timestamp and undelivered-payload hash.

  2. field 02recorded
    Triage owner

    Which agent in the fleet picked up the item, who it was assigned to, and at what wall-clock time — the same chain backed by a single signed event.

  3. field 03recorded
    Security lint

    CVE count, severity buckets, dependency hits, and the linter version that produced each result — replayed with the same seed on request.

  4. field 04recorded
    Reviewer verdict

    Approve, request changes, or pause — with the reasoning line that drove the call, kept alongside the diff for the entire retention window.

  5. field 05recorded
    Projected cost Δ

    Cloud-cost delta on every changed resource, computed at PR open and re-run at merge, with the diff of those two numbers in the audit record.

  6. field 06recorded
    Human approval

    The signature, identity, and timestamp of the human who clicked merge — until that event arrives, the PR remains an open diff, not a landing.

  7. field 07recorded
    Merge SHA

    Final commit pointer and the parent chain, so any audit replay can reconstruct the exact tree that was promoted into the target branch.

Policy & human-in-the-loop · 03

Gates, checkpoints, and reversibility — by construction, not by exception.

Three controls your platform team already expects, written into the merge pipeline rather than bolted on after. Every shippable change passes all three; a failed lever blocks the merge.

Policy gates, not policy theater

  • Signed commits on every agent-shipped PR
  • Policy-as-code gates evaluated before any merge attempt
  • Per-environment policy: dev, staging, and prod each set their own bars
  • FinOps regression blocks the gate before it ever lands

Humans stay in the merge seat

  • Merge is always a human action — agents file, humans land
  • Reviewer pause on high-blast-radius changes
  • Configurable thresholds per repo and per risk class
  • Pause-kill switch on every agent, per environment

Reversibility by construction

  • One-command revert of any agent-shipped PR
  • Append-only audit trail captures who did what, when, with which signal
  • Per-agent pause / kill switch, scoped to environment
  • Spend-by-agent breakdown exported with the trail

Data & residency · 04

Inside the boundary your platform team already operates in.

Customer code and model state stay where your platform team already runs them. The list below is what stays, what doesn’t, and the residency knobs you control at install.

Stays inside your trust boundary
Source repos, model context, and any secrets read from local workloads are processed in your VPC/on-prem. Nothing leaves the network boundary you configure at install.
Never used for training
Your code, prompts, and agent output do not flow back into any shared model training corpus. The fleet is tuned per-customer and never pooled across them.
Data classification respected
Agents read the classification labels your platform team attaches to repos, paths, and secrets. Anything marked restrictive is steered away from the shipper lane by policy.
Residency where you operate
Deploy into the region your platform team already operates — North America, EU, or your own VPC. The audit trail lives next to the work it describes, not in a region you didn’t choose.

FAQ · 05

What CISOs and platform leads ask before they flip the first lane on.

A few questions that come up in every first security review. Write to us with anything not covered here — we typically respond same-day during a pilot.

Ask another one

Deploy Nightjar · start with a shadow-run pilot

Turn on the fleet on your terms. Audit every step on the way.

Pilot scope starts with a shadow-run in a non-production environment — agents file PRs, your reviewers see the trail, and your platform team sees the policy gates fire. Production flips on lane-by-lane once your team is comfortable.

start a pilot

Talk to the Nightjar team

We map your repos, registries, and policy gates before we propose any lane.

Shadow-run keeps every agent-shipped PR reversible, one command, until you sign off.

Pause-kill switch is wired in day one, scoped per agent and per environment.

Join the waitlist

nightjar-noqvki@polsia.app