DOCS-892: integrate 4.53.0/1.146 updates into existing docs pages

docs/AI Security/akeyless-ai-insight.md

@@ -188,9 +188,13 @@ To test AI Insights in the Akeyless Console, follow these steps:
 2. Navigate to AI Insights.
 3. Start a chat session
 4. Ask a natural language question.
+5. Open the chat list in the left panel to review previous chats.
+6. Use **Search chats** to find a specific chat in your history.
 
 ![Illustration for: 2. Navigate to AI Insights. 3. Start a chat session 4. Ask a natural language question.](https://files.readme.io/9214bc7c65691ab90764917b7da86d69a6be792b3c494b6289b338aabf90f851-chatInteraction.png)
 
+AI Insights stores chat sessions per gateway selection so you can return to prior conversations and search them by title.
+
 ## Troubleshooting
 
 | Issue | Resolution |

docs/AI Security/identity-and-secrets-intelligence.md

@@ -41,7 +41,10 @@ The current Inventory implementation exposes finding details for secret, identit
 
 The current Scanner implementation supports creating scanners, starting scans, stopping active scans, reviewing scan history, and navigating from a running scan directly to **Inventory**.
 
-Current early-access scanner coverage includes GCP Scanner support and AWS Scanner support for cloud identities.
+Current early-access scanner coverage includes:
+
+* **GCP Scanner** support, including enrichment of secret findings with last-access timestamps from Cloud Audit Logs (when those logs are available in the scanned environment) and identity resolution for group-member identities.
+* **AWS Scanner** support for cloud identities, including scanner operation by way of AWS targets that use **Gateway Cloud Identity**.
 
 ## Operational Views
 

docs/Accessing Akeyless/access-and-authentication-methods/auth-with-kubernetes/dedicated-k8s-auth-service-accounts.md

@@ -216,6 +216,17 @@ Where:
 * `token-reviewer-jwt`: The ServiceAccount `JWT` used to access the `TokenReview` API
   (relevant only to `native_k8s` access type).
 
+> ℹ️ **Note (Gateway 4.53.0+):**
+>
+> You can configure TokenReview rate limiting for Gateway Kubernetes authentication by setting Gateway runtime environment variables:
+>
+> * `K8S_TOKEN_REVIEW_QPS`
+> * `K8S_TOKEN_REVIEW_BURST`
+>
+> If these variables are not set, Gateway uses the Kubernetes client-go defaults: `QPS=5` and `Burst=10`.
+>
+> Scope: This setting applies only to `native_k8s` TokenReview flows. Rancher TokenReview flows are not controlled by these variables.
+
 * `k8s-ca-cert`: The certificate to use to validate the Kubernetes cluster.
 
 * `k8s-issuer`: Optional, the [Kubernetes JWT issuer name](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) (default is `kubernetes/serviceaccount`).

docs/Accessing Akeyless/access-and-authentication-methods/index.md

@@ -62,7 +62,7 @@ The following optional features are available across Authentication Methods:
 * **Expiration Date:** Select an access expiration date. This parameter is optional. Leave it empty for access to continue without an expiration date.
 * **Allowed Client IPs:** Enter a comma-separated list of CIDR blocks from which the client can issue calls to the proxy. By "client," we mean cURL, SDKs, and so on. This parameter is optional. Leave it empty for unrestricted access.
 * **Allowed Trusted Gateway IPs:** Comma-separated CIDR blocks. If specified, the Gateway using this IP range will be trusted to forward the original client IP. If empty, the Gateway's IP address will be used.
-* **Audit Log Sub-Claims:** Include the following sub-claims values in Audit Logs.
+* **Audit Log Sub-Claims:** Include selected token sub-claims in Audit Logs (for example, `email`, `username`, or `uid_comment` for UID token flows).
 * **JWT TTL (in minutes):** The time span from authentication to JWT expiration.
 * **Allowed Client Type:** Select the allowed client types that will be authorized to use this authentication method. Multiple options can be selected. For example, `CLI`, `Web UI`, `Extension`, `Mobile`, `Gateway Admin`, or `SDK`.
 * **Delete Protection:** Enable this option to protect the authentication method from accidental deletion.

docs/Accessing Akeyless/rbac/index.md

@@ -114,6 +114,8 @@ The existing permissions for Secure Remote Access are as follows:
 * Upload Files: For RDP only. Allows a user to upload local files to a remote Windows machine using a button on the top menu. More information [here](https://docs.akeyless.io/docs/sra-remote-desktop#download--upload-files).
 * Download Files: For RDP only. Allows a user to download files from a remote Windows machine to their local machine. More information [here](https://docs.akeyless.io/docs/sra-remote-desktop#download--upload-files).
 
+From Gateway `4.53.0` and later, SRA users can request access from the portal and approvers can process the request through the Event Center.
+
 ## Administrative Rules
 
 With Administrative Rules, you can choose whether users have access only to the resources they own (**Own**), access to items users have `list` permission for (**Scoped**), or access to all resources (**All**).
@@ -138,6 +140,17 @@ The following **Administrative Rules** can be set:
 
 * `Usage Reports`
 
+## Reverse RBAC Review Coverage
+
+Reverse RBAC can be used to review who has access to object types beyond Items and Targets, including Secure Remote Access and Agentic Runtime Authority paths.
+
+For command syntax and full parameter details, see the [CLI Reference - Access Roles reverse-rbac command](https://docs.akeyless.io/docs/cli-reference-access-roles#reverse-rbac).
+
+Use the CLI `reverse-rbac` command with:
+
+* `--type sra` for Secure Remote Access rules
+* `--type ara` for Agentic Runtime Authority rules
+
 ## Event Center Rules
 
 You can define which events users are allowed to view based on their account permissions.

docs/Accessing Akeyless/rbac/sub-claims.md

@@ -12,6 +12,8 @@ next:
 ---
 For some of the Auth Methods like JWT/OIDC, Kubernetes, SAML, and LDAP that contain sub-claims or attribute-based access control (ABAC), also known as policy-based access control, as part of the given signed token, you can restrict the authorizations of the associated role to these specific claims or attributes. In other words, only clients whose tokens contain these sub-claims (in the case of JWT/OIDC) or attributes (in the case of SAML) will be allowed to access the rules defined in the role.
 
+For UID tokens, token comments are available as a sub-claim key named `uid_comment`.
+
 The sub-claims definition is in the structure of a map that contains keys that represent the field name of the sub-claims, and each key can contain several values ​​so the sub-claim must contain one of those values. The keys and values are case-sensitive.
 
 For example, assume sub-claims are set to:

docs/Advanced Functionality/account-settings/index.md

@@ -70,7 +70,7 @@ To update the address information on the account, click on the pencil icons, upd
 
 #### Secret Versions
 
-When enabled, this feature allows the user to choose the maximum number of versions of Static Secrets, Rotated Secrets, and Targets to keep in the account for a given item. To update it, click on the pencil icon, choose a number, and click the check mark to save. In addition, you can choose to **force** a new version on update when versions are enabled in the account.
+When enabled, this account-level feature allows the user to choose the maximum number of versions of Static Secrets, Rotated Secrets, and Targets to keep in the account for a given item and review version history from the item details view. To update it, click on the pencil icon, choose a number, and click the check mark to save. In addition, you can choose to **force** a new version on update when versions are enabled in the account.
 
 #### Delete Protection
 

docs/Advanced Functionality/akeyless-agent.md

@@ -1,8 +1,11 @@
 ---
 title: Akeyless Agent
+excerpt: ''
 deprecated: false
 hidden: false
 metadata:
+  title: ''
+  description: ''
   robots: index
 ---
 The Akeyless [CLI](https://docs.akeyless.io/docs/cli#/) lets you set up an Agent that automatically delivers secrets from your Akeyless account and places them in specific locations on your system (**Linux** or **Windows** operating systems are supported).
@@ -18,6 +21,7 @@ The supported items that can be fetched using the Agent are:
 
 * [Static Secrets](https://docs.akeyless.io/docs/static-secrets#/)
 * [Rotated Secrets](https://docs.akeyless.io/docs/rotated-secrets#/)
+* [Dynamic Secrets](https://docs.akeyless.io/docs/dynamic-secrets)
 * [SSH Certificates](https://docs.akeyless.io/docs/sra-ssh-certificates#/)
 * [PKI Certificates](https://docs.akeyless.io/docs/certificate-lifecycle-management#/)
 
@@ -55,6 +59,10 @@ destination = "path_to/static.txt"
 source = "path_to/rotated.tmpl"
 destination = "path_to/rotated.txt"
 
+[[template]]
+source = "path_to/dynamic.tmpl"
+destination = "path_to/dynamic.txt"
+
 [[template]] 
 source = "path_to/ssh_cert.tmpl"
 destination = "path_to/ssh_cert.txt"
@@ -113,6 +121,15 @@ password={{ .Data.Password }}
 {{- end -}}
 ```
 
+### Dynamic Secret
+
+```shell
+{{- with dynamicSecret "/my_dynamic_secret" -}}
+username={{ .Data.user }}
+password={{ .Data.password }}
+{{- end -}}
+```
+
 ### SSH Certificate
 
 ```shell ssh_cert.tmpl

docs/Advanced Functionality/audit-logs/index.md

@@ -27,9 +27,7 @@ Akeyless log auditing is important for cybersecurity because it provides records
 
 When using the console, you can navigate to the **Audit Logs** tab to view logs in the following format:
 
-![](https://files.readme.io/7ec054a7174c4de9426983fab4b975d5eeee76db3c232f68c249ee7beea90113-Screenshot_2026-06-11_at_12.21.37.png)
-
-<br />
+![Audit Logs view in the Akeyless Console.](https://files.readme.io/7ec054a7174c4de9426983fab4b975d5eeee76db3c232f68c249ee7beea90113-Screenshot_2026-06-11_at_12.21.37.png)
 
 These logs show you the time of the described action, what it was, whether it was successful or unsuccessful (status codes in the four hundreds means error), the client performing it, what IP it was performed from, and additional parameter tags such as access type or product type.
 
@@ -40,20 +38,26 @@ You can filter your logs based on any of these rubrics or tags inside the Akeyle
 Another way to view your logs is to forward them in their raw form to tools such as Splunk, Logz.io, and so on.
 The logs will show up as a line of text, from which you can read the following information:
 
-| Log Line             | Description                                                                                                                                                                               |
-| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `Timestamp`          | The log will start with a timestamp string in the format of Date `T` Time Timezone.                                                                                                       |
-| `account_id`         | Account ID.                                                                                                                                                                               |
-| `access_id`          | Access ID.                                                                                                                                                                                |
-| `action`             | The type of action performed, for example, list items, create item, get item, and so on. A list of common log items can be found [here](https://docs.akeyless.io/docs/log-actions)        |
-| `item_type`          | If the action was item specific, like create item, the item type will be listed here.                                                                                                     |
-| `status`             | Standard HTTP status code of the following types, Informational responses (100–199), Successful responses (200–299), Redirection messages (300–399), or Client error responses (400–499). |
-| `remote_addr`        | The IP address from which the action was performed.                                                                                                                                       |
-| `duration`           | The duration of the action in milliseconds.                                                                                                                                               |
-| `request_parameters` | More details about the action, for example, the name and details of a dynamic secret if one was fetched.                                                                                  |
-| `unique_id`          | Identifier for the specific user ID under the account (mostly relevant for human-to-machine auth methods).                                                                                |
-| `access_type`        | [Authentication Method](https://docs.akeyless.io/docs/access-and-authentication-methods) type from which the action was performed.                                                        |
-| `product`            | Which Akeyless product does this log concern. For example,  this could be **Secrets Management**, **Secure Remote Access**, or **Password Management** etc.                               |
+| Log Line | Description |
+| --- | --- |
+| `Timestamp` | The log starts with a timestamp string in Date `T` Time Timezone format. |
+| `seq_num` | Per-account sequence number used to preserve event ordering in audit logs. |
+| `account_id` | Account ID. |
+| `access_id` | Access ID. |
+| `component` | Service component that emitted the audit event (for example, `microservices/uam`). |
+| `action` | Type of action performed, such as list items, create item, or get item. For common actions, see [Log Actions](https://docs.akeyless.io/docs/log-actions). |
+| `item_type` | If the action is item-specific (for example, create item), the item type is listed. |
+| `status` | Standard HTTP status code: informational (`100`-`199`), success (`200`-`299`), redirection (`300`-`399`), client error (`400`-`499`), or server error (`500`-`599`). |
+| `remote_addr` | IP address from which the action was performed. |
+| `duration` | Duration of the action in milliseconds. |
+| `request_parameters` | Additional action details, such as dynamic secret details when a value is fetched. |
+| `scope_params` | Optional scoped-access suffix appended to some logs for exact scope matching (for example, item, role, auth method, target, event forwarder, and client auth scopes). |
+| `unique_id` | Identifier for the specific user under the account (mostly relevant for human-to-machine auth methods). |
+| `client_sub_claims` | Sub-claims captured for the authenticated client when configured on the authentication method (for example, `email`, `username`, and `uid_comment` for UID token flows). |
+| `access_type` | [Authentication Method](https://docs.akeyless.io/docs/access-and-authentication-methods) type used for the action. |
+| `product` | Akeyless product associated with the log, such as **Secrets Management**, **Secure Remote Access**, or **Password Management**. |
+
+To enrich Audit Logs with additional token parameters, configure **Audit Log Sub-Claims** on the relevant authentication method. For UID tokens, `uid_comment` is available as a sub-claim key.
 
 ## Tutorial
 

docs/Akeyless Gateway/configure-gateway/gateway-access-permissions-reference.md

@@ -57,6 +57,8 @@ Console behavior note: in the current custom permission multi-select UI, `admin`
 
 Administrative operations for Gateway allowed access management require `admin` permission.
 
+Gateway visibility in the Console is permission-scoped. Users with Gateway access permissions can view the Gateway in the Console only when their role includes Gateway administrative scope (`scoped` or `all`).
+
 For item-related operations (`targets`, `classic_keys`, `dynamic_secret`, `rotated_secret`, and `rotate_secret_value`), access is evaluated in two scopes:
 
 1. Gateway allowed access permission for the relevant component.

docs/Akeyless Gateway/configure-gateway/gateway-caching/index.md

@@ -37,6 +37,8 @@ Use this starting decision flow:
 
 For planning guidance and tradeoffs, see [Gateway Best Practices: Caching strategy considerations](https://docs.akeyless.io/docs/gateway-best-practices#caching-strategy-considerations).
 
+For proactive deployments, use the recommended implementation (`NEW_PROACTIVE_CACHE_ENABLE=true`) to get shared 429 backoff handling and leadership-cycle worker restart behavior. For details, see [Proactive Caching](https://docs.akeyless.io/docs/proactive-caching).
+
 For Kubernetes proactive cache sizing guidance, see [Gateway Best Practices: Resource planning for Kubernetes proactive cache](https://docs.akeyless.io/docs/gateway-best-practices#resource-planning-for-kubernetes-proactive-cache).
 
 ## Configure in Gateway UI

docs/Akeyless Gateway/configure-gateway/gateway-caching/proactive-caching.md

@@ -48,10 +48,14 @@ All `list-items` and `get-value` calls during warm-up are issued under this iden
 
 429 responses can occur when startup warm-up fan-out exhausts the per-access-ID limit window. The recommended implementation handles this automatically with a shared backoff gate:
 
-* Applies a shared backoff delay across all workers on 429.
+* Applies a shared backoff delay across proactive workers and RBAC refresh calls on 429.
 * Honors `Retry-After` or `will be released in <duration>` headers when available.
 * Retries up to `PROACTIVE_CACHE_WORKERS × 10` attempts before giving up on a cycle.
 
+### Leadership-Loss Handling
+
+In the recommended implementation, proactive workers are tied to the current leadership lease. When leadership is lost, active workers stop gracefully, the current cycle drains, and the next leadership cycle starts with a fresh jobs queue to avoid stale backlog carryover.
+
 To further reduce rate-limit risk:
 
 * Reduce `PROACTIVE_CACHE_WORKERS` to lower burst concurrency.
@@ -115,6 +119,9 @@ For the full key reference, see [Helm Values Reference](https://docs.akeyless.io
 * `CACHE_TTL`: Influences cache time-to-live and full-fetch cadence. Default: `60`.
 * `PROACTIVE_CACHE_DUMP_INTERVAL`: Sets the periodic secure cache backup interval in minutes for the legacy implementation. This variable has no effect when `NEW_PROACTIVE_CACHE_ENABLE=true`. For most tuning decisions on the legacy implementation, prefer `PROACTIVE_CACHE_MINIMUM_FETCHING_TIME`; adjust `PROACTIVE_CACHE_DUMP_INTERVAL` only when you need to change backup cadence specifically.
 
+> ℹ️ **Note:**
+> If Gateway starts without reachable SaaS configuration and initializes cache behavior from environment values, it temporarily enables `NEW_PROACTIVE_CACHE_ENABLE=true` for startup continuity until SaaS configuration becomes reachable.
+
 For Redis topology choices, see [Cluster Cache (Standalone)](https://docs.akeyless.io/docs/cluster-cache-standalone) and [Cluster Cache High Availability (HA)](https://docs.akeyless.io/docs/cluster-cache-ha).
 
 ## Migrating from Legacy Proactive Caching

docs/Akeyless Gateway/configure-gateway/gateway-log-forwarding.md

@@ -247,6 +247,10 @@ input {
 
 5. From the **Log Service** dropdown list, select `Standard Output`.
 
+> ℹ️ **Note:**
+>
+> To emit structured logs to container standard output, set the log format to `JSON`.
+
 ## Sumo Logic
 
 1. Log in to the Akeyless Gateway and go to **Log Forwarding**.

docs/Akeyless Gateway/gateway-best-practices.md

@@ -141,6 +141,7 @@ Caching is optional and should be enabled based on business continuity, performa
 
 * Consider enabling Gateway caching to improve resilience during temporary SaaS connectivity interruptions and to reduce latency for repeated reads.
 * Consider enabling proactive cache when read performance and reduced first-read latency are priorities.
+* For proactive cache, prefer the recommended implementation (`NEW_PROACTIVE_CACHE_ENABLE=true`) to get shared `429` backoff handling and leadership-cycle worker restart behavior.
 * Consider cluster cache when running multiple Gateway instances that should share cache state.
 * Evaluate security and operational tradeoffs before enabling caching:
     * Operational benefits: improved continuity, lower read latency, and reduced repeated upstream calls.