> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsiam/cloud-security/cloud-security-rules-and-policies/create-and-manage-cloud-security-rules/create-an-identity-rule.md).

# Create an identity rule

Identity rules detect security gaps such as over-permissive access or unused permissions by calculating net effective permissions across AWS, Azure, and GCP.

Perform these steps to create a custom identity rule:

1. Navigate to **Posture Management** → **Rules & Policies** → **Rules** → **Cloud Security** .
2. Select **Create Rule** → **Identity**.
3. In the **Overview** step, provide the following:
   1. Enter a **Rule Name and Description.**
   2. Select a **Severity.** Findings generated by this rule will inherit this severity.
   3. (Optional) Add **Labels**.
   4. (Optional) Enable **Remediation** using the toggle. In a later step, you'll enter the remediation instructions.
   5. (Optional) Associate this rule with a **Compliance Control**. Click **Add**, select one or more custom compliance controls from the list, and then click **Assign**. Custom configuration rules can only be associated with custom compliance controls.
   6. Click **Next**.
4. On the Rule Logic page, you can select options to build your rule. See more information below.
5. Once your logic is defined, click **Search** to view real-time results from your environment
6. Click **Next** to define Remediation instructions (if you had turned on **Enable Remediation** in the Overview step) or click **Done**.
7. (Optional) In the text field, define remediation actions or provide other information that will be included on issues created by this rule.
8. Click **Done** to save your rule.

### **Define identity rule logic**

When building identity rule logic, you define the criteria based on the five pillars of a permission. You choose an asset and apply filters to its attributes and its relationships to other assets. The five pillars are:

1. **Permission Source:** The human or non-human identity (such as a VM or function) that performs the action.
2. **Permission Destination:** The specific cloud resource or wildcard pattern being acted upon.
3. **Policy:** The IAM document, role, or resource-based policy that grants the rights.
4. **Granter:** The entity connecting the source to the policy, such as an IAM group or the source itself in the case of inline policies.
5. **Permission:** The actual action granted, including attributes like the **last used time** and **access level** (e.g., Administrative, Write, or Config).

To construct rule logic:

1. **Select the primary asset (pillar):** You begin by choosing one of the pillars to be the focus of the rule. The system will generate issues *only* for the first entity type you select (the Source, Granter, or Destination).

   For example, if you want to flag risky *users*, start by selecting the **Source** entity.
2. **Apply attribute filters:** Once an asset is selected, you add logical conditions based on its attributes.

   For example, you can filter for a **Source** where Cloud Type = AWS and Identity Type = IAM User.
3. **Define relationships:** You then connect this asset to other pillars to describe the risky permission path.

   For example, You can define a relationship where the **Source** (User) *has permission* to access a specific **Destination** (e.g., Production DB) via a specific **Permission** (e.g., Delete).
4. **Validate with search:** After constructing the logic, click **Search** within the rule builder. This runs the query against your current environment to show real-time results, allowing you to verify that the logic correctly identifies the intended assets before you save the rule.

### **Example rule logic structure:**

A common custom rule might look for an **AWS IAM User** (Source) who has **Administrative** access (Permission) but has **MFA Disabled** (Source Attribute). The logic would be constructed by:

1\. Selecting **Source** (IAM User).

2\. Filtering for MFA Enabled = False.

3\. Connecting to **Permission** where Access Level = Administrative.


---

# 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://cortex-docs.paloaltonetworks.com/cortex-xsiam/cloud-security/cloud-security-rules-and-policies/create-and-manage-cloud-security-rules/create-an-identity-rule.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.