> 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/nhi/nhi-entities.md). # NHI Supported Entities Reference for all supported non-human identity entity types and NHI classification logic across integrated systems. Veza automatically detects non-human identities (NHIs) across your environment and assigns each entity an *Identity Type*. This page lists all supported NHI entity types organized by integration and by functional category, and describes the built-in and user-defined rules Veza uses for NHI classification. See [Entities by Type](#entities-by-type) for a summary organized by functional category, or [Entity Reference by Integration](#entity-reference-by-integration) for the complete list per platform. ## Entities by Type NHI entities are organized into five categories based on their functional role and security characteristics. ### Infrastructure & Compute Compute resources including virtual machines, serverless functions, and container orchestration clusters. These entities typically assume IAM roles or service accounts to access cloud resources. | Veza Entity | Integration | Category | | -------------------------------- | ------------ | ------------------- | | EC2 Instance | AWS | Virtual Machine | | Virtual Machine | Azure | Virtual Machine | | Compute Virtual Machine | Google Cloud | Virtual Machine | | Lambda Function | AWS | Serverless Function | | Cloud Run Service Instance | Google Cloud | Serverless Function | | EKS Cluster | AWS | Container & Cluster | | EMR Cluster | AWS | Container & Cluster | | AKS Managed Cluster | Azure | Container & Cluster | | Google Kubernetes Engine Cluster | Google Cloud | Container & Cluster | ### Identities & Service Accounts Non-human principals used by applications, automation, and systems to authenticate and access resources. | Veza Entity | Integration | Category | | ---------------------------- | ------------------ | ---------------- | | Managed Service Account | Active Directory | Service Account | | Computer | Active Directory | Service Account | | Service Principal | AWS | Service Account | | Service Account | CockroachDB Cloud | Service Account | | Service Account | Confluent | Service Account | | Service Account | Delinea | Service Account | | Service Account | Egnyte | Service Account | | Service Account | GitLab | Service Account | | Service Account | Google Cloud | Service Account | | Service Account | Kubernetes | Service Account | | Service Account | Palo Alto Networks | Service Account | | Service Principal | Databricks | Service Account | | Account Service Principal | Databricks | Service Account | | Service Account | Slack | Service Account | | Service Account | Terraform | Service Account | | Service Account | Wiz | Service Account | | Managed Identity | Azure | Managed Identity | | AI Foundry Bot Service Agent | Azure | Service Account | | Service Account | OpenAI | Service Account | | Service Key | LangSmith | Service Account | ### SaaS & Integrations App registrations, enterprise application identities, devices, and deploy keys used to grant programmatic access to services and systems. | Veza Entity | Integration | Category | | --------------------------- | ------------------- | ---------------- | | Enterprise Application | Azure AD | App Registration | | Entra ID Application | Azure Dynamics ERP | App Registration | | Application User | Dynamics 365 | App Registration | | Connected Application | Salesforce | App Registration | | External Client Application | Salesforce | App Registration | | Identity Provider | AWS IAM | App Registration | | Developer App | Google Cloud Apigee | App Registration | | Device | Azure AD | Device | | Managed Device | Intune | Device | | Deploy Key | GitHub | Deploy Key & App | | App | GitHub | Deploy Key & App | ### AI Agents & Bots AI agents, reasoning engines, and bots that take autonomous actions, invoke models, and access resources through execution identities. | Veza Entity | Integration | Category | | ---------------------------------------------------- | ------------ | -------- | | Bedrock Agent | AWS | AI Agent | | Bedrock AgentCore Runtime | AWS | AI Agent | | Vertex AI Reasoning Engine | Google Cloud | AI Agent | | AI Foundry Agent | Azure | AI Agent | | Copilot Studio Bot | Microsoft | Bot | | M365 Declarative Agent | Microsoft | AI Agent | | Bot Definition (Agentforce Agents and Einstein Bots) | Salesforce | Bot | | ServiceNow AI Agent | ServiceNow | AI Agent | | ServiceNow External A2A Agent | ServiceNow | AI Agent | | Snowflake Cortex Agent | Snowflake | AI Agent | | Workday AI Agent | Workday | AI Agent | | Anthropic Claude Agent | Anthropic | AI Agent | | LangSmith Assistant | LangSmith | AI Agent | | LangSmith Fleet Agent | LangSmith | AI Agent | ### Secrets & Credentials Stored secrets, cryptographic keys, and long-lived access credentials. See [NHI Secrets](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-secrets.md) for discovery and lifecycle management details. | Veza Entity | Integration | Category | | -------------------------------- | ---------------------- | ------------------------- | | Secrets Manager Secret | AWS | Secret | | Systems Manager Parameter | AWS | Secret | | Key Vault Secret | Azure | Secret | | Secret | GitHub | Secret | | Secret Manager Secret | Google Cloud | Secret | | Secrets Engine Resource | HashiCorp Vault | Secret | | Secret | Kubernetes | Secret | | Secret | Snowflake | Secret | | KMS Customer Master Key | AWS | Cryptographic Key | | Key Vault Key | Azure | Cryptographic Key | | KMS Key | Google Cloud | Cryptographic Key | | Auth Server Key | Okta | Cryptographic Key | | Certificate Manager Certificate | AWS | Access Token & Credential | | IAM Access Key | AWS | Access Token & Credential | | App Credential | Azure AD | Access Token & Credential | | Key Vault Certificate | Azure | Access Token & Credential | | Storage Account Access Key | Azure | Access Token & Credential | | API Key | CockroachDB Cloud | Access Token & Credential | | API Key | Anthropic | Access Token & Credential | | Account Service Principal Secret | Databricks | Access Token & Credential | | Personal Access Token | Databricks | Access Token & Credential | | Deploy Key | GitHub | Access Token & Credential | | Personal Access Token | GitHub | Access Token & Credential | | Access Credential | GitLab | Access Token & Credential | | Service Account Key | Google Cloud | Access Token & Credential | | API Key | Google Cloud Apigee | Access Token & Credential | | Service Key | LangSmith | Access Token & Credential | | Personal Access Token | LangSmith | Access Token & Credential | | SCIM Token | LangSmith | Access Token & Credential | | API Token | Okta | Access Token & Credential | | Application Key Credential | Okta | Access Token & Credential | | OAuth Application Client Secret | Okta | Access Token & Credential | | OAuth Refresh Token | Okta | Access Token & Credential | | Custom Access Credential | Open Authorization API | Access Token & Credential | | Salesforce Auth Provider | Salesforce | Access Token & Credential | | Salesforce Certificate | Salesforce | Access Token & Credential | | Salesforce Named Credential | Salesforce | Access Token & Credential | | Salesforce External Credential | Salesforce | Access Token & Credential | | Salesforce OAuth Token | Salesforce | Access Token & Credential | | Salesforce Tenant Secret | Salesforce | Secret | ## Non-Human Identities These entities are always assigned the "non-human" identity type. Some are dedicated non-human entity types (such as service principals, managed identities, and bots). Others are user entities that Veza automatically classifies as non-human based on properties from the source system (such as account type flags or API-only access). ### AI Agents Veza discovers AI agent entities across multiple cloud platforms and classifies them as non-human identities by default. For full entity details, properties, and access relationship models, see [AI Agent Security — Supported Entities](/4yItIzMvkpAvMVFAamTf/features/ai-agent-security/supported-entities.md). | Entity Type | Classification | Description | | ---------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `BedrockAgent` | AI Agent | Orchestration engine in AWS Bedrock; assumes an IAM Role for resource access. | | `BedrockAgentCoreRuntime` | AI Agent | Running agent instance on the AWS Bedrock AgentCore platform; assumes an IAM Role for resource access. | | `AzureAiFoundryAgent` | AI Agent | AI agent or assistant created in Azure AI Foundry; backed by a model deployment. Linked to the Microsoft Entra agent identity that holds the agent's effective permissions in Azure. | | `VertexAiReasoningEngine` | AI Agent | Stateful orchestration engine in Google Cloud Vertex AI; runs as a Google Cloud service account. | | `MicrosoftCopilotStudioBot` | AI Agent | AI-powered conversational agent stored in Dataverse as a bot entity. | | `SalesforceBotDefinition` | AI Agent | AI agent or bot defined in Salesforce (Agentforce / Einstein Bot). | | `ServiceNowAIAgent` | AI Agent | AI agent from the ServiceNow Now Assist platform. Requires the AI Agent Studio (`sn_aia`) plugin. | | `ServiceNowExternalAgent` | AI Agent | Third-party agent registered through ServiceNow's AI Agent Fabric over the Agent2Agent (A2A) protocol. Requires the Now Assist AI Agents store app 6.0.x or later with `sn_aia.external_agents.enabled` set to `true`. | | `SnowflakeCortexAgent` | AI Agent | A Cortex Agent in a Snowflake schema. Runs with the role of the user who invokes it. | | `WorkdayAIAgent` | AI Agent | AI agent registered in Workday's Agent System of Record (ASOR). Linked to an Agent System User account that holds the agent's effective permissions in Workday. | | `AnthropicClaudeManagedAgentAgent` | AI Agent | A managed agent in an Anthropic Claude workspace. Acts as its own non-human principal; uses a Claude model and can call tools, MCP servers, and skills. | | `LangSmithAssistant` | AI Agent | An assistant served by a LangGraph deployment in a LangSmith workspace. Acts as its own non-human principal. | | `LangSmithFleetAgent` | AI Agent | An agent built in LangSmith Fleet. Acts as its own non-human principal; uses a model and can call tools from MCP servers. | ## Entity Reference by Integration The following sections list all entity types that Veza always classifies as non-human, organized by integration. ### Active Directory * Active Directory: Computer * Active Directory: Managed Service Account ### AWS * AWS EMR: Cluster * AWS: Service Principal * AWS IAM: Identity Provider * AWS EC2: Instance * AWS Lambda: Function * AWS EKS: Cluster * AWS Bedrock: Agent * AWS Bedrock AgentCore: Runtime * AWS Bedrock AgentCore: Gateway * AWS Bedrock AgentCore: Code Interpreter * AWS Bedrock AgentCore: Browser * AWS Bedrock AgentCore: Online Evaluation Config ### Azure * Azure AD: Enterprise Application * Azure AD: Device * Azure: Managed Identity * Azure: Virtual Machine * Azure AKS: Managed Cluster * Azure Dynamics ERP: Entra ID Application * Azure AI Foundry: Agent * Azure AI Foundry: Bot Service Agent * Intune: Managed Device ### Anthropic * Anthropic Claude: AI Agent * Anthropic Claude: API Key ### OpenAI * OpenAI: Service Account ### LangSmith * LangSmith: Service Key * LangSmith: Assistant * LangSmith: Fleet Agent ### CockroachDB Cloud * CockroachDB Cloud: Service Account ### Google Cloud * Google Cloud: Service Account * Google Cloud Compute: Virtual Machine * Google Cloud Run: Service Instance * Google Cloud Vertex AI: Reasoning Engine * Google Kubernetes Engine: Cluster * Google Cloud Apigee: Developer App ### GitHub * GitHub: Deploy Key * GitHub: App ### Databricks * Databricks: Service Principal * Databricks: Account Service Principal ### Microsoft Copilot Studio * Microsoft Copilot Studio: Bot ### ServiceNow * ServiceNow: AI Agent, External A2A Agent ### Snowflake * Snowflake: Cortex Agent ### Workday * Workday: AI Agent ### Salesforce * Salesforce: Auth Provider * Salesforce: Bot Definition (Agentforce Agents and Einstein Bots) * Salesforce: Certificate * Salesforce: Connected Application * Salesforce: External Client Application * Salesforce: External Credential * Salesforce: Named Credential * Salesforce: OAuth Token * Salesforce: Tenant Secret Veza also connects Salesforce Named Credentials and External Credentials to the Salesforce users who can authenticate through them. For details on enabling NHI credential discovery, required permissions, and these relationships, see [Salesforce Keys and Secrets (NHI Credentials)](/4yItIzMvkpAvMVFAamTf/integrations/integrations/salesforce.md#salesforce-keys-and-secrets-nhi-credentials). For External Client Apps and OAuth tokens, see [Salesforce OAuth Tokens and External Client Apps](/4yItIzMvkpAvMVFAamTf/integrations/integrations/salesforce.md#salesforce-oauth-tokens-and-external-client-apps). {% hint style="info" %} **Available starting with Veza v2026.10.19.** Earlier releases do not discover Salesforce External Client Apps or OAuth tokens. {% endhint %} ### Other Services * Dynamics 365: Application User * Kubernetes: Service Account ### Auto-Classified Service Accounts For the following integrations, Veza automatically classifies certain user accounts as non-human based on account type flags from the source system (such as bot status, service account flags, or application account indicators): * Confluent: Service Account * Delinea: Service Account (application accounts) * Egnyte: Service Account * GitLab: Service Account (dedicated service account users and bots) * Palo Alto Networks: Service Account * Slack: Service Account (bot users and app users) * Terraform: Service Account * Wiz: Service Account ## Entities That Can Be Human or Non-Human The following entities can be marked "human" or "non-human" depending on Veza rules for identifying NHIs: * Active Directory: User (Built-in Rule) * AWS ElasticSearch: User * AWS: IAM User (Built-in Rule) * AWS RDS MySQL: User * AWS RDS MySQL: User Instance * AWS RDS Postgres: User * AWS Redshift: User * CyberArk: User (Built-in Rule) * GitHub: Personal Account * Google Cloud SQL: User (Built-in Rule) * Hashicorp Vault: Alias (Built-in Rule) * Hashicorp Vault: Entity (Built-in Rule) * Microsoft Dynamics 365: User (Built-in Rule) * MongoDB Atlas Database User * Mongo DB User * Okta App User (Built-in Rule) * Okta User (Built-in Rule) * Open Authorization API: Custom IDP User * Open Authorization API: Custom Principal User * Open Authorization API: Custom User * PostgreSQL User * Privacera: Portal User (Built-in Rule) * Salesforce User (Built-in Rule) * ServiceNow User (Built-in Rule) * Snowflake User (Built-in Rule) * SQL Server Database User * Trino User * Workday Account (Built-in Rule) Veza has internal rules to assign some of these identity types as non-human. See the following section for rule details. For some integrations, there is no consistent method to automatically detect non-human identities. In Veza, these are shown as "human" by default. This behavior can be changed to label certain identities based on tags, naming patterns, groups, or other conventions employed by your organization. ## Determining Human vs. Non-Human Identities Veza uses the following rules to distinguish between human and non-human accounts in supported integrations: | **Integration Type** | **Non-Human Identity (NHI) Rule** | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **AWS IAM User** | Considered non-human if *ConsoleAccess* is nil/false and *MfaActive* is false. | | **Active Directory User** | Non-human if *User Principal Name (UPN)* is absent. | | **Dynamics 365 User** | Non-human if the user is marked as non-interactive. | | **Google Cloud SQL User** | Identified as non-human if *UserType* is UserTypeCloudIAMServiceAccount, UserTypeCloudIAMGroup, or UserTypeCloudIAMGroupServiceAccount. | | **HashiCorp Vault Alias** | Identified as non-human if the Alias's *UserType* is "service account." | | **HashiCorp Vault Entity** | Identified as non-human if the Entity's *UserType* is "service account." Veza derives an Entity's *UserType* from its Aliases: when every Alias resolves to the same value, the Entity takes that value; when the Aliases disagree, the Entity has no *UserType* and is classified as human. | | **ServiceNow User** | When ServiceNow's `identity_type` field has a value, the user is non-human only if the value is `service_account`, `integration`, `non_human`, `nonhuman`, `machine`, `ai`, `ai_agent`, or `ai agent`. Matching ignores case and surrounding whitespace. Any other value (including `employee`, `contractor`, `customer`) results in human classification. A user matched on one of the three AI values also receives the `AI_AGENT` identity subtype. When `identity_type` is empty or `unclassified`, non-human classification applies when the user is flagged as an internal integration user or email is missing. | | **Okta User** | Non-human if all conditions are met: *UserType*, *Manager*, and *DisplayName* are empty; *MFA* is false; *LastLogin* is nil. | | **Okta App User** | Inherits the identity type from the corresponding Okta User account. When an associated Okta User exists, the App User automatically adopts the same identity type classification (human or non-human). For App Users without corresponding Okta User accounts, the system defaults to marking them as human identities. | | **Privacera Portal User** | Non-human by default. Classified as human if any assigned role name contains "ADMIN", "USER", "AUDITOR", or "APPROVER" (case-sensitive substring match). | | **Salesforce User** |

