inlinedocs
Portal ↗

Security & monitoring

Compliance

Compliance answers a question that’s easy to ask and hard to keep answering: for every third-party service our code sends data to, do we have a signed agreement that covers it? inline detects the providers your repositories use, cross-references your uploaded agreements (BAAs, DPAs), and flags real exposures — data actually flowing to a vendor you’re not covered for.

It’s built for HIPAA-style obligations but the mechanics are general. Optional per-org, off by default.

# The domain

  • Provider catalog — a global profile per vendor: how it exposes data (server_side / client_side_only / local_lib / hybrid), whether the vendor offers a BAA, and detection signals (package names, API hostnames, config patterns). Seeded with ~60 curated providers and auto-extended by a web-research step for unknowns (which start pending_review).
  • Vendor agreement — your signed contract, uploaded as a PDF/DOCX. inline extracts its terms, dates, and covered services and tracks its status (active / expiring / expired).
  • Compliance finding — a per-repo exposure, judged on two axes: does data actually flow to the provider (data_flows / no_data_flow / needs_attention), and is sensitive data involved (phi_likely / phi_possible / no_phi). Real exposure = data flows and PHI is plausible.

# The pipeline

Daily workers run four stages:

  1. Match (no AI) — detect providers across dependencies and config files, classify each against your active agreements, short-circuiting on an unchanged manifest.
  2. Research — for unknown vendors, a web search plus fast-model triage adds a catalog entry (pending human review).
  3. Analyze — extract terms from an uploaded agreement document using a model with native PDF vision.
  4. Assess — the same agentic false-positive killer as Sentinel (a fast triage model escalating to more capable models), reading the repo to decide whether data really flows and whether it’s sensitive. It escalates on a positive finding rather than a negative one, because a wrong “you’re exposed” is the expensive mistake.

# PR-time checks

With PR-time checks on, inline also checks at review time: it parses the added lines of package.json / .csproj / config files in a PR diff, detects a newly introduced uncovered provider, and appends a 🔒 Compliance note to the review — so a new vendor dependency gets flagged the moment it’s proposed, not on the next daily sweep.

# The portal

  • Overview — a coverage matrix of providers against agreements.
  • Agreements — upload (≤25 MB PDF/DOCX), view extracted terms, re-analyze; expiry reminders fire at 30/7/1 days.
  • Findings — exposures with their two-axis verdict and evidence.
  • Settings — enable the module, PR-time checks, email alerts, and review the pending-provider queue.

# Configuration

Agreement documents are stored in a private, access-controlled cloud container.

Per-org settings: Enabled, PR-time checks, Email alerts.