add proper docs

docs/documentation/platform/access-controls/abac/managing-machine-identity-attributes.mdx

@@ -0,0 +1,68 @@
+---
+title: "Machine identities"  
+description: "Learn how to set metadata and leverage authentication attributes for machine identities."
+---
+
+Machine identities can have metadata set manually, just like users. In addition, during the machine authentication process (e.g., via OIDC), extra attributes called claims—are provided, which can be used in your ABAC policies.
+
+#### Setting Metadata on Machine Identities
+
+<Tabs>
+  <Tab title="Manually Configure Metadata">
+    <Steps>
+      <Step title="Navigate to the Access Control page on the organization sidebar and select a machine identity.">
+        <img src="/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-1.png" />
+      </Step>
+      <Step title="On the machine identity page, click the pencil icon to edit the selected identity.">
+        <img src="/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-2.png" />
+      </Step>
+      <Step title="Add metadata via key-value pairs and update the machine identity.">
+        <img src="/documentation/platform/access-controls/abac/images/add-metadata-on-machine-identity-3.png" />
+      </Step>
+    </Steps>
+  </Tab>
+</Tabs>
+
+#### Accessing Attributes From Machine Identity Login
+
+When machine identities authenticate, they may receive additional payloads/attributes from the service provider. 
+For methods like OIDC, these come as claims in the token and can be made available in your policies.
+
+<Tabs>
+  <Tab title="OIDC Login Attributes">
+    1. Navigate to the Identity Authentication settings and select the OIDC Auth Method.  
+    2. In the **Advanced section**, locate the Claim Mapping configuration.  
+    3. Map the OIDC claims to permission attributes by specifying:  
+       - **Attribute Name:** The identifier to be used in your policies (e.g., department).  
+       - **Claim Path:** The dot notation path to the claim in the OIDC token (e.g., user.department).
+
+    For example, if your OIDC provider returns:
+
+    ```json
+    {
+      "sub": "machine456",
+      "name": "Service A",
+      "user": {
+        "department": "engineering",
+        "role": "service"
+      }
+    }
+    ```
+
+    You might map:
+    
+    - **department:** to `user.department`  
+    - **role:** to `user.role`
+
+    Once configured, these attributes become available in your policies using the following format:
+    
+    ```
+    {{ identity.auth.oidc.claims.<permission claim name> }}
+    ```
+
+    <img src="/images/platform/access-controls/abac-policy-oidc-format.png" />
+  </Tab>
+  <Tab title="Other Authentication Method Attributes">
+    At the moment we only support OIDC claims. Payloads on other authentication methods are not yet accessible.
+  </Tab>
+</Tabs>

docs/documentation/platform/access-controls/abac/managing-user-metadata.mdx

@@ -0,0 +1,39 @@
+---
+title: "Users identities"  
+description: "How to set and use metadata attributes on user identities for ABAC."
+---
+
+User identities can have metadata attributes assigned directly. These attributes (such as location or department) are used to define dynamic access policies.
+
+#### Setting Metadata on Users
+
+<Tabs>
+  <Tab title="Manually Configure Metadata">
+    <Steps>
+      <Step title="Navigate to the Access Control page on the organization sidebar and select a user.">
+        <img src="/images/platform/access-controls/add-metadata-step1.png" />
+      </Step>
+      <Step title="On the User Page, click the pencil icon to edit the selected user.">
+        <img src="/images/platform/access-controls/add-metadata-step2.png" />
+      </Step>
+      <Step title="Add metadata via key-value pairs and update the user identity.">
+        <img src="/images/platform/access-controls/add-metadata-step3.png" />
+      </Step>
+    </Steps>
+  </Tab>
+  <Tab title="Automatically Populate Metadata">
+    For organizations using SAML for **user logins**, Infisical automatically maps metadata attributes from SAML assertions to user identities on every login. This enables dynamic policies based on the user's SAML attributes.
+  </Tab>
+</Tabs>
+
+#### Applying ABAC Policies with User Metadata
+Attribute-based access controls are currently only available for polices defined on Secrets Manager projects. 
+You can set ABAC permissions to dynamically set access to environments, folders, secrets, and secret tags.
+
+<img src="/images/platform/access-controls/example-abac-1.png" />
+
+In your policies, metadata values are accessed as follows:
+
+- **User ID:** `{{ identity.id }}` (always available)
+- **Username:** `{{ identity.username }}` (always available)
+- **Metadata Attributes:** `{{ identity.metadata.<metadata-key-name> }}` (available if set)

docs/documentation/platform/access-controls/abac/overview.mdx

@@ -0,0 +1,15 @@
+---
+title: "Overview"  
+description: "Learn the basics of ABAC for both users and machine identities."
+---
+
+Infisical's Attribute-based Access Controls (ABAC) enable dynamic, attribute-driven permissions for both users and machine identities. ABAC enforces fine-grained, context-aware access controls using metadata attributes—stored as key-value pairs—either attached to identities or provided during authentication.
+
+<CardGroup cols={2}>
+  <Card title="Users" icon="square-1" href="./managing-user-metadata">
+    Manage user metadata manually or automatically via SAML logins.  
+  </Card>
+  <Card title="Machine Identities" icon="square-2" href="./managing-machine-identity-attributes">
+   Set metadata manually like users and access additional attributes provided during machine authentication (for example, OIDC claims).
+  </Card>
+</CardGroup>