Platform¶

#194 · Secrets Vault Integration: Credentials That Stay Current

Availability: General Availability

Your scan credentials now live in one place. Create a variable once, reference it as ${KEY} in any profile, and rotate it without opening a single scan configuration. Point it at Azure Key Vault and Escape reads the current secret each time a scan starts, so a rotated password stops breaking your scans.

Organization Variables: one list for every value your scans share.

What's New

• Three variable types: Plain text stays readable. Secret is write-only after you save it. External is a reference to a secret that stays in your Azure Key Vault.
• Azure Key Vault: create an Azure Key Vault integration with a tenant ID, client ID, and client secret, then pick the vault and the secret name when you create an external variable.
• Redaction: in scan outputs, secret and external values of 6 characters or more are replaced with [REDACTED: KEY].
• Audit trail: each scan that reads variables writes an audit log entry listing the keys it used.
• API: /v3/vault-variables lists, creates, and deletes variables, POST /v3/vault-variables/{variableId}/rotate rotates one, and GET /v3/vaults lists linked vaults.

How It Works

Write ${KEY} anywhere a string value appears in a profile's configuration: a username, a password, a header, a URL.

A profile user with variable references in the username and password.

When a scan starts, Escape resolves every referenced variable once and reuses those values for the whole run. External variables are read live from your vault at that moment. If Escape fails to read one (the secret was deleted or disabled, or access is refused), the scan fails at start instead of running without credentials.

Requirements and Limits

• Managing variables and linking vaults requires Manage Vault Variables or Admin through a global role binding.
• A key is SCREAMING_SNAKE_CASE, starts with a letter, and holds up to 128 characters.
• Azure Key Vault is the external vault supported today. The service principal needs Reader on the subscription and Key Vault Secrets User on each vault.
• Values are read once at scan start: a secret must stay valid for the full run.
• Plain text values and values shorter than 6 characters aren't redacted. The variable form warns when a secret is under that length.

Variables Docs → Read the Announcement →

HashiCorp Vault is next.

Questions?

Have a question? Reach out on your dedicated support channel, or email us at support@escape.tech.

#182 · One-Click Fix in Cursor: Turn Findings Into Codebase-Tailored Remediation

Availability: General Availability

Escape closes the loop between triage and fix. When you see a finding, you no longer copy details into your IDE and rebuild context from scratch: one click from the issue side panel sends a remediation prompt straight to Cursor, Claude Code, or Codex. The prompt carries your finding so your coding agent starts with everything it needs.

What's new:

• Fix this finding: Start remediation from any issue side panel with a single action.
• IDE choice: Open in Cursor, Claude Code, Codex, or copy the prompt to your clipboard.
• Deep links: Cursor opens with the full prompt preloaded through a native deep link.

IDE integrations documentation →

Questions?

Have a question? Reach out on your dedicated support channel, or email us at support@escape.tech.

#179 · First and last login now shown for every member

The org members page now shows a first login and last login column for every member.

Together they answer the three questions admins actually ask: when did this person activate, are they using the platform consistently, and are they still around?

First login shows an absolute date, like "Jan 12, 2025." Last login shows relative time, like "3 days ago."

At a glance, you can find members who were invited but never logged in, spot accounts that have gone quiet, and check seat usage before a renewal conversation.

Status labels are also simpler now: invited, activated, deactivated.

#167 · Jira Integration: Custom Fields, Two-Way Status Sync, and Workflow Ticketing

Availability: General Availability

Run triage where your team already works: map Escape findings into the Jira fields your process depends on, keep ticket and finding status aligned when work closes on either side, and open issues from workflows with the right project, filters, and field values filled in automatically.

What's new:

• Custom field mapping: map any Escape property to any Jira field, including custom fields specific to your schema.
• Two-way status sync: resolving a finding in Escape closes the Jira ticket, and vice versa. A manual "Close in Jira" action is available from the issue view too.
• Workflow-based ticketing: create tickets straight from workflows. Filter by severity or saved view, route to the right project, and populate fields automatically.

Questions?

Have a question? Reach out on your dedicated support channel, or email us at support@escape.tech.

#165 · New Report Template: Executive Summary and Redesigned Issue Layout

Availability: General Availability

Your security report now serves the full room. A new executive summary gives leadership a clear read on your security posture and the actions worth prioritizing. A redesigned issue layout makes findings faster to triage for the engineers doing the work.

What's new:

• Executive summary: a dedicated section that distills your security posture into clear signals: risk level, trend, and the top actions worth taking, sharable to leadership without writing a separate briefing.
• Redesigned issue layout: findings are structured for triage, with evidence, severity, and remediation steps in a consistent, scannable format so you spend less time parsing and more time fixing.

Report and export documentation →

