> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/product-updates/blog/2026.4.md).

# Veza Product Update - 2026.4

The 2026.4 release weaves AI-powered intelligence deeper into daily security workflows, embeds NHI governance actions throughout the platform, and broadens integration coverage with new ITSM and HRIS connectors. Teams gain richer query context, faster extraction performance, and more precise lifecycle automation.

Veza 2026.4 highlights include:

* **Veza Integrations**: New integrations for Freshservice and Personio; Kubernetes RBAC policy rule visibility; CyberArk Privilege Cloud enhancements; AWS Lambda Layer discovery; in-app certificate generation extended to ServiceNow and Snowflake; expanded support for identity mapping templates; AWS IAM batch extraction optimization.
* **Access Intelligence**: Access AI explanations for dashboard tiles and query details; AI-suggested query enhancements; improved dashboard trend indicators; Role Mining for Microsoft Entra ID.
* **NHI Security**: AI-powered Suggested Owners for unowned NHIs; key rotation for Azure Key Vault keys; improved ServiceNow dormancy detection via Machine Identity Console; new owner management and NHI Agents API endpoints.
* **AI Agent Security**: Support for ServiceNow AI Agents, Tools, and Skills; enhanced AWS Bedrock agent discovery.
* **Access Reviews**: Access Path Risk Scores, improved UX for multi-level reviews; review completion statistics for Watchers.
* **Lifecycle Management**: Get Node From Graph action for graph-aware workflow execution; real-time provisioning policy status; bulk dry run export; Google Workspace OU targeting.

Please see the sections below for details on each product area, and contact your Veza representative with questions or feedback.

### **Veza Integrations**

#### **New Integrations**

**Freshservice from Freshworks**: Veza now integrates with the Freshservice IT service management platform. The integration discovers agents, groups, and roles for access reviews and Access Graph queries.

Optional CMDB extraction brings Configuration Items into the Access Graph with cross-service connections to their owner identities and linked cloud resources. Enrichment rules can then traverse from any Veza entity via the linked CMDB asset record to identify an owner. For example, Veza can trace an S3 bucket through its CMDB asset record to identify the responsible owner listed in Freshservice.

For setup instructions, see [Freshservice](/4yItIzMvkpAvMVFAamTf/integrations/integrations/freshservice.md).

**Personio**: A new HRIS integration with Personio discovers employees, departments, teams, and cost centers, including reporting relationships, employment status, and custom Personio attributes. Personio identities map to IdP and application users for Access Graph queries and access reviews.

For setup instructions, see [Personio](/4yItIzMvkpAvMVFAamTf/integrations/integrations/personio.md).

#### **Integration Enhancements**

**AWS IAM Batch Extraction Optimization**: The AWS IAM integration now retrieves policies and roles in batches for reduced extraction time. The integration also now supports fetching tags for customer-managed policies.

For integration details, see [AWS](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws.md).

**AWS Lambda Layers**: The AWS integration now discovers Lambda Layers and Lambda Layer Versions as distinct entity types, with IAM permissions and effective permissions on Lambda Layer resources. Queries and access reviews can now search Lambda Layer infrastructure alongside existing Lambda function coverage.

For integration details, see [AWS](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws.md).

**Kubernetes RBAC Policy Rule Visibility**: The Kubernetes integration now surfaces policy rules directly in the Veza UI and Access Graph. Administrators can now inspect and query policy rules associated with roles to discover permissions on Kubernetes resources across clusters.

For integration details, see [Kubernetes](/4yItIzMvkpAvMVFAamTf/integrations/integrations/kubernetes.md).

**CyberArk Privilege Cloud AD Group Privileges**: The CyberArk Privilege Cloud integration now discovers Active Directory group privileges to Safes. The integration links group safe members to their effective permissions. Azure AD and Active Directory principals also connect to their identity provider nodes, completing access paths from external directories to CyberArk resources.

For integration details, see [CyberArk Privilege Cloud](/4yItIzMvkpAvMVFAamTf/integrations/integrations/cyberark.md).

**LDAP Transient Error Resilience**: LDAP extraction now retries automatically when the server returns a transient Code 52 ("Unavailable") response. Brief server interruptions that earlier caused extraction failures now recover without manual intervention.

**Expanded Identity Mapping Templates**: Custom identity mapping templates now support any entity property and a more complete range of string transformation functions.

