What's new in Console: Edition 2

We've shipped a lot since the last edition. Here's what you can use in Console from the October 14 through November 10, 2026 release window: preview environment support for CI pentests, chat with Pensar, an attack surface map, Tailscale connectivity, and more control over what agents know and when they test.

Preview environments in CI

Pensar already runs security reviews on pull requests and deployments. This update adds support for preview environments, so you can test a change against its own running deployment before merging it.

The workflow waits for your preview provider to report a successful deployment, then runs a pentest against that preview URL and commit. Pensar uses the pull request's diff to identify affected endpoints, including new routes, and decide what to test. Results come back to the pull request as a Pensar Security Review check.

You can set this up under Settings → CI/CD on the pull request tab. The CI integration docs include the workflow and configuration details.

pensar pentest \
  --base "$BASE_SHA" \
  --commit "$HEAD_SHA" \
  --url "$PREVIEW_URL" \
  --pull-request "$PULL_REQUEST"

Findings at or above your severity threshold fail the check; the default is critical. Lower-severity findings appear as annotations. A review also needs to finish testing its targets to pass.

You'll need @pensar/ci 2.8.0 or later and a preview provider that creates GitHub deployments with an environment URL. Verify the parent domain of your preview hosts once, such as preview.example.com, to cover the per-PR hosts beneath it. Credentials that sign in on your application's domain use the preview host for that run.

Give the planner your testing priorities

You can now add testing guidance under Settings → CI/CD → Testing guidance. Tell Pensar what matters in your application, such as prioritizing authentication and session handling or paying particular attention to changes in payment flows.

The planner uses that guidance alongside the diff for both commit pentests and pull-request reviews. You can also supply testingGuidance on POST /ci/dispatch for a specific run. Guidance stays within your authorized testing scope.

Chat with Pensar

Chat is now available in every workspace. Open Chats in the sidebar, or press Option+K on Mac and Alt+K on Windows or Linux, to ask about your findings, fixes, scans, and attack surface. Pensar can read your workspace records and connected repositories, explain what it found, and triage issues when you ask.

You can also open chat directly from a finding. It starts with that finding and its proposed fix, so you can ask questions about the vulnerability or work through changes to the patch. Pensar builds on the existing fix, shows you the updated diff, and saves it back to the issue. Patch refinement requires a connected repository.

See your attack surface

Map your applications and their connections

The Attack surface page now has a map view. It shows how your applications connect across the client, edge, service, data, and external layers, with dependencies labeled by type and open findings shown by severity.

Pensar generates the map after reconnaissance. You can also generate it from your current inventory, regenerate it as your system changes, and export it as JSON, Markdown, or PNG.

When a map is available, the grid and table views open on Entry points, giving you a starting point for reviewing the applications users can reach. You can switch to All applications to see the full inventory.

See when each application was last tested

Application cards and table rows now show when each application was last pentested. You can filter by recency, find applications that have never been tested, and sort the table to put the oldest tests first.

This reflects completed testing in the application, so you can use it to decide where to focus the next run.

Set your reachability check frequency

You now control how often Pensar checks whether your applications are publicly reachable. Under Settings → Recon → Reachability checks, admins can choose a frequency from every six hours to weekly, or turn automated checks off.

Each application also has a Reachability tab with the URL being checked, the last and next check times, and up to 90 days of history collected from this release onward. You can see whether the application responded and the HTTP status or connection error for each check.

Pentest private applications through Tailscale

If your applications live on a Tailscale tailnet, you can now connect it under Settings → Network → Private networks and run pentests against those private hosts.

You control which hosts and ports Pensar can reach through your tailnet policy. Console provides a policy snippet for the pentest tag, and you connect a Tailscale OAuth client scoped to that tag. Each run joins as a temporary device and is removed when testing ends.

This lets you test internal applications while keeping them on your private network. The private networks guide walks through setup. One detail to account for: runs using a private network don't use Pensar's fixed egress IP, including when the same run also tests public targets.

Give agents the context they need

Your knowledge base now gives you more control over what agents use during testing. Under Settings → Context → Knowledge base, each entry has a priority:

• Always includes the entry in every pentest, retest, and credential test. Use this for context agents need on every run, such as application roles or testing constraints.
• On request lets agents look up the entry when it's relevant.
• Off keeps the entry saved without making it available to agents.

Admins can mark up to 10 entries as Always, with a combined limit of 20,000 characters. Each entry shows how often it was used in the last 30 days, and you can open it to see the runs that used it. That gives you a way to check whether the context you're adding is actually being used.

You can search and filter entries, update priorities in bulk, and delete entries you no longer need. Priority controls are also available through the REST API and MCP. The knowledge base guide covers the details.

Schedule testing around your team

Scheduled pentests now support selected weekdays, every-other-week schedules, multiple dates in a month, and custom intervals of 1–12 days, weeks, or months.

For example, you can test every Tuesday and Thursday or on the 1st and 15th of each month. Settings → Scheduled pentests shows the upcoming run dates before you save. Schedules follow your selected local time across daylight-saving changes.

Credentials and authentication

For authenticated testing, use email and password with Pensar's agent inboxes whenever your application supports it. Give each test account the role and access you want tested, and add that context with the credential.

If your application only supports Google SSO, bring test accounts from a Google Workspace you own. For an external-user scenario, you can attach a separate testing domain to your workspace and create accounts there. Pensar's agent inboxes remain available for email-based authentication; Google login accounts should be customer-provided.

Before launching a pentest, test the credentials you want it to use. Pentests sign in with credentials whose test reached Authenticated. You can watch the agent's browser through Live desktop during a credential test or an active pentest endpoint, and review the endpoint's recording after it finishes.

Retests can also use an application's current credentials when the original account is no longer available. The agent selects the role that best matches the original proof and records when it uses replacement credentials. If it can't reproduce the required identity, the result is inconclusive.

Work with findings from your own tools

The API and MCP now expose more of the evidence behind a finding. GET /issues/:issueId/evidence and the get_issue_evidence MCP tool return the proof of concept, its output, evidence steps, attack path, and the source snippet at the recorded commit.

You can also launch a retest with retest_issue and read its history with list_issue_retests. Issue payloads include the full CVSS record and the associated application, endpoint, and repository, giving your tools the context they need to work with the finding.

The Console API reference is generated from the API's validation schemas and documents the public REST routes.