# What's new in Console: Edition 2 > Preview environment support for CI pentests, chat with Pensar, an attack surface map, Tailscale connectivity, and more control over testing context and schedules. Published 2026-11-10 · By Josh Kotrous · Product · 7 min read Canonical: https://pensar.dev/blog/whats-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](https://docs.pensar.dev/console/features/ci-integration) include the workflow and configuration details. ```bash 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](https://docs.pensar.dev/console/domains/private-networks) 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](https://docs.pensar.dev/console/features/knowledge-base) 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](https://docs.pensar.dev) is generated from the API's validation schemas and documents the public REST routes.