Changelog: 13 entries

src/content/changelog/2026-06-10-5-new-access-review-connectors-june-2026.mdx

@@ -0,0 +1,12 @@
+---
+title: "5 New Access Review Connectors: Better Stack, SigNoz, Neon, Render, Qovery"
+description: "Pull user access straight from five more infrastructure and observability tools."
+date: 2026-06-10
+tags: ["Console"]
+---
+
+Access reviews are only as complete as the systems you can connect. This batch adds five more.
+
+Better Stack and SigNoz cover observability, so you can review who has access to your monitoring and logging stack. Neon, Render, and Qovery cover infrastructure, letting you pull organization members straight from your database and deployment platforms.
+
+All five connect with an API key, same as the rest of the access review connectors. Add them from the connectors page and they show up in your next campaign.

src/content/changelog/2026-06-10-nested-third-party-relationships.mdx

@@ -0,0 +1,13 @@
+---
+title: "Nested Third-Party Relationships"
+description: "Third parties can now nest to any depth, not just one level of sub-vendor."
+date: 2026-06-10
+image: "/changelog/2026-06-10-nested-third-party-relationships.png"
+tags: ["Console"]
+---
+
+Third-party relationships used to support exactly one level: a vendor and its direct sub-vendors. Anything past that had no home in the data model.
+
+Third parties can now nest to arbitrary depth. Each third party carries a reference to its parent, and the console, API, and CLI (`prb third-party list --level N`) all understand levels beyond the first. If your vendor's subprocessor has its own subprocessor, that relationship is now representable instead of flattened.
+
+This also cleans up how sub-vendor links work generally: they're just a parent reference on the third party itself now, instead of a separate link/unlink relationship to manage.

src/content/changelog/2026-06-12-auto-enriched-vendor-catalog.mdx

@@ -0,0 +1,13 @@
+---
+title: "Auto-Enriched Vendor Catalog"
+description: "Import vendors from a shared catalog instead of typing in the same third-party details your peers already found."
+date: 2026-06-12
+image: "/changelog/2026-06-12-auto-enriched-vendor-catalog.png"
+tags: ["Console"]
+---
+
+Every org that adds Stripe or Datadog as a third party ends up typing the same legal name, headquarters, and compliance docs someone else already looked up.
+
+Probo now keeps a common third-party catalog that fills itself in. A background enricher researches legal name, headquarters, canonical website, compliance certifications, and logo for common vendors, with a confidence score behind each field. When you add a third party that matches an existing catalog entry, you can import it directly instead of starting from a blank form.
+
+Catalog vendors also show up in your tracker policy documents automatically, so cookie and tracker disclosures reference the same vetted third-party data your team is already using.

src/content/changelog/2026-06-16-electronic-signatures-employee-documents.mdx

@@ -0,0 +1,12 @@
+---
+title: "Electronic Signatures for Employee Documents"
+description: "Employee document signings now generate a real signed PDF and an esign record, the same way document approvals already did."
+date: 2026-06-16
+tags: ["Compliance Page"]
+---
+
+Document approvals in Probo already produced a signed PDF and an esign record capturing the signer's IP and user agent. Employee document signings, like acknowledging a policy or signing an NDA, did not.
+
+Now they do. When an employee signs a document, Probo generates the signed PDF, creates the esign record, and captures the same consent wording used across signing, approval, and NDA pages, so the legal language is consistent everywhere a signature happens.
+
+If you're relying on employee sign-offs as audit evidence, this closes the gap between what approvals captured and what plain signings captured.

src/content/changelog/2026-06-19-connect-ai-agents-oauth2-cimd.mdx

@@ -0,0 +1,13 @@
+---
+title: "Connect AI Agents via OAuth2 (CIMD)"
+description: "MCP clients like Claude and ChatGPT can now register with Probo through a standard OAuth2 client metadata document instead of a pre-provisioned client ID."
+date: 2026-06-19
+image: "/changelog/2026-06-19-connect-ai-agents-oauth2-cimd.png"
+tags: ["MCP"]
+---
+
+Connecting an MCP client to Probo used to mean provisioning a client ID by hand first.
+
+With OAuth2 Client ID Metadata Document (CIMD) support, clients like Claude and ChatGPT register themselves by pointing at an HTTPS client_id URL. Probo fetches and caches the metadata document, upserts the client on first use, and advertises CIMD support in OIDC discovery once you've configured which client URLs are allowed.
+
+It's opt-in. Nothing changes until you add allowed CIMD client URLs to your OAuth2 config, and existing pre-provisioned MCP clients keep working exactly as before.

src/content/changelog/2026-06-19-personal-api-tokens.mdx

@@ -0,0 +1,13 @@
+---
+title: "Personal API Tokens"
+description: "Create, list, and revoke your own bearer tokens for scripting against the Probo API, without sharing a service account."
+date: 2026-06-19
+image: "/changelog/2026-06-19-personal-api-tokens.png"
+tags: ["IAM"]
+---
+
+Until now, calling the Probo API outside the console meant either building an OAuth2 app or borrowing a token meant for something else.
+
+Personal API tokens fix that. Head to `/me/oauth-tokens` in the console, and you can create a bearer token scoped to your own identity, list the tokens you've issued, and revoke any of them on the spot. Every v1 API scope is now registered and enforced, so tokens only work for what they were actually granted.
+
+Auditors get the `v1:iam:read` scope by default, which covers the read-only API access most audit tooling needs without a separate request.

src/content/changelog/2026-06-22-custom-url-slugs-trust-center.mdx