Questions?

Have a question? Reach out on your dedicated support channel, or email us at support@escape.tech.

#163 · Asset Project IDs in the Escape Public API and CLI

Availability: General Availability. Discover project IDs on every asset response in Escape's public API and CLI: map findings to your portal without extra round trips.

You can already assign assets to projects on writes. Reads stayed silent: asset payloads came back without their project assignments, so anything round-tripping through the API or escape-cli had to call /v3/projects separately to place findings in the right product bucket. Asset payloads now carry projectIds on every read endpoint, and GET /v3/assets accepts a projectIds filter for parity with /v3/scans.

What's New

• projectIds on every asset payload: returned by GET /v3/assets, GET /v3/assets/:assetId, and every endpoint that embeds an asset (issues, profiles, events, scan issues). Empty array when no project is assigned, never null.
• projectIds filter on GET /v3/assets: ?projectIds=A,B scopes a list to assets in any of those projects, mirroring the semantics already on /v3/scans.
• escape-cli assets list --project-id <uuid>: repeatable flag plumbed through to the same filter.
• PROJECTS count column in escape-cli assets list and escape-cli assets get table output. JSON output is unchanged and now includes the full projectIds array.

Why It Matters

Customer AppSec teams plugging Escape into their internal product portals told us they were running extra /v3/projects lookups just to figure out which product each issue belonged to. That's a small tax that adds up across thousands of findings. Round-tripping is now lossless: write projectIds on an asset, read them straight back. Pipelines consuming issues, profiles, or events get the project context on the first response, so you can route findings into the right bucket without a second hop.

How to Get Started

• API: read projectIds from any asset response. Filter lists with GET /v3/assets?projectIds=<uuid>,<uuid>.
• CLI: escape-cli assets list --project-id <uuid> -o json scopes the list. escape-cli assets get <id> -o json includes projectIds on every detail payload.
• SDKs: regenerate from services/public-api/v3.openapi.json to pick up the new field and query parameter.

Compatibility

Hard-Breaking Changes

None.

Soft-Breaking Changes

• Public API and CLI assets list and assets get table columns: a new PROJECTS count column sits between OWNERS and NAME. Scripts that parse the human-readable table by tab-column index need to shift their NAME index by one. JSON output (-o json) is unchanged and is the recommended target for automation.

Non-Breaking Changes

• projectIds: string[] on AssetSummarized and AssetDetailed: present on every asset returned by the public API, including embedded assets in issues, profiles, events, and scan issues. SDKs that ignore unknown response keys keep working unchanged.
• projectIds query parameter on GET /v3/assets: optional, comma-separated, OR semantics. Existing callers that don't pass it see no change.
• --project-id flag on escape-cli assets list: new optional flag, repeatable. Existing invocations are unaffected.

Questions?

