diff --git a/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md
index b46bdc576..e0c47b710 100644
--- a/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md
+++ b/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md
@@ -96,6 +96,30 @@ The mitigation planning should be done in two layers:
     as developer and B2B APIs). They tend to be an easy target for attackers
     because they often don't implement all the required protection mechanisms.
 
+### Asynchronous Agent Mutation & Business Flow Drift
+
+In agent-driven and workflow-automation architectures, background agents may mutate sensitive business objects after initial authorization checks. This creates a new class of business-flow abuse where state changes occur outside the original security context.
+
+#### Example Abuse Scenario
+
+1. A user submits a legitimate request to update a non-sensitive field.
+2. An autonomous background agent enriches or modifies the object asynchronously.
+3. The agent applies restricted fields such as approval flags, role attributes, or workflow states.
+4. The system commits unauthorized business-state transitions without any further user interaction.
+
+#### Why This Happens
+
+- Authorization is enforced only at the synchronous API layer.
+- Agents reuse service tokens with broader privileges.
+- Business-flow validation is bypassed in background job processing.
+
+#### Mitigations
+
+- Enforce authorization on every write boundary, including background jobs and message queues.
+- Prevent agents from reusing user authorization contexts.
+- Implement strict server-side field allow-lists for all asynchronous mutations.
+- Log and alert on cross-workflow state transitions initiated by agents.
+
 ## References
 
 ### OWASP
diff --git a/editions/2023/en/0xa7-server-side-request-forgery.md b/editions/2023/en/0xa7-server-side-request-forgery.md
index a0482f75a..577fdd20f 100644
--- a/editions/2023/en/0xa7-server-side-request-forgery.md
+++ b/editions/2023/en/0xa7-server-side-request-forgery.md
@@ -142,6 +142,28 @@ can view the credentials of the cloud environment.
 * Validate and sanitize all client-supplied input data.
 * Do not send raw responses to clients.
 
+### Agent-Driven Replay & Rebinding SSRF Risk
+
+Modern agentic systems often store or replay previously validated URLs across tasks. This creates a new SSRF risk class where:
+
+- A URL is validated once, then reused later when DNS records or routing context have changed.
+- Autonomous agents fetch resources based on historical state rather than real-time authorization context.
+- Trusted internal callbacks are rebound to attacker-controlled infrastructure after task completion.
+
+#### Example Abuse Scenario
+
+1. An agent validates a webhook URL during onboarding.
+2. The domain later expires or is repointed by an attacker.
+3. The agent replays the stored URL during a scheduled task.
+4. The backend performs a trusted internal fetch to attacker infrastructure.
+
+#### Mitigations
+
+- Re-validate all agent-stored URLs before every execution.
+- Bind allowed fetch destinations using certificate pinning or static IP allowlists.
+- Enforce short-lived trust windows for stored URLs.
+- Log and alert on changes in DNS resolution for previously trusted domains.
+
 ## References
 
 ### OWASP