Public Risk Report: OpenAI Ecosystem (2026)
PDF Version: Updated on 12/01/26
Due to a current attack that is in progress. This link is made available to a select view with a password.
Timeline of the recorded incident as of 12/01/2026
Discovery
Escalation
Status
| Date / Phase | Event | Expected Response | Observed Response | Risk Signal |
|---|---|---|---|---|
| Initial use | Notion connector enabled with limited scope. | Access constrained to authorised pages only. | Out-of-scope private pages accessible. | Critical |
| Discovery | Unexpected private content surfaced during normal use. | Immediate containment and investigation. | No containment; behaviour reproducible. | Critical |
| Revocation attempt | User revoked connector permissions. | Immediate and complete access invalidation. | Access persisted after revocation. | Critical |
| Reconnection / expiry | Connector reconnected and time allowed to elapse. | No residual access or cached content. | Previously accessible private content remained reachable. | Critical |
| Initial report | Issue reported via vulnerability / safety channels. | Triage → escalation → engineering review. | Triage looped; testing incorrect; no escalation. | Critical |
| Safety escalation | Reports flagged involving minors and DV survivors. | Immediate Trust & Safety engagement. | No Trust & Safety involvement. | Critical |
| Incident handling | Cross-vendor coordination expected. | Joint investigation and shared remediation. | No coordination; reports misrouted to legal inbox. | High |
| Closure | Report closed. | Root cause analysis and documented resolution. | No RCA; no confirmation of fix; no audit trail. | Critical |
1. Technical Implications (as of 29/11/25)
These stem from the connector’s observed behaviour. The below has been sent and logged as a ticket with OpenAI and the OAIC.
No response has been received as of 16th January, 26.
1.1. Permission Boundary Failure
A connector accessing private Notion content beyond the authorised scope indicates:
flawed access-control enforcement
broken revocation semantics
stale or unbounded cache/index behaviour
possible improper reuse of tokens
lack of internal guardrails between “allowed pages” and “all pages previously indexed”
Implication:
The architecture cannot reliably guarantee confidentiality or least privilege — which undermines all enterprise assurances about data isolation.
1.2. Revocation Failure
Permissions revoked at the Notion side and reconnection performed with restricted scope still resulted in access to previously private pages.
Implication:
The system may retain document bodies or embeddings beyond permission boundaries, violating expected token lifecycle management and creating ongoing exposure even after user corrective action.
1.3. Multi-Account Reproducibility
The behaviour appears on several accounts, which strongly suggests systemic, not edge-case, causes.
Implication:
This is not a user-specific anomaly. It represents a platform-level architectural risk affecting multiple tenants.
1.4. Undocumented Connector Behaviour
There is no public documentation describing:
caching approach
index persistence
revocation timing
how permission deltas propagate
expected state after re-authentication
connector boundary guarantees
Implication:
Enterprises cannot make informed risk assessments because critical behaviours are opaque.
2. Security & Compliance Implications
2.1. Cross-Framework Non-Compliance Exposure
Based on the behaviour and evidence, the system is likely in conflict with:
GDPR Article 25, 32, 33
APP 11, 6, and NDB
ISO 27001, 27017, 27018, 27701
SOC 2 Security, Confidentiality, Processing Integrity
CSA STAR
CCPA Sections 1798.150 & 1798.100
CISA Secure-by-Design expectations
NIST CSF (Identify/Protect/Respond)
Implication:
The incident represents a multi-standard compliance alignment failure, increasing regulatory exposure across AU, EU, and US jurisdictions.
2.2. Breach-Notification Triggers
EU GDPR, AU NDB, and CCPA all require breach assessment upon unauthorized access.
No such assessment was conducted.
Implication:
Failure to evaluate or notify may constitute an independent regulatory breach, regardless of the underlying technical flaw.
2.3. Misrepresentation of Security Posture
The public Trust Portal asserts:
permission-bounded access
industry-standard controls
secure revocation
reliable incident response
audited certifications
Your evidence contradicts this.
Implication:
Potential exposure under consumer-protection regimes (e.g., ACL s18, FTC Act s5, EU consumer protection harmonisation).
3. Governance & Operational Implications
3.1. Breakdown of Vulnerability Handling Pathways
The Bugcrowd loop demonstrates:
non-technical triage
incorrect reproduction attempts
disregard of provided evidence
ticket closure without resolution
no escalation despite explicit requests
no engineering involvement
Implication:
The vulnerability disclosure workflow fails to meet CVD (Coordinated Vulnerability Disclosure) norms and security best practices.
3.2. Breakdown of Internal Routing
Your report was handled by:
generic support
then routed to legal@openai.com
without ever reaching security, privacy, or engineering teams
Implication:
This indicates:
no functional incident routing
no defined IR chain
unclear ownership of safety/security incidents
potential liability containment replacing safety escalation
This is a governance failure, not a support mistake.
3.3. Absence of Audit Trails
There is no evidence of:
internal access logs
connector access logs
incident logging
risk assessment artifacts
DPIA-like evaluation
system behaviour notes
Implication:
Breach investigations and auditing are hindered — contradicting both ISO and GDPR governance requirements.
4. Safety & Human Harm Implications
4.1. Impact on Vulnerable Users
Your evidence includes:
minors in school settings
Domestic Violence survivors relying on Notion for safety planning
psychological harm content distributed via official channels
exploitation scenarios
Implication:
Ignoring such reports contravenes safety-by-design, Online Safety Act expectations, and any ethical AI framework.
4.2. Harm Amplification via Connector Flaw
If a person in a dangerous environment uses Notion for safety/escape planning and the AI connector retrieves that content unexpectedly, an abuser with access to their device could view it.
Implication:
A technical flaw becomes a direct safety risk with real-world harm potential.
5. Platform Trust & Enterprise Risk Implications
5.1. Enterprise Deployment Instability
Organisations considering connectors (Notion, OneDrive, Google Drive) rely on enforceable boundaries.
If these boundaries are not reliable:
Implication:
Enterprise customers may be exposed to unseen cross-scope data breaches and cannot safely integrate OpenAI services in regulated industries (health, finance, education, government).
5.2. Reputational Risk
OpenAI markets:
safety
privacy
compliance
secure design
responsible AI
A documented case where:
permissions fail
vulnerabilities go unaddressed
safety reports are ignored
legal absorbs support flow
no breach assessment occurs
This creates reputational exposure.
6. Cross-Vendor Implications (OpenAI ↔ Notion)
6.1. Joint Controller / Processor Duties
The connector creates shared responsibilities between Notion and OpenAI.
Implication: Failure in one system propagates into compliance failures for the other, creating compounding liability.
6.2. Transparency & Responsibility Gap
Neither company documented the connector’s actual behaviour or informed users of risks.
Implication: Regulators may treat this as a joint failure of privacy-by-design and shared processing governance.
7. Long-Term Ecosystem Implications
7.1. AI Governance Expectations
Global norms (OECD, G7, UN, NIST) require:
transparency
robustness
incident reporting
traceability
human oversight
risk management
Implication: This becomes a case study of how frontier AI deployments can fail across safety/security/governance simultaneously.
7.2. Lessons for AI Connectors Globally
This exposes an entire class of risk:
permissions being treated as advisory
stale indexes leaking data across boundaries
connectors retaining more information than documented
cross-platform revocation not respected
Implication: This could affect all AI–third-party integrations if similar revocation/design patterns exist.
8. Evidence Preservation Implications
8.1. High-Risk Evidence Wipe Potential
Given system instability, legal routing, and non-response patterns:
Implication:
Your assessment (keep multiple copies) is correct.
Evidence may not be preserved internally, so external redundancy is essential.
Recommended storage:
local encrypted archive
offline copy
cloud backup in independent jurisdiction
timestamped hash
RISK TIERING
This section classifies the risks arising from the connector behaviour and the subsequent failure of OpenAI’s incident-handling systems. The tiering model follows standard risk categories used in privacy, security, safety, and governance frameworks.
1. Technical Security Risk — CRITICAL
Description
Unauthorized access to private Notion content outside the permitted scope, persisting across reconnections, revocations, and time delays.
Contributing Factors
Revocation does not invalidate access
Stale index or token reuse
Permission boundaries not enforced
Cross-account reproducibility
Undocumented connector behaviour
Reason for Critical Tier
Direct compromise of confidentiality
Cross-tenant exposure potential
Violates core security expectations across multiple frameworks
Represents a system-level architectural flaw, not an isolated defect
Cannot be mitigated by the user
Classification: Critical system-security failure
2. Privacy & Data Protection Risk — CRITICAL
Description
Processing and returning personal data outside the authorised scope, with no breach assessment or notification pathways activated.
Contributing Factors
Breach of lawful basis and purpose limitation
Breach of integrity/confidentiality
Lack of data minimisation controls
Absence of records of processing
Affected data includes highly sensitive categories
Reason for Critical Tier
Clear triggers for GDPR Article 32/33 and AU NDB
Risk of serious harm to affected individuals
Exposure of sensitive personal information without user knowledge
No incident-response behaviour by the controller or processor
Classification: Critical privacy breach with regulatory implications
3. Safety & Human Harm Risk — CRITICAL
Description
Exposure directly affecting minors, vulnerable users, and individuals at risk of interpersonal harm.
Contributing Factors
DV survivor safety planning material accessible
Harmful content circulated on official platforms
Minors exposed to psychologically harmful “training” patterns
Reports of harm ignored by OpenAI support and triage teams
No routing to trust & safety
Reason for Critical Tier
“Likely risk of serious harm” standard is met
Safety failures compound privacy failures
System design and reporting pathways both fail simultaneously
Groups involved meet regulatory definitions of high-risk populations
Classification: Critical real-world harm exposure
4. Governance & Compliance Risk — CRITICAL
Description
The failure of OpenAI’s internal reporting, escalation, and incident-management systems across multiple channels (Bugcrowd, support@, legal@).
Contributing Factors
No engineering involvement at any stage
No breach assessment
No escalation despite explicit requests
Misrouting to legal@ for a security incident
Template responses replacing risk evaluation
No acknowledgment of system-level failure
Reason for Critical Tier
Governance breakdown across multiple internal teams
Contradiction with claims made in OpenAI’s Trust Portal
Exposure across multiple compliance regimes (GDPR, ISO, SOC2, CCPA, OAIC)
Indicates lack of operational maturity in high-severity incident handling
Classification: Critical organisational-governance failure
5. Reputational & Enterprise Trust Risk — HIGH
Description
Undermining enterprise-customer confidence in OpenAI’s connectors, permissions, and security posture.
Contributing Factors
Enterprise relies on permission enforcement
Connector behaviour contradicts security marketing
No transparency or documentation
Incident reports ignored for two months
Real-world harm cases unreviewed
Reason for High Tier (not Critical)
Severity substantial, but reputational impact depends on whether incident becomes public or regulator-driven
Still a major enterprise trust concern
Classification: High reputational risk with systemic consequences
6. Cross-Vendor Ecosystem Risk (OpenAI ↔ Notion) — HIGH
Description
Joint-controller and processor duties not met between platforms.
Contributing Factors
Undefined responsibility boundaries
No coordinated incident handling between vendors
Shared tenant exposure without clear accountability
Integration behaviour contradicts both companies’ claims
Reason for High Tier
Impact potentially large but depends on Notion’s infrastructure and logging
Risk increases if integration is widely deployed in regulated industries
Classification: High inter-vendor governance risk
7. Long-Term Systemic Risk — HIGH
Description
The observed flaws point to a category of risk applicable to all AI-app integrations, not just Notion–OpenAI.
Contributing Factors
Connector architecture pattern likely similar across OneDrive, Google Drive, Confluence, etc.
If permission enforcement is consistently handled via stale indexing, larger systemic risk exists
Missing incident-handling capability affects other vulnerabilities
Reason for High Tier
Systemic impact probable
Depends on replication across additional connectors
Regulatory scrutiny likely to expand scope if discovered
Classification: High systemic AI/connector ecosystem risk
Summary of Risk Tiers
| Risk Category | Tier |
|---|---|
| Technical Security | CRITICAL |
| Privacy & Data Protection | CRITICAL |
| Safety & Human Harm | CRITICAL |
| Governance & Compliance | CRITICAL |
| Enterprise Reputation | HIGH |
| Cross-Vendor Ecosystem | HIGH |
| Systemic / Long-Term | HIGH |
1. OpenAI Policy Commitments (Public Statements & Published Documentation)
This section outlines the commitments OpenAI makes to users, enterprise customers, and regulators through its public documentation, product descriptions, and security statements. These commitments define the expected behaviour of the OpenAI–Notion connector and associated systems.
1.1. Data Access and Permissions
OpenAI states that:
“ChatGPT can only see what you can see in your connected apps.”
“Connectors respect existing permissions and only access data the user is authorised to view.”
“Users can revoke access at any time, and revocation removes connector access.”
Expected baseline: Connector access must strictly follow granted permissions; revocation must reliably remove access.
1.2. Security and Privacy Commitments
OpenAI states that:
It follows industry-leading security practices.
It provides “enterprise-grade security and privacy controls.”
User data is protected through secure architecture, token control, and access boundaries.
Sensitive data is processed in compliance with GDPR, CCPA, and other data-protection regimes.
Access and data flows are transparent and auditable.
Expected baseline: No system component should access data outside the permitted scope, and auditability should be functional.
1.3. Incident Response and Vulnerability Handling
OpenAI publicly commits to:
Coordinated Vulnerability Disclosure (CVD).
Use of Bugcrowd as the official intake channel for security issues.
Internal escalation to the appropriate engineering and security teams.
Timely, structured responses to high-severity issues.
Processes that ensure prompt assessment of reported vulnerabilities.
Expected baseline: Security issues involving unauthorized access must be quickly escalated, triaged, investigated, and acted upon.
1.4. Safety and Harm Prevention
OpenAI states that:
Protecting users — especially minors and vulnerable groups — is a core priority.
Serious safety concerns are routed to Trust & Safety teams.
The company monitors and enforces policy on misuse across affiliated platforms.
All safety reports are taken seriously and reviewed appropriately.
Expected baseline: Reports involving harm to minors, vulnerable individuals, or psychological harm must trigger a safety review.
1.5. Transparency and Accountability
OpenAI claims:
Clear, transparent communication about system behaviour.
Clear guidance for reporting privacy, security, and safety issues.
Behaviour consistent with documented connector operation.
Expected baseline: Connector behaviour should match documentation, and reporting pathways should be functional and accessible.
2. OpenAI Certification & Compliance Commitments (Trust Portal Claims)
OpenAI displays a set of formal certifications and compliance badges on its Trust Portal. Each badge represents obligations and audit expectations. The presence of these badges establishes a higher baseline for system behaviour, incident handling, and security posture.
These certifications define the standard against which the observed behaviour must be measured.
2.1. ISO/IEC 27001:2022
Information Security Management Systems (ISMS). Requires:
Effective access controls
Secure design and configuration
Incident response and escalation pathways
Logging and monitoring
Continuous risk assessment
Alignment with documented policies and procedures
Expected behaviour: Systems must enforce permission boundaries accurately and support timely incident handling.
2.2. ISO/IEC 27017
Cloud security controls. Requires:
Tenant isolation
Secure handling of cloud resources
Correct configuration of cloud-specific access paths
Expected behaviour: Cloud-integrated connectors must not access data outside configured scopes.
2.3. ISO/IEC 27018
PII protection in cloud environments. Requires:
Robust safeguards for personal data
Strict access-control discipline
Reliable revocation of access rights
Transparency regarding processing
Incident notification when required
Expected behaviour: Data stored in Notion (including personal content) must not be accessed without valid authorization.
2.4. ISO/IEC 27701
Privacy Information Management System (PIMS). Requires:
Documented processing activities
Privacy-impact evaluation
Clear controller/processor responsibilities
Privacy-intrusive events triggering internal review
Expected behaviour: Privacy incidents must be logged, assessed, and escalated.
2.5. SOC 2 Type 2
Trust Services Criteria: Security, Confidentiality, Privacy, Processing Integrity.
Requires:
Logical access control
Vulnerability management
Change management
Incident response
Consistent security practices over time
Expected behaviour: Security vulnerabilities must be properly triaged and handled; systems must behave consistently with claims.
2.6. CSA STAR
Cloud Security Alliance certification for transparency and cloud security maturity.
Requires:
Clear disclosures
Documented security controls
Transparent connector behaviour
Functional IR processes
Expected behaviour: Connector operation must match disclosed documentation and audit expectations.
2.7. GDPR Compliance Badge
Represents adherence to:
Article 32 (security of processing)
Article 25 (data protection by design and default)
Article 6 (lawfulness)
Article 33 (breach notification)
Principle of transparency
Purpose limitation and data minimisation
Expected behaviour: Unauthorized access should not occur; breaches must trigger assessment and appropriate notification.
2.8. CCPA / CPRA Badge
Requires:
Reasonable security procedures
Controls preventing unauthorized access/disclosure
Accurate representations of system behaviour
Expected behaviour: Data returned outside the permitted scope is incompatible with CCPA compliance.
2.9. TX-RAMP and Government Standards
Requires:
Government-grade controls
Access-boundary integrity
Clear incident-handling procedures
Demonstrable compliance with security baselines
Expected behaviour: Security issues must be escalated with documented handling and remediation.
MASTER COMPLIANCE CONTRADICTION MATRIX
This matrix maps each OpenAI commitment (policy + certifications) against the observed connector behaviour and documented incident-handling breakdowns. It provides a consolidated view of how the incident intersects with global security, privacy, safety, and governance frameworks.
1. Policy Commitments vs Observed Behaviour
| OpenAI Public Commitment | Expected Standard | Observed Behaviour | Status | Risk Tier |
|---|---|---|---|---|
| “ChatGPT can only see what you can see.” | Permissions strictly enforced; no access beyond scope. | Connector returned private Notion pages outside scope. | Contradicted | CRITICAL |
| “Revocation removes access.” | Revocation must trigger full access invalidation. | Access persisted after revocation, reconnection, and time expiry. | Failed | CRITICAL |
| “Connectors respect existing permissions.” | All access must remain within Notion-permitted teamspace/pages. | Connector retrieved pages not granted in the limited scope. | Failed | CRITICAL |
| “We follow coordinated vulnerability disclosure.” | Triage → escalation → engineering → assessment. | Triage looped, mis-tested, never escalated, then closed. | Failed | CRITICAL |
| “We take reports involving safety and vulnerable users seriously.” | Immediate safety escalation. | Reports ignored; routed to legal@; no T&S engagement. | Failed | CRITICAL |
| “Enterprise security is transparent and auditable.” | Logs, traceability, consistent behaviour. | No logs, no audit trail, no transparency on connector behaviour. | Failed | HIGH |
| “Incident reports are routed to relevant internal teams.” | Security/SRE/privacy/T&S must receive reports. | All routing failed; legal inbox swallowed chain. | Failed | CRITICAL |
2. Certification Claims vs Framework Requirements
| Certification | Expected Obligations | Observed Behaviour | Status | Risk Tier |
|---|---|---|---|---|
| ISO 27001 | Access control, incident response, monitoring, secure design. | Permission failure and absence of incident response. | Failed | CRITICAL |
| ISO 27017 | Secure cloud configuration; tenant isolation. | Cross-scope access to private Notion pages. | Failed | CRITICAL |
| ISO 27018 | PII isolation and revocation integrity. | Private content remained accessible post-revocation. | Failed | CRITICAL |
| ISO 27701 | Privacy governance; DPIA-like evaluation; defined roles. | No privacy-team involvement; no records of processing. | Failed | HIGH |
| SOC 2 Type II | Logical access controls, vulnerability management, IR maturity. | Broken access enforcement and failed vulnerability handling. | Failed | CRITICAL |
| SOC 3 | Public attestation of SOC 2-aligned controls. | Public claims contradicted by observed control failures. | Contradicted | HIGH |
| CSA STAR | Cloud transparency and control maturity. | Connector behaviour undocumented and non-transparent. | Failed | HIGH |
| GDPR | Articles 5, 6, 25, 32, 33 compliance. | Multi-article failure with no breach assessment. | Failed | CRITICAL |
| CCPA | Reasonable security measures and truthful representations. | Security representations contradicted by behaviour. | Failed | HIGH |
| TX-RAMP | FedRAMP-like public-sector security controls. | No functioning incident response; permission enforcement failure. | Insufficient | HIGH |
3. Australian Law & Regulatory Frameworks vs Behaviour
| AU Framework | Required Behaviour | Observed Behaviour | Status | Risk Tier |
|---|---|---|---|---|
| APP 11 (Security) | Prevent unauthorised access; enforce revocation; incident response capability. | Out-of-scope access and absence of incident response. | Failed | CRITICAL |
| APP 6 (Use / Disclosure) | No use or disclosure outside authorised purpose. | Connector accessed content explicitly not authorised. | Failed | CRITICAL |
| APP 1 (Transparency) | Clear explanation of personal data handling. | Connector caching and indexing behaviour undocumented. | Failed | HIGH |
| APP 10 (Accuracy) | Data must be current, relevant, and appropriate. | Stale private content accessible after revocation. | Degraded | MEDIUM / HIGH |
| Notifiable Data Breach Scheme | Breach assessment and potential notification. | No breach assessment conducted or documented. | Failed | CRITICAL |
| Online Safety Act | Safeguards for minors and vulnerable people. | Safety-related reports ignored. | Failed | CRITICAL |
| eSafety Safety-by-Design | Effective reporting pathways and escalation. | Reporting pathway failed end-to-end. | Failed | CRITICAL |
| ACSC “Reasonable Security Steps” | Incident response, access control, secure configuration. | Incident response failure and access-boundary failure. | Failed | CRITICAL |
| Australian Consumer Law (ACL) | No misleading or deceptive security representations. | Permission-boundary claims contradicted by behaviour. | Contradicted | HIGH |
4. Safety & Human Harm Governance vs Behaviour
| Commitment Area | Expected Behaviour | Observed Behaviour | Status | Risk Tier | |||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Protection of minors | Investigate reports and escalate harmful content. | No action taken following explicit reports. | Failed | CRITICAL | |||||||||||||||||||||||||||||||||||||||||||||||
| Protection of vulnerable groups | Immediate risk review and safety-team involvement. | Domestic violence survivor scenarios ignored. | Failed | CRITICAL | |||||||||||||||||||||||||||||||||||||||||||||||
| Misuse on affiliated platforms | Moderation and enforcement against harmful misuse. | Harmful “training,” scams, and psychosis-like prompts left active. | Failed | HIGH /
5. Cross-Vendor (OpenAI ↔ Notion) Responsibility Matrix
6. Consolidated Risk Ratings (From Master Matrix)
7. Summary PositionThe Master Matrix demonstrates that the incident is not isolated, trivial, or limited to a single connector.
…with risk implications in every critical category. Next
Next
Human–AI Cognitive & Behavioural Forensics |