Have a question? Reach out on your dedicated support channel (Slack, Microsoft Teams, or whichever channel we've set up with your team), or email us at support@escape.tech.

#161 · Public API: Clearer Error Types in Generated SDKs

Availability: General Availability

Error responses across the Escape Public API (v3) now carry explicit, semantic schema names. Every endpoint returns the same JSON payloads it always did, so direct HTTP integrations need no changes. If you regenerate an SDK from the updated OpenAPI spec, you'll see a handful of error-type renames that make decoded errors easier to read and reuse.

What's New

• Named error schemas: the 400, 404, 409, and 500 responses now expose BadRequest, PaginationError, NotFound, Conflict, and InternalServerError as semantic schema names in the spec.
• Consistent types across endpoints: regenerated SDKs use one semantic type per error shape, so you can share error-handling code across every endpoint that returns the same error.
• Spec matches reality on GET /scans/{scanId}/targets: the declared 400 schema is now a single PaginationError, matching what the server actually returns.

Why It Matters

Until today, SDKs generated from our spec produced awkward error types like ListProfiles400Response or UpdateProfile400Response, one per operation, even when the payload was identical. Writing shared error-handling meant juggling a dozen near-duplicate types. With semantic names, one handler can cover every list endpoint's pagination error, another can cover every validation error, and so on. AppSec tooling that wraps the SDK ends up with cleaner imports, fewer surprises during audits, and fewer places to update when a new endpoint shows up.

How to Get Started

• Call the API directly with JSON: nothing to do. Payloads are byte-for-byte identical.
• Use an SDK and don't regenerate: nothing to do.
• Use an SDK and regenerate from the new spec: update imports to the new type names. See the Compatibility section below for the exact renames.

Compatibility

Hard-breaking changes

None.

Soft-breaking changes

Wire payloads and HTTP status codes are unchanged. Regenerated SDKs and strongly-typed consumers will see type names and shapes change.

• SDK error-type renames: identical inline error schemas used to produce one Go, TypeScript, or Python type per operation, with names derived from the alphabetically-first operation that referenced them. They now collapse into one semantic type per error shape. Typical renames you'll see after regeneration:

  Before (example)	After
  ListProfiles400Response	PaginationError
  UpdateProfile400Response	BadRequest
  GetProfile404Response	NotFound
  IgnoreScan409Response	Conflict
  CreateAssetComment500Response	InternalServerError

  Update imports and type references to the new names. Payload fields are unchanged.

• GET /scans/{scanId}/targets 400 schema narrowed: the declared 400 used to be a union of BadRequest and PaginationError. The server has only ever returned the pagination variant on this endpoint, so the spec now declares a single PaginationError. Regenerated SDKs drop the union wrapper. Hand-written error handlers only need to match on "Invalid cursor" for this endpoint. Runtime responses don't change.

Non-breaking changes

• Named schemas in the OpenAPI spec: every 400, 404, 409, and 500 response now carries an explicit title and description for BadRequest, PaginationError, NotFound, Conflict, and InternalServerError. Payload shapes for reference:

  HTTP	Schema	Shape
  400	BadRequest	{ "message": "Bad Request", "details": string }
  400	PaginationError	{ "message": "Invalid cursor", "details": string }
  404	NotFound	{ "message": "Not found" }
  409	Conflict	{ "message": "Conflict on the following field", "field": string, "instanceId": uuid }
  500	InternalServerError	{ "message": "Internal Server Error", "details": string }

• No changes to operations, paths, methods, parameters, request bodies, success responses, or authentication.

What's Next

We keep improving the Public API, and there's more on the way.

Learn More

• Public API documentation

Questions?

Have a question? Reach out on your dedicated support channel (Slack, Microsoft Teams, or whichever channel we've set up with your team), or email us at support@escape.tech.

#158 · Workflows API OpenAPI v3.1

Breaking changes

Workflows API restructured

The single-workflow endpoints have been replaced with a resource-oriented API. You will need to update any integration that calls the workflows endpoints.

┌───────────────────┬────────────────────────┐ │ Old │ New │ ├───────────────────┼────────────────────────┤ │ GET /workflows │ GET /workflows/{id} │ ├───────────────────┼────────────────────────┤ │ PUT /workflows │ PUT /workflows/{id} │ ├───────────────────┼────────────────────────┤ │ DELETE /workflows │ DELETE /workflows/{id} │ └───────────────────┴────────────────────────┘

A new GET /workflows endpoint now returns a paginated list of all your workflows (instead of a single workflow object).

Non-breaking changes

• OpenAPI spec upgraded to 3.1 — the spec served at /v3/openapi.json now uses the OpenAPI 3.1 format. Nullable fields are now expressed as type: ["X", "null"] instead of nullable: true. This is semantically equivalent; most client generators handle both.
• New POST /workflows endpoint added to create workflows programmatically.
• Automated Pentest GraphQL profile (POST /profiles/ai-pentesting/graphql) — internal stability metadata removed from the spec; no functional change.

#154 · Updated Escape Copilot — Smarter, Faster, More Actionable

Escape Copilot just got a significant upgrade. It now understands your current context, pulls from Escape's documentation, and guides you directly to the right place in the platform.

What's new

• Page-aware context. Copilot reads your current page. Ask about a vulnerability, a scan, or how to remediate a specific issue you’re reviewing— it already knows which one you mean:

Grounded in Escape's documentation. Ask anything about the platform and Copilot pulls the answer directly from the official docs. You’ll be always working from accurate, up-to-date guidance:

• Direct links inside the platform. Copilot points you to the exact setting, result, or configuration you need:

**- Always up to date. **Copilot automatically picks up new Public API features as they ship.

How to use it:

Open Copilot from any page. Just press Cmd + Shift + E (or Ctrl + Shift + E on Windows) to activate Copilot in-app.

Ask in plain language — "what are my most vulnerable profiles?", "how do I remediate this issue?", "how do I configure my firewall?" — and get answers tied to where you are right now.

We’ve implemented a new thinking model that can perform more complex actions to ensure utmost accuracy. You might experience slower reasoning times but better output.

Try it our now!

#145 · Escape Projects Now Generally Available

Escape Projects, our feature for organizing assets and assigning clear ownership so teams can act on the findings that matter to them, is now generally available for all customers.

Projects let you map assets to logical ownership boundaries, scope access to the right users, reduce noise by filtering out unrelated findings, and accelerate remediation loops by giving teams the context they need to fix issues efficiently.

You can learn more about the feature in our documentation and how to use it efficiently in this article.

Want to set it up?

Go to Organization Settings → Projects: This is where you create, edit, and manage Escape Projects.

Happy organizing!