Non-human if any of the following conditions are met:

The api\_only and user\_license properties on the user's Salesforce Profile show whether the first two conditions apply. A user on a standard profile, such as "Minimum Access - Salesforce", is classified as human unless another condition above applies, even if it is used only for integrations.

Available starting with Veza v2026.10.19. Earlier releases classify only users assigned one of the two API-only profiles.

See Salesforce Help: Give Integration Users API Only Access.

| | **Snowflake User** |

Non-human if any of the following conditions are met:

| | **Workday Account** | Non-human if the account is an Integration System User, an Agent System User (which is also flagged as an AI agent), or if UI access is disabled. | | **CyberArk User** | Non-human if the user is flagged as a service user (`ServiceUser` is `true`). | ### Non-Human Identity (NHI) Enrichment Rules Veza provides **Non-Human Identity (NHI) Enrichment Rules** to automate NHI labeling based on specific conditions. For example, you might assign users as non-human when their email contains "service-account-%", "svc-%", or is missing. Administrators can add rules on the **Integrations** > **Enrichment** page: 1. **Save a Query**: In Query Builder, save a query that identifies the entities to mark as non-human. For example, you could query for SAP ECC Users where the *Email* or *Name* contains the text "system-". 2. **Enable Enrichment Rules**: Configure the saved query as an enrichment rule. When extracting metadata, Veza will update the *Identity Type* attribute for any entities that match the query conditions. Enrichment Rules will take precedence over any default identity type for specific users. To learn more, see the [Enrichment Rules](/4yItIzMvkpAvMVFAamTf/integrations/configuration/enrichment.md) documentation. ### NHI Owner Enrichment Rules After identifying non-human identities, you can assign ownership and accountability using **NHI Owner enrichment rules**. These rules assign owners from your integrated Identity Provider (IdP) or HRIS to NHIs, establishing clear responsibility for service accounts and machine identities. Enriched owners combine with owners assigned via other methods to create a merged list of owners shown throughout Veza. For configuration steps and examples, see the [Entity Owner Enrichment Rules](/4yItIzMvkpAvMVFAamTf/integrations/configuration/enrichment.md#entity-owner-enrichment-rules) section. For more on how owners are used in Access Reviews, see [Managers and Resource Owners](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/managers-and-resource-owners.md). --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-entities.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.