> 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/features/search/entity-attributes.md). # Veza-assigned entity attributes When Veza discovers an entity through an integration, the entity is represented in the Access Graph with a combination of two categories of metadata: * **Source-system attributes** make up the majority of columns on a typical entity. These are properties ingested from the source system without modification. They vary by integration and reflect the source system's schema. Examples include `mfa_enabled` on an Okta user, `is_encrypted` on an Amazon S3 bucket, and `department` on an HRIS record. * **Veza-assigned attributes** are a smaller, stable set of properties whose column names are defined by Veza. Some carry a source-system value unchanged under a Veza-defined column name; others are computed by Veza during ingestion. These attributes are consistent across integrations and provide the common analytical surface for Search, Query Builder, Reports, Rules, and Access Reviews. This page documents the Veza-assigned set. Source-system attributes that vary by integration are not enumerated here; refer to the documentation for each integration for those. ## How to read the tables The **Set by** column identifies the origin of each attribute's value: * **Source** — supplied by the source system unchanged. Veza defines the column name, and the column appears for any integration that reports the underlying field. * **Veza** — assigned by Veza from a fixed value or normalization rule, with no source input. * **Computed** — derived by Veza from source data, for example risk computation, classification logic, or rule-based pattern matching. * **Hybrid** — varies per integration. Some integrations populate the value from source data while others assign a Veza-controlled value, or Veza normalizes a source-supplied value against a canonical list. The **Scope** column identifies the entity types on which the attribute is populated. *All entities* indicates that the attribute is part of Veza's global property set and appears on every node in the Access Graph. ## Universal identifiers These attributes are present on every entity in the Access Graph. | Attribute | Type | Scope | Set by | Description | | --------------- | ------ | ------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `id` | string | All entities | Veza | The Veza identifier for the entity. Stable across extraction cycles within its datasource. | | `name` | string | All entities | Veza | The display name Veza assigns to the entity, derived from source data. Filters on this attribute are case-insensitive. | | `provider_id` | string | All entities | Veza | The external identifier of the integration instance (one per configured connector). | | `datasource_id` | string | All entities | Veza | The specific data source loaded under the provider during ingestion. A single provider can emit multiple `datasource_id` values; for example, a PostgreSQL server provider produces one server datasource and one datasource per database. | ## Lifecycle timestamps Timestamps are reported by the source system where supported. An integration that does not report a value for a given timestamp will leave that attribute unset on the entity. | Attribute | Type | Scope | Set by | Description | | ----------------- | --------- | ----------------------- | ------ | ---------------------------------------------------------------------------------------- | | `created_at` | timestamp | Most entities | Source | The time at which the entity was created in the source system. | | `updated_at` | timestamp | Most entities | Source | The time at which the entity was last modified in the source system. | | `last_used_at` | timestamp | Identities, credentials | Source | The time at which the entity was last observed in use, as reported by the source system. | | `expires_at` | timestamp | Credentials, sessions | Source | The expiration time of the entity. | | `can_expire` | boolean | Credentials | Source | Indicates whether the entity is subject to an expiration policy. | | `last_rotated_at` | timestamp | Credentials, secrets | Source | The time at which the credential was last rotated. | ## State flags These flags describe identity and resource state. The three identity flags (`is_active`, `is_disabled`, and `is_locked`) describe related but distinct aspects of state and should be evaluated together when auditing deprovisioning controls. | Attribute | Type | Scope | Set by | Description | | ------------------ | ------- | ------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `is_active` | boolean | Identities | Source | Indicates whether the source system considers the identity to be active. Populated for all identity entities. | | `is_disabled` | boolean | Identities | Source | Indicates whether the source system has explicitly disabled the identity. Distinct from inactivity: an identity may be inactive without being disabled (for example, a newly provisioned account that has not yet been used). | | `is_locked` | boolean | Identities | Source | Indicates whether the identity is locked in the source system, typically following authentication failures or policy enforcement. | | `customer_managed` | boolean | Resources, policies | Hybrid | Indicates whether the entity is managed by the customer (`true`) or by the provider (`false`). Derived per integration. For AWS IAM, AWS-owned policies are `false` and customer-created policies are `true`. For Azure RBAC, built-in roles are `false` and custom roles are `true`. For Azure Key Vault, the value reflects whether the key, secret, or vault is customer-managed at the source. Always set at extraction time, with source metadata as the input. | ## Identity attributes These attributes are populated on identity entities. Users, Groups, Roles, Service Accounts, AI Agents, Virtual Machines, and other identity types inherit this set; additional integration-specific identity attributes may also be present. | Attribute | Type | Scope | Set by | Description | | --------------------- | -------------- | ---------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `identity_unique_id` | string | Identities | Source | A source-supplied stable identifier for the identity, such as the source login, email, ARN, or application ID. Uniqueness is established by integration convention rather than enforced by Veza; identity mapping rules use this attribute as a join key across data sources. | | `identity_unique_ids` | list of string | Identities | Source | Additional source-supplied identifiers for sources that publish multiple aliases for one identity. | | `login` | string | Identities | Source | The source-system login or username. | | `email` | string | Identities | Source | The primary email address associated with the identity. | | `emails` | list of string | Identities | Source | Additional email addresses associated with the identity. | | `employee_id` | string | HRIS-linked identities | Source | The employee identifier from the HRIS or directory of record. | | `user_type` | string | Users | Veza | The Veza classification of the user. Values include `human` and `service account`. | | `identity_type` | enum | Identities | Computed | The top-level Veza classification of the identity, with the values `HUMAN` and `NONHUMAN`. See [NHI Supported Entities](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-entities.md) for classification rules. | | `identity_subtypes` | list of enum | NHI identities | Computed | Additional classification of non-human identities, returned as a list. Currently `AI_AGENT` is the only defined subtype. See [NHI Supported Entities](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-entities.md). | | `is_privileged` | boolean | Roles, privileged identities | Computed | A Veza-computed flag indicating that the entity carries elevated administrative permissions within its scope. | | `full_admin` | boolean | Identities | Hybrid | Set on identity nodes (users, groups, roles, service principals) per integration. Indicates administrative access within that integration's scope, not a tenant-global flag. Derivation varies by integration: AWS IAM computes it from policy statements (an `Action=*` and `Resource=*` grant); Snowflake matches the role name to `ACCOUNTADMIN`. Not every integration populates this attribute; check the integration's documentation for coverage. | ## Ownership Veza maintains an entity ownership model that combines owners extracted from the source system with owners assigned by Veza enrichment rules. The ownership attributes below are stored as JSON-serialized strings on the entity and are evaluated together to produce the entity's effective ownership. | Attribute | Type | Scope | Set by | Description | | ------------------ | ------------- | --------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------ | | `owners` | string (JSON) | Identities, resources | Veza | The effective owner set used by Veza for ownership-based workflows. Set by enrichment rules; serialized as a JSON array. | | `enriched_owners` | string (JSON) | Identities, resources | Veza | Owners assigned by Veza enrichment rules. Serialized as a JSON array. | | `extracted_owners` | string (JSON) | Identities, resources | Source | Owners reported by the source system during ingestion. Serialized as a JSON array. | | `removed_owners` | string (JSON) | Identities, resources | Veza | Owners explicitly removed by an enrichment rule. Serialized as a JSON array. | | `merged_owners` | string (JSON) | Identities, resources | Computed | The composite owner set produced by merging `enriched_owners`, `extracted_owners`, and `removed_owners`. Serialized as a JSON array. | ## Risk and criticality Risk and criticality are surfaced as numeric and enum attributes that support filtering, alerting, and review prioritization. The values are computed and assigned within Veza; the inputs and methodology are documented in the dedicated risk references. | Attribute | Type | Scope | Set by | Description | | ------------------- | ------ | ------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `risk_score` | number | Entities with risk | Computed | A numeric risk score computed by Veza from source signal. Higher values indicate greater risk. | | `risk_level` | enum | Entities with risk | Computed | A coarse risk bucket derived from `risk_score`. Values: `NONE`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`. The value `WARNING` is deprecated and is aliased to `LOW`. | | `criticality_level` | enum | Resources | Veza | An administrator-assignable criticality bucket with the values `LOW`, `MEDIUM`, `HIGH`, and `CRITICAL`. Veza sets a default value that an administrator can override. | For details on how `risk_score` is calculated, the available risk types, and how `risk_level` is derived, see: * [Risks](/4yItIzMvkpAvMVFAamTf/features/insights/risks.md) * [Configure Risk Levels and Profiles](/4yItIzMvkpAvMVFAamTf/features/insights/risks/configure-risk-levels-and-profiles.md) * [Investigate Risks](/4yItIzMvkpAvMVFAamTf/features/insights/risks/investigate-risks.md) ## Resource taxonomy Veza assigns each resource or service a categorical type so that Search, reports, and rules can target a class of entity rather than a single integration's resource shape. The mechanism varies by integration: * **Open Authorization API (OAA) integrations** — the OAA push supplies the value, which Veza normalizes against a canonical type list. Values that do not match the canonical list pass through unchanged. * **Veza-managed integrations** — Veza assigns a fixed value per integration (for example, `CLUSTER` or `ORGANIZATION` for CockroachDB Cloud). * **Source-passthrough integrations** — the source system supplies the value directly. | Attribute | Type | Scope | Set by | Description | | ------------------- | ------ | ------------------------ | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `resource_type` | string | Resources | Hybrid | The categorical type of the resource. Veza-managed integrations such as CockroachDB Cloud assign a fixed Veza value (for example, `CLUSTER` or `ORGANIZATION`). OAA pushers supply a value that is canonicalized against the registered resource-type list. Some integrations (for example, SharePoint) pass through a source value directly. | | `application_type` | string | Applications | Hybrid | The categorical type of the application. For OAA, the pusher supplies the value and Veza canonicalizes it against the registered application-type list. For Okta, the value mirrors the OAuth client's `application_type` directly. | | `hris_type` | string | HRIS integrations | Hybrid | Supplied by the OAA pusher for HRIS integrations and canonicalized against the registered HRIS-type list. | | `principal_type` | string | Principal entities | Hybrid | Supplied by the OAA pusher and canonicalized against the registered principal-type list. | | `file_system_type` | string | File system integrations | Hybrid | Supplied by the OAA pusher for file-system integrations and canonicalized against the registered file-system-type list. | | `idp_type` | string | Identity providers | Hybrid | Supplied by the OAA pusher for identity-provider integrations and canonicalized against the registered IDP-type list. | | `secret_store_type` | string | Secret stores | Source | Supplied by the OAA pusher for secret-store integrations. Passed through to the graph unchanged. | | `secret_type` | string | Secrets, credentials | Hybrid | The categorical type of a secret or credential. For AWS KMS, Veza classifies the key as `dynamic` or `static` based on whether automatic rotation is enabled. For Snowflake, the value is supplied by Snowflake. | | `cmdb_type` | string | CMDB integrations | Source | Supplied by the OAA pusher for CMDB integrations. Passed through unchanged. | | `vault_type` | string | Vaults | Source | Supplied by the OAA pusher on secret-store vault nodes. Passed through unchanged. | ## AI classification These attributes are populated on AI Agent, AI Model, AI Tool, and AI Resource entities. They identify the AI platform, the publisher of the entity, and (for models) the model family and series. Veza maintains the canonical platform, publisher, family, and series value sets internally and updates them as new AI products are supported. | Attribute | Type | Scope | Set by | Description | | -------------------- | ------------ | ----------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `ai_platform` | string | AI entities | Hybrid | The platform that hosts or provides the AI entity. For Veza-managed AI integrations, set to a fixed Veza value per integration (examples: `Azure AI Foundry`, `Workday`, `Microsoft Copilot Studio`, `Salesforce`, `ServiceNow`). For OAA-pushed AI agents, the pusher supplies the value. | | `ai_agent_publisher` | string | AI Agents | Hybrid | The publisher of the AI agent. Veza-assigned for Veza-managed integrations (typically the platform vendor); OAA-supplied for OAA-pushed agents. Values are normalized against a canonical publisher list. | | `ai_model_publisher` | string | AI Models | Hybrid | The publisher of the AI model. When the source system reports the publisher, Veza normalizes it against the canonical publisher list (for example, `anthropic` → `Anthropic`). When the source does not supply a publisher, Veza derives it by extracting the model family from the model name and looking up the canonical publisher for that family. | | `ai_model_family` | string | AI Models | Veza | The model family. Veza pattern-matches the source-supplied model name against a curated list. Recognized families include `Claude`, `GPT`, `Llama`, `Nova`, `Titan`, `Gemini`, `PaLM`, `Command`, `Embed`, `Stable`, `Jurassic`, `DeepSeek`, `Qwen`, `Mistral`, `Pixtral`, `Codestral`, `Ministral`, `Phi`, `Gemma`, `Imagen`, `Veo`, `Mars`, `Palmyra`, `Cosmos`, `Cube`, `Rerank`, and `VirtueGuard`. Unrecognized model names yield an empty value. | | `ai_model_series` | string | AI Models | Veza | The model series within a family. Veza substring-matches the model name against a curated pattern table (for example, `Claude Opus`, `GPT-4o`, `Gemini 2.5`, `Llama 3.3`). Unrecognized model names yield an empty value. | | `ai_tool_publisher` | string | AI Tools | Hybrid | The publisher of the AI tool. Veza-assigned for Veza-managed integrations (for example, `Microsoft` for Microsoft Copilot Studio). For the public MCP registry, the value is supplied by the registry. | | `ai_tool_subtypes` | list of enum | AI Tools | Veza | Additional classification of AI tools, returned as a list. Veza tags AI tools that are MCP servers with `MCP_SERVER`. Currently `MCP_SERVER` is the only defined subtype. | For the full list of AI agent, model, tool, and resource entities, see [NHI Supported Entities](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-entities.md) and the AI integration guides. ## Resource hierarchy Veza models hierarchical resources (folders containing files, accounts containing roles, and so on) and computes ancillary attributes that describe each node's position in the hierarchy. | Attribute | Type | Scope | Set by | Description | | ----------------------- | ------- | ---------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `parent_id` | string | Hierarchical resources | Source | The identifier of the parent resource in the source system's hierarchy. | | `hierarchical_level` | number | Hierarchical resources | Computed | The depth of the entity within its hierarchy. | | `hierarchical_in_cycle` | boolean | Hierarchical resources | Computed | Indicates whether the entity participates in a cyclic reference in the source hierarchy. Used by Veza to traverse hierarchies safely when the source data contains cycles. | | `sub_resource_access` | enum | Resources | Computed | Indicates the scope of sub-resource access for the entity. Values: `all`, `partial`. | ## Integration-scoped attributes A small number of Veza-defined columns are populated only on entities from a single integration. They are not part of the universal Veza-assigned set but are listed here for completeness so that administrators encountering them in Search or reports can identify their source. | Attribute | Type | Integration | Set by | Description | | ------------ | ------- | ---------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `versioned` | boolean | Azure Key Vault | Computed | Indicates that the key or secret has more than one version at the source. Veza computes this attribute from the source's version count at extraction time. | | `visibility` | string | GitHub (repositories), Azure AD (groups) | Source | A shared column populated by multiple integrations with different semantics. For GitHub repositories, this is the repository visibility (for example, `public`, `private`, or `internal`) reported by the GitHub API. For Azure AD groups, this is the group visibility reported by Microsoft Graph (for example, `Private`, `Public`, or `HiddenMembership`). The string values are defined by the source API, not by Veza. Search filters on `visibility` may match across both integrations; constrain by entity type to scope the result. | ## Where these attributes appear * **Search and Query Builder** — attribute filters are listed under *Filters → Attributes*, with each attribute displayed in human-readable form (for example, `is_active` appears as **Is Active**). * **Reports** — exported reports include Veza-assigned attributes as columns. Because the column names are consistent across integrations, they are suitable for templated reporting. * **Access Graph** — entity detail panels display the full property set for an entity. * **API** — entity and search endpoints return these attributes under each entity's `properties` object. The exact set of attributes present on a given entity depends on the entity type. A resource does not carry `identity_unique_id`, and an identity does not carry `criticality_level`. Search and Query Builder expose filters only for attributes that exist on the selected entity type. ## Lifecycle Management adds more [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md) computes an additional set of attributes during identity processing — for example, `sys_attr__is_mover` and `sys_attr__is_new_identity`. These attributes are evaluated each extraction cycle and are used as workflow triggers. The LCM-computed attributes are documented separately because they have their own lifecycle (re-evaluated on each extraction) and naming convention (`sys_attr__*` prefix). See [System Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/system-attributes.md) for the full reference. ## NHI classification The `identity_type` and `identity_subtypes` attributes are populated by Veza's NHI classification engine, which combines built-in rules per integration with customer-defined classification rules. See [NHI Supported Entities](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-entities.md) for the full list of integration-specific entity types and the classification logic that drives `identity_type`. ## Related references * [Entities](/4yItIzMvkpAvMVFAamTf/features/search/entities.md) - the broader concept of entities and the Access Graph * [Access Search Glossary](/4yItIzMvkpAvMVFAamTf/glossary/access-search-glossary.md) — definitions for Search-specific terms * [Filters - Attributes](/4yItIzMvkpAvMVFAamTf/features/search/filters.md) — filtering by attributes in Query Builder * [Risks](/4yItIzMvkpAvMVFAamTf/features/insights/risks.md) — risk calculation and `risk_score` derivation * [Configure Risk Levels and Profiles](/4yItIzMvkpAvMVFAamTf/features/insights/risks/configure-risk-levels-and-profiles.md) — how `risk_level` is configured * [System Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/system-attributes.md) — LCM-computed `sys_attr__*` attributes * [NHI Supported Entities](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-entities.md) — classification rules behind `identity_type` and `identity_subtypes` --- # 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/features/search/entity-attributes.md?ask=&goal= ``` `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.