A responsible disclosure report on a permissions mismatch in ChatGPT Enterprise's GitHub and Google Drive connectors: how documented read-only access turned out to be full write access, and how OpenAI fixed it.
Read-Only Was a Lie: What We Found in ChatGPT Enterprise's GitHub Connector
During a security evaluation of ChatGPT Enterprise's connector capabilities, our research team discovered that the permissions displayed to users and administrators in the ChatGPT UI significantly understated the actual access granted to the model. The GitHub connector, documented as read-only, could create branches, files, commits, and pull requests. The Google Drive connector, similarly described as basic file access, exposed destructive operations including document deletion.
The root cause: ChatGPT Enterprise was silently routing connector sessions through the Codex connector, which carries full read/write permissions, even when users connected GitHub through the ChatGPT interface. Enterprise administrators making security decisions based on the documented permission scope were unknowingly approving write access to their source code repositories.
OpenAI fixed the issue approximately 30 days after our security team engaged.
Why We Were Looking: AI Connector Security Is a Blind Spot in Enterprise Deployments
At Tego AI, we help enterprises adopt and deploy AI agents safely, from selecting the right platforms to implementing the security controls and governance frameworks that make production AI workloads trustworthy. A significant part of that work today involves ChatGPT Enterprise: helping teams roll out custom GPTs, configure connectors, and understand the actual risk profile of the integrations they're enabling for their employees.
As we evaluate these environments alongside our customers, we systematically assess the trust boundaries and permission models of every platform we touch. ChatGPT Enterprise is one of the most widely deployed AI platforms in the enterprise market, and its connector ecosystem is the primary surface through which users grant the model access to real organizational data.
When evaluating any AI integration, the central question is: what can the model actually do with connected systems? The answer should be clear from documented permissions. With ChatGPT Enterprise's connectors, it wasn't.
The Permission Mismatch: ChatGPT's UI Said Read, the Tools Said Write
GitHub: Five Read Badges, Twenty Write Capabilities
The ChatGPT connector settings panel lists what appear to be read-only actions for the GitHub connector:
check_repo_initialized— READcompare_commits— READdownload_user_content— READfetch— READfetch_blob— READ
.webp)
The ChatGPT connector settings panel. Every action listed carries a READ badge, creating the impression of a safe, read-only integration.
This presentation implies limited, read-only access: reasonable for a coding assistant that needs to understand your codebase. A security team reviewing this would likely approve the integration.
The actual tool set available to the model told a very different story. When our research team asked ChatGPT to enumerate its GitHub tools and list only those with write capabilities, it returned:
add_review_to_pr
create_pull_request
enable_auto_merge
add_comment_to_issue
update_issue_comment
reply_to_review_comment
update_review_comment
add_reaction_to_issue_comment
remove_reaction_from_issue_comment
add_reaction_to_pr
remove_reaction_from_pr
add_reaction_to_pr_review_comment
remove_reaction_from_pr_review_comment
label_pr
create_branch
update_ref
create_file
create_blob
create_tree
create_commit
This is not a read-only permission set. This is full repository write access.
Live Proof: ChatGPT Created a Branch in a Production Repository
To validate this wasn't a documentation artifact or hypothetical tool definition, we asked ChatGPT to create a new branch in a test GitHub repository. The branch name: CHATGPT_WRITE_TEST_BRANCH.
It worked. The branch appeared in GitHub immediately. ChatGPT had called create_branch successfully, confirming the write capability was real and active, not theoretical.
.webp)
ChatGPT confirming "Branch created successfully!" alongside the create_branch tool call in developer mode.
To be sure, ChatGPT isn’t hallucinating, we repeated the test. Multiple branches were created by ChatGPT across sessions, all verified in GitHub's branch list.
.webp)
Google Drive: Document Deletion Was Available, Not Disclosed
The same pattern appeared in the Google Drive connector. While the documentation framed the integration as basic file access, the actual available operations included:
delete_documentcopy_document
delete_document is a destructive operation. Organizations whose employees connected Google Drive to ChatGPT under the assumption of read-only access were exposed to a model that could delete documents on their behalf.
The Codex Connector Was the Culprit: Wrong App, Wrong Scope, Wrong UI
Further investigation revealed why the write tools were available. The GitHub App installed when connecting through ChatGPT's interface was the ChatGPT Codex Connector, a GitHub App developed by OpenAI that explicitly requests:
Read access to checks, commit statuses, and metadata
Read and write access to actions, code, issues, pull requests, and workflows
.webp)
The GitHub App installed by ChatGPT Enterprise's GitHub integration. The "ChatGPT Codex Connector" explicitly requests read and write access.
Codex is OpenAI's AI coding agent. It requires write access to repositories by design: it needs to create branches, commit code, and open pull requests. That scope is appropriate for Codex.
The problem: when a user connected GitHub through the ChatGPT Enterprise interface (not through Codex), the system was silently using the Codex connector with its broader permissions, while the ChatGPT UI displayed only the read operations.
Full Repository Write Access Was the Real Risk Profile
For GitHub integrations:
- ChatGPT could create, modify, or delete branches in any repository the authenticated user has write access to
- ChatGPT could create files, commits, and pull requests, including in production branches
- Prompt injection attacks targeting the GitHub connector could trigger unintended repository modifications
For Google Drive integrations:
- ChatGPT could permanently delete documents in the connected Drive
- Operations could affect documents the user had write access to but didn't intend to expose to AI operations
For enterprise security teams:
- Approval processes based on documented connector permissions were making decisions on incomplete information
- Risk models for ChatGPT Enterprise integrations systematically underestimated actual access scope
Five Steps Enterprises Should Take Right Now
- Audit currently installed GitHub Apps in your GitHub organization settings. Look for the "ChatGPT Codex Connector" and review the actual OAuth scopes it was granted.
- Review connector authorizations for all ChatGPT Enterprise integrations. The documented permission view may not reflect the full OAuth scope granted.
- Treat AI connector permissions conservatively: document what the connector can do, not just what the vendor says it will do.
- Monitor for unexpected repository changes attributable to service accounts or OAuth apps associated with ChatGPT.
- Enable branch protection rules on critical repositories.
Documented Permissions Must Equal Actual Permissions: The Architectural Lesson
This issue illustrates a pattern that will become increasingly common as AI platforms expand their connector ecosystems: the gap between documented capabilities and actual capabilities in AI integrations.
When organizations evaluate whether to connect an AI system to their infrastructure, they rely on the vendor's documentation of what access is being granted. If that documentation is inaccurate (even by omission), security teams cannot make sound decisions. In the case of agentic AI systems with tool-calling capabilities, that gap translates directly to unauthorized write access to production systems.
The OWASP Top 10 for Agentic Applications (2026) frames this under ASI-02 (Tool Misuse and Exploitation) and ASI-03 (Identity and Privilege Abuse): when the privilege boundary is misrepresented in the UI, every downstream decision built on that representation is wrong. The NIST AI RMF Agentic Profile makes the same point from the governance side: the documented scope of an AI integration must be the authoritative, complete representation of what the model can do, not a summary that understates it.
The deeper lesson is architectural. Permissions shown in an AI platform's UI should reflect actual OAuth scopes granted, verified at runtime, not inferred from product intent.
Q&A
Q: Was this a vulnerability in ChatGPT or in GitHub?
It was a misconfiguration in how ChatGPT Enterprise routed GitHub connector sessions. GitHub behaved correctly: it granted the scopes the OAuth app (the Codex connector) requested. The problem was that OpenAI was using the Codex connector (full read/write) for ChatGPT Enterprise's GitHub integration while only displaying the read operations in the UI. The UI misrepresented the actual permission scope being granted.
Q: Is this fixed now?
Yes. OpenAI confirmed the fix on February 19, 2026. We independently verified on March 2, 2026, that the connector UI and actual tool access were consistent. If you connected GitHub to ChatGPT Enterprise before that date, you should still audit the GitHub Apps installed in your organization to confirm what OAuth scopes remain active.
Q: Could an attacker have exploited this without the user knowing?
Yes. Indirect prompt injection is the relevant attack path: a malicious payload embedded in a file the agent reads (a README, a PR description, a code comment) could instruct ChatGPT to create branches, commit files, or open pull requests without any explicit user instruction. The user would see the model "helping" with a task while the injected instructions triggered unintended repository modifications in the background.
Q: What should we do if we connected GitHub to ChatGPT Enterprise before the fix?
Go to your GitHub organization settings under "Installed GitHub Apps" and check whether the ChatGPT Codex Connector is listed. Review the permissions it was granted. If it has read/write access to code and pull requests and you connected it through the ChatGPT interface (not through Codex), revoke and reinstall it after confirming the updated connector behavior. Also enable branch protection rules on any repositories that were accessible to the integration.
Q: Does this affect ChatGPT personal accounts or only Enterprise?
Our research focused on the ChatGPT Enterprise connector ecosystem, which is the deployment context where enterprise security teams are making formal approval decisions based on documented permissions. Whether analogous permission mismatches exist in other ChatGPT tiers wasn't in scope for this evaluation.
Q: What does this say about AI connector security more broadly?
It says you shouldn't rely on the vendor's UI to accurately represent what access an AI integration holds. The authoritative source is the OAuth app's granted scopes, visible in the connected platform (GitHub organization settings, Google Workspace admin console, etc.), not the AI product's settings panel. For every AI connector your organization enables, verify the actual OAuth scopes granted at the source, not through the AI platform's display layer. This is the same principle the NIST AI RMF Agentic Profile calls out: AI systems' access should be verifiable, not assumed from documentation.
Disclosure Timeline
Tego AI helps enterprises adopt AI agents safely: from platform evaluation to connector security and governance.