@@ -0,0 +1,12 @@
+---
+title: "Custom URL Slugs for the Compliance Portal"
+description: "Give Compliance Portal pages a memorable URL instead of a generated ID."
+date: 2026-06-22
+tags: ["Compliance Page"]
+---
+
+Compliance Portal entries used to live at whatever ID Probo assigned them. Fine for the app, not great for a link you want to put in a sales deck.
+
+Now you can set a custom alias on any Compliance Portal entry, and the page resolves at that alias instead of the raw ID. Set or remove aliases from the console, the API, or the CLI (`prb resource-alias`), and existing links keep working alongside the new one.
+
+Small change, but it's the difference between sending a prospect a readable link and sending them a UUID.

src/content/changelog/2026-06-24-docusign-signing-integration.mdx

@@ -0,0 +1,12 @@
+---
+title: "DocuSign Signing Integration"
+description: "Connect DocuSign with OAuth2 and pick which account to use, no manual API key wrangling required."
+date: 2026-06-24
+tags: ["Console"]
+---
+
+Some teams run their signing workflows through DocuSign instead of Probo's built-in e-signature flow. Now you can connect the two.
+
+The integration uses a full OAuth2 authorization-code flow with PKCE, so there's no API key to copy around. If your DocuSign login has access to multiple accounts, you'll get an account picker; the account you choose is saved, and Probo resolves the correct regional data-center URL for it automatically.
+
+Connect it from the integrations page and your DocuSign account stays linked until you disconnect it.

src/content/changelog/2026-06-24-five-new-access-review-connectors-mercury-apollo-deepgram.mdx

@@ -0,0 +1,12 @@
+---
+title: "Five New Access Review Connectors: Mercury, Apollo.io, Deepgram, ClickHouse Cloud, Langfuse"
+description: "Cover banking, sales tooling, and AI infrastructure in your next access review campaign."
+date: 2026-06-24
+tags: ["Console"]
+---
+
+Access review connectors keep expanding to match what teams actually run. This batch adds Mercury for banking access, Apollo.io for sales tooling, and three AI-adjacent platforms: Deepgram, ClickHouse Cloud, and Langfuse.
+
+Some of these connectors also support a custom Authorization header scheme instead of the default Bearer token, since not every API speaks the same auth dialect. That's a small detail, but it's what let us add API-key connectors for tools that would have otherwise needed a one-off integration.
+
+Connect them from the connectors page and include them the next time you run a campaign.

src/content/changelog/2026-06-25-four-more-access-review-connectors-pylon-openrouter.mdx

@@ -0,0 +1,12 @@
+---
+title: "Four More Access Review Connectors: Pylon, OpenRouter, incident.io, Brevo"
+description: "Support, AI routing, incident response, and email marketing join the access review connector list."
+date: 2026-06-25
+tags: ["Console"]
+---
+
+Four more API-key connectors landed: Pylon for customer support, OpenRouter for AI model routing, incident.io for incident response, and Brevo for email marketing.
+
+Same setup as every other API-key connector: add your key on the connectors page, and the tool's members show up the next time an access review campaign runs.
+
+This keeps growing because access reviews only work if every tool with real user access is in scope, not just the obvious ones like your IdP.

src/content/changelog/2026-06-30-deeper-third-party-vetting-reports.mdx

@@ -0,0 +1,13 @@
+---
+title: "Deeper Third-Party Vetting Reports"
+description: "Third-party vetting now keeps the full structured analysis, not just a short summary."
+date: 2026-06-30
+image: "/changelog/2026-06-30-deeper-third-party-vetting-reports.png"
+tags: ["Console"]
+---
+
+Async third-party vetting has been running for a while, producing a summary paragraph on risk classification and data handling for each vendor you vet.
+
+That summary was throwing away most of what the vetting agent actually found. Vetting notes now persist the full structured breakdown: risk classification, a per-category analysis, privacy and data-processing practices, AI governance posture, contractual clauses, and professional standing.
+
+If you've been vetting vendors and wanted more than a paragraph to back up your decision, it's already there. Nothing to turn on, existing and future vetting runs both get the full breakdown.

src/content/changelog/2026-07-02-document-lifecycle-webhooks.mdx

@@ -0,0 +1,13 @@
+---
+title: "Document Lifecycle Webhooks"
+description: "Subscribe to document created, updated, signed, and approved events instead of polling for changes."
+date: 2026-07-02
+image: "/changelog/2026-07-02-document-lifecycle-webhooks.png"
+tags: ["Console"]
+---
+
+If you wanted to know when a document got signed or a new version got published, you had to poll the API and diff the result yourself.
+
+Document lifecycle events are now webhook subscribable: created, updated, archived, unarchived, deleted, plus the version, signature, and approval sub-events underneath each document. Wire up a webhook once and get notified the moment any of those happen.
+
+The CLI's `prb webhook create`/`update` commands cover the same event list, so you can wire this up without leaving your terminal.

src/content/changelog/2026-07-02-n8n-trigger-workflows-from-probo-events.mdx

@@ -0,0 +1,13 @@
+---
+title: "n8n: Trigger Workflows from Probo Events"
+description: "A new Probo Trigger node starts your n8n workflow the moment a document event happens, no polling node required."
+date: 2026-07-02
+image: "/changelog/2026-07-02-n8n-trigger-workflows-from-probo-events.png"
+tags: ["Integrations"]
+---
+
+Automating anything downstream of a Probo event used to mean polling on a schedule and diffing state in your n8n workflow.
+
+The new Probo Trigger node replaces that. It owns the whole webhook subscription lifecycle: it registers a subscription when you activate the workflow, re-registers it if your webhook URL changes, and cleans up the subscription when you deactivate. It also verifies the HMAC-SHA256 signature on every event, so you're not trusting an unauthenticated payload.
+
+It covers the same document lifecycle events as the API: created, updated, archived, unarchived, deleted, plus version, signature, and approval events. Point it at the event you care about and skip the polling node entirely.