--- title: "Working with Multi-Identity Policy Evaluation" slug: "working-with-multi-identity-policy-evaluation" updated: 2026-03-22T16:23:44Z published: 2026-03-22T16:23:44Z --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.plainid.io/llms.txt > Use this file to discover all available pages before exploring further. # Working with Multi-Identity Policy Evaluation In some authorization scenarios, an access decision must reflect the combined context of multiple **Identities** rather than a single principal. This commonly occurs when a human user operates through an agent, such as in Agentic AI use cases, or when both human and non-human entities must jointly satisfy authorization requirements. **Multi-Identity Policy Evaluation** enables the **Policy Decision Point (PDP)** to compute a single authorization decision using multiple **Identities** of different types. In this model, the **PDP** evaluates the authorization decision using all relevant Identity-based logic within one unified decision flow, rather than evaluating a **Policy** for a single Identity type and omitting rules that apply to other Identity types. The final outcome reflects the full combined authorization context. Access is granted only when all Identity-related **Policy** requirements are satisfied for all evaluated **Identities**. ## Evaluation Model A request may include up to three **Identities**. Each **Identity** must originate from a different **Identity Template**. If more than three **Identities** are provided, the **PDP** rejects the request with an error. When Multi-Identity Evaluation is enabled, the **PDP** matches all relevant **Identity Templates** included in the request and evaluates them together as part of a single **Policy** calculation. Although **Identities** are processed sequentially, the evaluation order does not affect the semantics of the decision. The logical relationship between **Identities** is strictly enforced using **AND** semantics. Each **Identity** must independently satisfy all **Policy** components that apply to its **Identity Template**. If any **Identity** fails its evaluation, the overall authorization decision is denied. A request may include a primary Identity and additional Identities, or it may include only additional Identities. There is no hierarchy in evaluation between the **Identities**. If Multi-Identity Evaluation is disabled, only the primary **Identity** is evaluated to preserve backward compatibility. If a request does not include a primary **Identity** in this mode, the **PDP** returns an error. ## Dynamic Groups, Conditions, and Rulesets **Dynamic Groups** are evaluated per **Identity Template** and participate in the same unified decision. Their behavior depends on which **Identities** are included in the request. - If only one **Identity** type is provided, only the **Dynamic Groups** associated with that **Identity Template** are evaluated. - If multiple **Identity** types are included, the **Dynamic Groups** for each **Identity Template** must pass. The relationship between the Identity logic is enforced using **AND** semantics. For example, if a **Policy** contains one **Dynamic Group** for a Human **Identity** and another for an Agent **Identity**, and both **Identities** are present in the request, both **Dynamic Groups** must evaluate successfully. Failure of either results in denial. There is no override or substitution between **Identity** types. **Conditions** behave consistently with the standard evaluation model but operate within a shared multi-Identity context. When a **Condition** references **Identity Attributes**, those attributes are resolved against the corresponding **Identity Template** in the request. If multiple **Identities** are present, all Identity-related **Conditions** must evaluate to true. When using **Identity Attribute** logic, **Rulesets** are evaluated using the referenced **Attribute's Identity Template**. If multiple **Rulesets** reference different **Identity Templates**, all rules must evaluate successfully. ## Scope Configuration Multi-Identity Policy Evaluation is controlled at the **Scope** level through the **Use Multiple Identities Combination** setting. See [Managing Scopes](/v1/docs/managing-scopes) to learn more about enabling this setting. By default, this setting is disabled to preserve backward compatibility. In this mode, Identity logic components such as **Dynamic Groups**, **Conditions**, and **Rulesets** are evaluated using the existing single-Identity behavior. When enabled, Identity logic components from multiple **Identity Templates** within the same **Policy** are evaluated together as part of one authorization decision. ## Request and Response Behavior Multiple **Identities** can be included in a request using the existing `entityTypeId` and `entityId` request parameters. These parameters can represent the primary **Identity**, additional **Identities**, or all **Identities**, depending on the request structure. **Identity Attributes** can be provided for the primary **Identity** as well as for additional **Identities**. Alternatively, multiple JWTs can be included in the request by using multiple identity mappers, each associated with a different **Identity Template**. When the `includeIdentity` flag is used in the request, the response structure reflects the number of evaluated **Identities**: - If a single **Identity** is evaluated, **Identity Attributes** are returned as a single object to maintain backward compatibility. - If multiple **Identities** are evaluated, **Identity Attributes** are returned as a list, with each entry corresponding to one **Identity Template**. --- Multi-Identity Policy Evaluation enables **Policies** to enforce authorization requirements across multiple **Identity** types within a single, unified decision. This supports advanced scenarios such as human-plus-agent authorization while maintaining strict and predictable **Policy** semantics.