Users can now reference any property on the source or destination entity by name (for example, `{principal_name}`, `{employee_id}`, `{mail_nickname}`), and chain transformations for case conversion, substring extraction, and trimming, padding, or character replacement. For more information, see [Template Transformations](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md#template-transformations).

**Identity Mapping UX Improvements**: When configuring custom identity mappings, Veza now dynamically lists available source node types and mapping modes (user, group, role) for each integration, with clearer suggestions for property matching. For configuration steps, see [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md).

**IdP Application Entity Owner Assignment**: Identity provider application entities (including OktaApp, OneLoginApp, AzureAD Enterprise Application, PingOne, and custom IdPs) now accept entity owner assignment. Administrators can assign owners through the management API or enrichment rules, making these application entities eligible for owner-based access reviews and governance workflows.

**In-app Certificate Generation for ServiceNow and Snowflake**: In March, we introduced faster integration via downloadable credentials when configuring SharePoint Online and Okta integrations. This option is now available for ServiceNow and Snowflake integrations.

**Collapsible Integration Configuration Sections**: Integration configuration forms now group advanced and optional settings into collapsible sections, reducing visual clutter when setting up or editing integrations. Inline validation applies in collapsed sections as well, and conditional fields update dynamically based on earlier selections.

### **Access Intelligence**

#### **Product Design and Usability**

**Dashboard Absolute Delta Trend Indicators**: Dashboard tiles now show change as an absolute delta with a color-coded direction arrow, replacing the earlier percentage-based metric. The arrow's color reflects whether the trend has improved or worsened (relative to the start of the selected time period).

![Dashboard tiles showing absolute delta trend indicators with color-coded direction arrows](/files/R23A8siJdrlbGNy78mQg)

**Risks Page as Default Landing**: Selecting **Access Intelligence** from the navigation menu now navigates to the Risks page by default. The earlier Overview page displays a retirement notice directing users to the Integrations page for equivalent metrics.

![Access Intelligence navigating to the Risks page by default](/files/Z2BqpbVDelQCKJt4013F)

**Standardized Alert and Remediation Templates**: Veza now uses unified human-readable templates when posting rule-based alerts and remediation tickets to ServiceNow, Jira, and Slack. Each ticket now includes a `[Veza Action] <Severity>: <Query Name>` or `[Veza Alert - <Severity>] <Rule Name>` title, and includes a structured default body with query or rule details: severity, triggered-by user, trigger time, source and destination entity types, and a deep link back to Veza. Any notes added in the remediation form are appended.

Previously, ServiceNow alert descriptions were single-line summaries with the JSON payload in comments; earlier Jira and Slack remediation messages included query name, notes, and a link to Veza. The JSON payload is still submitted as a ServiceNow comments entry or Jira `details.json` attachment for downstream automation.

#### **Access AI Integration**

Access AI features are enhanced to streamline the query process, improve conversation organization, and provide deeper explainability for dashboards and saved queries.

* **Save Suggested Queries**: When Access AI suggests a query during a conversation, a **Save Query** action now persists it directly from the chat. This helps shorten the path from natural-language exploration to reusable saved queries.
* **Conversation Folder Selection**: The Access AI prompt interface now includes a **destination folder** picker. You can use this to file and organize new conversation threads on creation, helping keep sessions organized and accessible.
* **Dashboard Tile Explanations**: Dashboard tile action menus now include an **Explain with Access AI** option. This opens the Access AI chat panel for a plain-language explanation of the tile's underlying query. Veza stores each explanation for fast reuse across teams.
* **Query Details Explanations**: The Query Details page action menu now includes an option to **Explain Query**. This opens the Access AI side panel to describe the query configuration, the access patterns it covers, and how to interpret the results.

#### **Direct Remediation Enhancements**

* **Remediation Without Risk Level**: Remediation actions no longer require that queries be assigned a risk level. Any query, including Non-Human Identity (NHI) queries that do not use risk scoring, is now a valid candidate for enabling direct remediation on the query results.
* **Disable Accounts: Dashboard Toggle**: Administrators can now toggle the **Disable Accounts** remediation action for supported queries from the dashboard tile options menu. Previously, this required navigating to the query details page.
* **Disable Accounts: Provisioning Error Messaging**: When a Disable Accounts action fails because provisioning is not enabled on the integration, Veza now shows a clear notification explaining the cause. The earlier error message did not indicate that provisioning needed to be enabled.

#### **Role Mining Enhancements**

* **Role Mining for Microsoft Entra ID**: Role Mining now supports Microsoft Entra ID as a data source. Administrators can analyze Entra ID access patterns alongside existing supported integrations to identify opportunities for role consolidation and right-sizing. For setup steps, see [Role Mining](/4yItIzMvkpAvMVFAamTf/features/insights.md) and the [Role Definitions how-to guide](/4yItIzMvkpAvMVFAamTf/features/insights/role-definitions-how-to-guide.md).

### **Access Visibility**

#### **Enhancements**

**"Unsupported Conditions" Column**: Query Builder now includes an **Unsupported Conditions** column:

* When Veza cannot fully evaluate one or more conditions attached to a permission, the column flags those rows in the results table and CSV exports.
* Analysts can use these to identify where conditional access policies apply, even if Veza cannot fully resolve the specific condition.

For background on which AWS policy condition operators Veza supports, see [Conditions in Policy Statements](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-info.md#conditions-in-policy-statements).

**Background Query Partial Results**: Users can now view background query results before the query finishes loading.

Once Veza has fetched enough initial data, you can click **View Results** to show partial results while the remaining rows are processed. A progress indicator shows the overall query completion status.

### **NHI Security**

#### **New Features**

**Suggested Owners for Non-Human identities (Early Access)**: A new AI-powered analysis workflow identifies the most likely human owner of an unowned NHI entity by traversing Veza's Access Graph.

The agent analyzes NHI metadata and tags, direct edges and connected entities, ownership patterns from similar NHIs, and graph proximity, then resolves each candidate against your connected identity providers.

Up to three owner candidates surface with confidence scores and reasoning, allowing security teams to assign ownership to unowned service accounts, API keys, and other NHI entities at scale. See [NHI Suggested Owners](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-suggested-owners.md).

**NHI Key Rotation (Early Access)**: Veza can now rotate cryptographic keys directly from the platform, starting with Azure Key Vault as the first supported credential type.

In NHI Security, a **Rotate Key** action lets teams remediate keys flagged by security queries in one click, eliminating context switching to the Azure portal.

The same action is available in Lifecycle Management workflows for scheduled or event-driven rotation, executing up to five keys in parallel with per-key success and failure reporting. See [Rotate Key](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/rotate-key.md).

#### **Enhancements**

**ServiceNow NHI Dormancy Detection**: ServiceNow NHI dormancy detection now uses two additional data sources for more precise last usage detection:

* The `last_login_at` attribute uses the `last_login_time` field (datetime precision) as the primary source, falling back to `last_login` (date precision) when unavailable.
* For Zurich or later, Veza also reads API call timestamps from the Machine Identity Console (`sys_mi_user_tracker`). Veza uses the most recent timestamp across both sources as the last-use date.

NHIs that authenticate only through REST or OAuth are no longer flagged as dormant. Instances without the Machine Identity Console skip this enrichment gracefully.

**Owner Management API**: The Owner Management v1 API introduced in the 2026.3 release is updated with new endpoints:

* **List Available Owners** (`POST /api/v1/list_available_owners`): Returns a paginated, searchable list of active IdP users eligible for owner assignment, supporting programmatic lookup before batch assignment.
* **Batch Set Owners** (`POST /api/v1/batch_set_owners`): Assigns, adds, or removes entity owners across up to 1,000 entities in a single request. Supports incremental and replacement updates.

For endpoint details, see [Owner Management API](/4yItIzMvkpAvMVFAamTf/developers/api/management/owners.md).

**Enrichment Rules API**: A new `GetValidEnrichmentRuleOtherNodeQueries` API endpoint returns the saved queries compatible with the **Owner Query** field in dynamic owner assignment rules.

The endpoint covers cases where ownership metadata is available on a related entity (such as a CMDB Configuration Item), enabling automated owner assignment from connected nodes in the Access Graph.

### **AI Agent Security**

#### **Enhancements**

**ServiceNow AI Agents**: The ServiceNow integration now discovers AI Agents, Tools, Gen AI Skills, AI Models, and Gen AI Configs from the Now Assist platform, and parses the ACL rules governing access to each.

![Access Graph showing a ServiceNow AI Agent with linked ACL rules and user associations](/files/P88oHU04Lfs9UCetEcqG)

* AI Agents that run as a specific ServiceNow user are now linked to that user, exposing AI-driven access paths in the Access Graph.
* This capability requires the AI Agent Studio (`sn_aia`) plugin. For more on discovered AI entities for ServiceNow and AWS Bedrock, see [AI Agent Security: Supported Entities](/4yItIzMvkpAvMVFAamTf/features/ai-agent-security/supported-entities.md).

**AWS Bedrock Agents**: AWS Bedrock AI Agent entities in Access Graph now represent individual agent versions, rather than the parent agent container.

![Access Graph search results showing AWS Bedrock agent versions with version-level entities](/files/5iJW3JNa8CddLg8ZLqNR)

* Each version carries its own active status, platform, publisher, and model association, for visibility into which versions can access specific foundation models and IAM roles.
* Queries and saved searches for AWS Bedrock AI Agents now return version-level entities. The parent agent container remains as an identity node in the Access Graph.

**AI Agent Security APIs**: Four new public endpoints (`GET /api/v1/nhi/ai/...`) extend the NHI Agents v1 API, enabling programmatic listing of AI platforms, model publishers, model families, and model series discovered in Access Graph. For endpoint details, see [NHI Agents API](/4yItIzMvkpAvMVFAamTf/developers/api/nhi.md).

### **Access Reviews**

#### **Access Path Risk Scores in Access Reviews**

**Access Path Risk Score**: Each row in an access review now shows a single Access Path Risk Score (0–100) and Risk Level (Critical, High, Medium, Low, or None) when Access Intelligence is enabled. Before, risk scores were assigned individually to User, IDP User, and Resource sections. This enables at-a-glance exposure comparison of access risk per row, without the need to reconcile separate risk scores.

![Access review rows showing consolidated Access Path Risk Score and Risk Level columns](/files/Cf1qxRWLP8UpkSh4lQkg)

For default column customization, see [Access Review Columns](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/columns.md). For methodology, see [Access Path Risk Score](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/access-path-risk-score.md).

#### **Product Design and Usability**

**Due Date Visibility for Multi-Level Reviews**: When multi-level approval is enabled, the main Reviews list page now shows a *Level 1 Due Date* column. The original *Due Date* column is now shown as the *Final Due Date*.

Pending reviews have color-coded due-date icons: a warning for reviews due within 7-15 days, a critical highlight for reviews due within 7 days, and an alert for reviews overdue.

![Access Reviews list showing the new Level 1 Due Date and Final Due Date columns](/files/LfDUC6zaRbLEpzF9XeiB)

For single-level reviews, both columns show the same value. Highlighting applies only when the review is on level 1.

For multi-level approval setup, see [Multi-Level Approval](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/multi-level-approval.md).

**Multi-Role Reviewer Tabs and Progress**: Reviewers can now better distinguish between the rows they must personally decide on and the broader population of review items they can also view.

Users who hold the *Access Reviewer* role alongside another role (such as Operator or Watcher) now see tabs at the top of the Reviewer Interface: *All* and *Assigned to Me*.

* *All* refers to all rows across all reviews visible to the user.
* *Assigned to Me* refers to only the rows across reviews explicitly assigned to the reviewer.

Each tab shows its own row count and completion progress. The review progress indicator is now labeled *My Progress* on the *Assigned to Me* tab to make the scope explicit.

**Application Labels on Review Configurations**: Review Configurations now support custom labels to organize and filter reviews per-application. Any reviews derived from the labeled configurations are categorized accordingly, enabling operators to filter both the Configurations list and the main Reviews list page.

**Enhanced Filter Support**: When filtering rows in a review, you can now choose the "In" operator. This enables specifying a comma-separated list of values in a single filter and matching on any value in the list. Previously, this required manually adding multiple "Or" filter conditions.

Additionally, the Reviewer filter in the reviewer interface now supports the Does Not Equal operator in addition to Equals and Contains. Reviewers can use this operator to verify which rows are not assigned to a particular reviewer.

For example, an admin can now confirm that all Azure AD security group rows are assigned to the application owner by filtering for rows where Reviewer Does Not Equal the application owner's identity.

**Horizontal Scroll Indicator**: The list of reviews and the Reviewer Interface now indicate when columns exist beyond the visible viewport, enabling reviewers to discover off-screen columns quickly when working with extra-wide reviews.

#### **Enhanced Access Reviews Administration**

**Default Due Dates for New Reviews**: Administrators can now specify default due dates globally or per Review Configuration through the API. The configuration includes both the final Review Due Date and (for multi-level reviews) the Level 1 Due Date, enabling new reviews to start with consistent schedules without manual entry on each one.

**Verify Remediations - Override Fixed or Rejected**: Administrators can now switch a row's decision between Fixed and Rejected on completed reviews to correct rows that were incorrectly marked. Additionally, the validation job now runs bidirectionally: rows previously marked *Fixed* are automatically reverted to *Rejected* if the access reappears in the graph after the review closes.

For details, see [Verify Remediations](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/verify-remediations.md).

**Watcher Role Improvements**: Users with the *Watcher* role can now view access review completion statistics directly from the reviews list page.

Watchers can also now select a review to open the Review Details side panel.

Cumulatively, these changes are intended to give full read-only visibility into review progress, without requiring an Operator or Admin role.

### **Lifecycle Management**

#### **New Features**

**Get Node From Graph Action**: Provisioning policies now support a new **Get Node From Graph** action that queries the Veza Access Graph for entities during workflow execution. One typical use case for this action is verifying that a user exists and is active in a target system before submitting a provisioning request.

![Provisioning policy workflow editor showing a Get Node From Graph action configuration](/files/fhX42lpi6RrMCMQAXPDL)

* The action returns a read-only set of nodes that subsequent steps can branch on or reference by attribute.
* The action supports SCIM filter syntax (for example, `active eq true` or `email eq {email}`) and transformer template variables to include values from earlier actions.
* Retrieved nodes enable branching in workflows via the `NODE_IN_GRAPH` and `ENTITY_TYPE_IN_OUTPUT` conditions. Their attributes can be referenced by later actions using `{EntityType.attribute}` syntax (for example, `{OktaUser.login}`).

For more details, see [Get Node From Graph](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/get-node-from-graph.md).

#### **Enhancements**

**Real-time Policy Processing Status**: Provisioning policies now show real-time processing status (Running, Awaiting, Stopped, or Disabled) instead of a static Enabled/Disabled tag.

![Lifecycle Management Dashboard showing a policy with an Awaiting status pill](/files/wyvruuXPJXSGhHxyqHXP)

Clicking any active status pill opens a detailed Extraction Run view showing each pipeline step (identity detection, validation, workflow filtering, and task execution) with live statistics and links to the Activity Log.

**Bulk Dry Run Export**: A new export option in the bulk dry run results table downloads all results to a file, including identity details, department, and labels.

**Azure License Distinction for Deprovisioning**: For Azure/Entra ID Deprovision Identity and Manage Relationships actions, Veza now distinguishes between directly-assigned and group-inherited licenses.

Veza now skips group-inherited licenses during deprovisioning, since Entra ID releases them automatically when group membership ends. This avoids the errors that surfaced earlier when the integration tried to remove inherited licenses directly.

**SCIM Configurable Unique Identifiers**: The SCIM Configurable Unique Identifiers enhancement allows administrators to select either `userName` (default) or `emails` as the unique identifier for matching against SCIM-target users in the **Sync Identities** action.

Veza uses the selected attribute to find an existing user record before deciding whether to create or update it. This feature helps prevent duplicate accounts when the target system identifies users by email rather than username. For details, see [SCIM provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/scim/provisioning.md).

**Transformer Expression JSON Values**: Transformer expressions can now insert multiple `<EntityType.Attribute>` values as JSON field values in **Send REST Request** action payloads, supporting richer attribute mapping in provisioning workflows.

**Google Workspace OU Targeting**: When creating Google Workspace users through provisioning workflows, administrators can now select the target **Organizational Unit (OU)** for the new user. Previously, all provisioned users were assigned to the default OU. See [Google Workspace provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/google/provisioning.md).

For more information about provisioning actions, see [Lifecycle Management Actions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md).

***

*Individual releases can include additional bug fixes and performance improvements not detailed in this document. For more information about any features or bug fixes, contact your Veza representative.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/product-updates/blog/2026.4.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
