# What's new in Console: Edition 1 > The first edition of What's new in Console: pentests scoped to a commit range or an exact list of endpoints, attack paths across applications, ServiceNow and outbound webhooks, scoped API keys, and a knowledge base you can manage from the API, CLI, and MCP. Published 2026-10-13 · By Josh Kotrous · Product · 8 min read Canonical: https://pensar.dev/blog/whats-new-in-console-edition-1 Welcome to the first edition of **What's new in Console**, a regular roundup of what has shipped in Pensar Console. Each edition covers everything that has reached production since the one before it. This one covers August 26 through October 13, 2026. The biggest launch of this period was bug bounty support. Native HackerOne and Bugcrowd integrations, plus a dedicated email intake, now send external reports through the same loop Pensar runs on its own findings: reproduced by an offensive agent, patched, and retested. The [bug bounty announcement](https://pensar.dev/blog/bug-bounty-autonomous-remediation) covers how it works. This edition covers everything else that shipped alongside it. ## Test exactly what changed ### Compare two specific commits in CI Continuous pentesting in CI already narrows testing to what changed. By default, Pensar compares the commit you pass with the most recent completed pentest on the same repository. That baseline is shared across branches and environments, so it reflects the last thing Pensar tested, which isn't always the last thing you deployed. When you want to test the exact difference between two releases, you can now name both ends of the range: ```bash pensar pentest \ --commit 2222222222222222222222222222222222222222 \ --base 1111111111111111111111111111111111111111 ``` The `--base` flag requires `@pensar/ci` 2.7.0 or later, and the API accepts the same pair as `commitSha` and `baseSha` on `POST /ci/dispatch`. GitHub Actions detects the repository automatically. Elsewhere, pass `--repo-id`. Both commits must exist in that repository: if one is missing, the request fails instead of quietly falling back to a full scan. If the two commits are identical, there's nothing to test and the run is skipped. ### Launch against an exact list of endpoints `POST /pentests` and the `dispatch_pentest` MCP tool now accept `endpointIds`, a list of up to 1,000 endpoints already discovered in your workspace. Pensar works out which applications those endpoints belong to and tests only them, at full depth. From the CLI, repeat `--endpoint-id`, pass a comma-separated list, or point `--endpoint-ids-file` at a file with one ID per line. This is the most precise way to drive a pentest from your own tooling: you decide exactly which routes are in scope, and the run stays inside them. An endpoint-scoped launch can't also pin a branch. ### Tell the agent how your applications connect Custom Tests that span two or more applications have a new, optional **System relationships** section. Use it to describe how the services relate: HTTP calls, JWT trust, shared sessions, SSRF vectors, data flows, or anything else you spell out yourself. The agent uses those relationships to chain findings across services, and it still explores paths you didn't declare. When a finding from one of these runs involves more than one application, the issue page shows an **Attack path**: the ordered list of applications the agent moved through to demonstrate it. ### Guardrails on actions that move money Agents now treat requests that create or move money, such as payments, payouts, transfers, refunds, and charges, as destructive. They stay blocked unless you turn on **Test destructive actions** in the advanced step of the launch wizard. That's the same opt-in that already governs deletes, drops, and truncates, and it's off by default. ## Send findings to where your team works ### Outbound webhooks **Settings → Webhooks** lets you register an endpoint and subscribe it to five events: `issue.created`, `issue.updated`, `issue.status_changed`, `retest.completed`, and `pentest.completed`. Every delivery is signed. The signing secret is shown once, when you create the endpoint, so store it then. To pull an issue's retest history into your own systems, call `GET /issues/:issueId/retests`. ### ServiceNow, plus Linear and Notion upgrades **Settings → Issue tracking** now supports ServiceNow alongside GitHub Issues, Linear, and Notion. | Tracker | What's available | | --- | --- | | ServiceNow | **New.** Connect your own instance with OAuth or a service account, and choose the table each repository's findings land in. A business rule on your instance can send status changes back to Pensar. | | Linear | Route synced issues to a Linear project, and apply existing labels by default or per finding. Teams that restrict label creation keep that restriction. | | Notion | Pick a database per repository. Status and severity are written onto that database's properties. | | GitHub Issues | Sync findings to a repository, with an option to bring status changes made on GitHub back into Pensar. | Changes you make in Pensar are pushed to the connected tracker. Where the tracker supports it, status changes made there flow back to the finding. ### Review from the API, CLI, and MCP Issue review now works the same way from the REST API, the CLI, and MCP as it does in Console. You can read and post comments, close a finding with a reason (resolved, duplicate, won't fix, out of scope, or risk accepted), and close it as a duplicate of a specific original issue. Issue payloads also include the issue's short label and a direct link to it in Console. Posting a comment requires a signed-in user, so every comment has a real author. A workspace API key can read comments but can't post them. ## Put your knowledge base to work Your workspace knowledge base lives in **Settings → Context**. Entries render as Markdown, and you can open any entry to read it in full. They're organized as false positives, tech context, user notes, agent learnings, and testing history. The knowledge base is now available everywhere you work, and agents rely on it in more places: - **Manage it anywhere.** `pensar knowledge` can list, get, add, update, and archive entries, and the REST API and MCP expose the same operations. - **Retests and credential tests use it.** Active entries are included when an agent retests a finding or tests a credential. - **Point a pentest at specific entries.** A Custom Test can reference entries in its objective, and an API or MCP launch can attach up to 20 of them. - **Agents add to it.** When an agent learns something about your environment, it records it as an agent learning entry in the workspace. API keys can read entries, but creating or editing one requires a signed-in user. That matters because a false-positive pattern can suppress findings, so an unattended key can't change what your agents ignore. ## Reports, severity, and evidence **Executive summaries.** Any pentest report can now be downloaded as the full PDF or as a shorter **Executive summary** for readers who don't need every finding. Reports generated before this change need to be regenerated once to produce the summary. **Reports that match your issues list.** Both versions of the report respect the close reasons you've set: duplicates aren't counted as open findings, and remediated findings get their own breakdown. **CVSS-driven severity.** A finding's severity is now derived from its CVSS score. You can paste a full vector string into the CVSS editor, and reviewers can still override the severity when the score doesn't reflect the real risk. **Recordings in step with the log.** On blackbox runs, scrubbing an endpoint recording keeps it aligned with the agent log, so the request on screen is the one you're reading about. ## Workspace and access **Scoped API keys.** Admins and owners can now limit a key to exactly what it needs, with read or write access per area (issues, pentests, fixes, inventory, reports, knowledge, and settings) plus separate permissions to launch pentests, add repositories or domains, and spend inference credits. Presets cover read-only, CI, Apex CLI, and full access. Keys can be given an expiration date, and the key list shows when each one was last used. **Credentials scoped to applications.** A credential can be assigned to specific applications, and agents only receive it when those applications are in scope. Unassigned credentials stay available across the workspace. Client certificates are the exception and must be assigned explicitly. Username and password credentials have a new **Mobile OTP** option that reserves a Pensar-managed phone number for logins that send an SMS code, and saved secrets can now be revealed and copied from the credential sheet. **Hostname mappings.** **Settings → Agent network** lets you map a hostname to a specific public IP address. New agent runs resolve that hostname to the address you set, much like an entry in a hosts file. **Subagents.** **Settings → Pentesting** has a new **Subagents** switch, off by default. When it's on, the agent acts as an orchestrator and spawns a focused subagent for each objective on each target. Testing goes deeper, but runs take longer and cost more. ## Fixes and smaller improvements - Patches open their pull request on the repository the finding belongs to, and the patch job completes once that pull request is open. - Renaming a repository on GitHub updates the existing connection, so its applications and findings stay attached.