# NHI Supported Entities
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 |
### 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 |
| Identity Provider | AWS IAM | 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 |
| Bot Definition (Agentforce Agents and Einstein Bots) | Salesforce | Bot |
| ServiceNow AI Agent | ServiceNow | 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 |
| 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 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 |
## 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. |
| `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. |
## 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 AgentCore: Runtime
### Azure
* Azure AD: Enterprise Application
* Azure AD: Device
* Azure: Managed Identity
* Azure: Virtual Machine
* Azure AKS: Managed Cluster
* Azure Dynamics ERP: Entra ID Application
* Intune: Managed Device
### CockroachDB Cloud
* CockroachDB Cloud: Service Account
### Google Cloud
* Google Cloud: Service Account
* Google Cloud Compute: Virtual Machine
* Google Cloud Run: Service Instance
* Google Kubernetes Engine: Cluster
### GitHub
* GitHub: Deploy Key
* GitHub: App
### Databricks
* Databricks: Service Principal
* Databricks: Account Service Principal
### ServiceNow
* ServiceNow: AI Agent
### Other Services
* Dynamics 365: Application User
* Kubernetes: Service Account
* Salesforce: Connected Application
### 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
* 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)
* Mongo DB 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." |
| **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`, `ai_agent`, or `ai` (case-insensitive). Any other value (including `employee`, `contractor`, `customer`) results in human classification. 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 assigned a built-in API-only Integrations Profile, including "Salesforce API Only System Integrations" or "Minimum Access - API Only Integrations." See [Salesforce Help: Give Integration Users API Only Access](https://help.salesforce.com/s/articleView?id=platform.integration_user.htm\&type=5) for more details about these identities. |
| **Snowflake User** | Non-human if any of the following conditions are met:
- User is configured to use RSA public key authentication without a password.
- User is a SNOWFLAKE user (a special user that is only used by Snowflake Support).
- User is a WORKSHEETS\_APP\_USER user (the first time Snowsight is accessed in an account, Snowflake creates this internal account to support the web interface).
- User's
Type is one of the following Snowflake non-human account types: SERVICE, LEGACY\_SERVICE, or SNOWFLAKE\_SERVICE.
|
| **Workday Account** | Non-human if the account is an Integration System User or if UI access is disabled. |
### 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: 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:
```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-entities.md?ask=
```
The question should be specific, self-contained, and written in natural language.
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.