Notion AI Agent Lethal Trifecta Leads to Silent Data Exfiltration

Sanitizing AI-generated page edits before rendering prevents automatic image preview requests. Filtering unconfirmed image tags or escaping them into plain text (e.g., escaping ![image](url) with backslashes into \\!\\[image\\](url) so the browser treats it as a raw string rather than a rendering target) blocks the browser from making unauthorized outbound HTTP requests.

Dynamic per-request capability scoping ensures that an agent task triggered by summarizing an untrusted file does not inherit the authority to execute arbitrary web search tools or modify database pages without step-up approval.

Decoupling access rules from application logic via policy engines (such as Open Policy Agent or Casbin) prevents privilege escalation. A stateful authorization check can block the agent from querying sensitive workspace database pages (like hiring trackers) during simple resume summary tasks.

For URL retrieval inside functions.search, the provider must route the actual URL and every redirect through the mandatory single-pass pinned safe fetcher and deny direct bypasses. Checking only the search API hostname does not check a URL embedded in its query or stop disclosure to an approved search service. Destination authorization and sensitive-data authorization are separate. This is a provider integration requirement, not a Notion administrator setting or the published method merely enabled by a domain list.

A provider-controlled architecture can put raw resume parsing in a separately isolated Q worker with no Notion write tools, credentials or privileged network access. A validating broker passes only bounded task fields to the P planner. Typed strings and derived links remain untrusted and require independent document-write and image-sink authorization. This reduces direct raw-payload exposure, but a schema-validated summary is not proof of semantic safety and is not a setting available to an ordinary Notion workspace user.

Before provider-side context assembly, apply versioned screening to parsed PDF text and synchronously reject, quarantine, sanitize or route findings for review. Test this payload and transformed variants and deny when required checks are unavailable. Screening can miss semantic attacks; final tool and rendering authorization remain independent. This is not a customer hook exposed by the stock SaaS interface.

Provider-side egress policy can restrict the search backend to approved destinations when every request traverses that controlled path. It does not constrain a separate browser image request. The preview path needs separately verified renderer/CSP or managed-browser enforcement, including redirects and direct bypasses. Allowed destinations can still receive sensitive query data, so data-aware sink authorization is required. Ordinary workspace customers do not control Notion's service network.

Define document processing as low-autonomy Observe/Analyze work and mark workspace writes, delegation, persistence, and outbound calls as supervised or prohibited functions. This profile supplies policy facts; AID-H-018.002 owns the runtime allow or deny decision.