mirror of
https://github.com/vxcontrol/pentagi.git
synced 2026-07-20 12:37:04 -04:00
[GH-ISSUE #208] [Enhancement]: Support OAuth-based LLM authentication (ChatGPT / Google Gemini) or external OAuth gateways #79
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @CharanRayudu on GitHub (Mar 15, 2026).
Original GitHub issue: https://github.com/vxcontrol/pentagi/issues/208
Originally assigned to: @asdek on GitHub.
Target Component
External Integrations (LLM/Search APIs)
Enhancement Description
Hi maintainers,
First of all, thank you for building PentAGI. It is a very powerful framework for autonomous security testing.
Currently PentAGI requires users to configure LLM providers using API keys (OpenAI, Gemini, Anthropic, etc.). While this works well, many developers already have LLM access through subscription-based web accounts, such as:
ChatGPT (OpenAI subscription)
Google Gemini (Google account / Gemini Advanced)
In those cases, users cannot easily reuse their existing access because PentAGI expects API keys.
Some newer agent frameworks such as OpenClaw support OAuth-based authentication, allowing users to log in with their account and then route requests through a local gateway.
Technical Details
I implemented a local project that authenticates to ChatGPT via OAuth and calls Codex models using the internal ChatGPT backend endpoint.
The request endpoint used is:
https://chatgpt.com/backend-api/codex/responses
Authentication is handled using an OAuth access token stored locally (for example in ~/.codex/auth.json).
However, the request format used by this endpoint is different from the OpenAI API format currently expected by PentAGI.
Example payload structure used by the Codex backend:
{
"model": "...",
"instructions": "...",
"input": "...",
"store": true,
"stream": true,
"temperature": 0.2
}
This differs from the standard OpenAI-compatible request shape such as:
POST /v1/chat/completions
{
"model": "...",
"messages": [...]
}
Because PentAGI currently assumes OpenAI-compatible providers, this endpoint cannot be used directly even though it exposes powerful Codex models through OAuth authentication.
Designs and Mockups
One possible solution would be to introduce a pluggable LLM provider adapter layer.
Architecture example:
PentAGI
↓
LLM provider adapter
↓
Custom endpoint (Codex backend / OAuth providers)
↓
Model response
This would allow PentAGI to support providers that are not strictly OpenAI-compatible while still keeping the existing OpenAI provider implementation unchanged.
Alternatively, PentAGI could allow defining:
This would enable integration with endpoints such as:
https://chatgpt.com/backend-api/codex/responses
Alternative Solutions
Another approach would be to use an adapter/proxy service.
PentAGI
↓
OpenAI-compatible proxy
↓
OAuth-authenticated provider
↓
Codex / Gemini / other models
The proxy would translate:
PentAGI OpenAI-style requests
into
Codex backend request format.
This approach keeps PentAGI unchanged while enabling additional provider integrations.
Verification
@asdek commented on GitHub (Mar 19, 2026):
hey @CharanRayudu
thanks for the detailed proposal!
unfortunately, we cannot include OAuth-based subscription authentication in PentAGI for several reasons:
legal issues
subscription terms (ChatGPT Plus, Gemini Advanced) explicitly prohibit using backend APIs outside the official interface. including this would encourage license violations and create legal risks for both the project and users.
technical problems
even ignoring the legal side, subscription endpoints have serious limitations:
what you can do
your proxy/gateway approach is actually correct - but should be implemented outside PentAGI as a separate service. there are existing projects like https://github.com/lbjlaq/Antigravity-Manager that do this, however, be aware of the risks.
recommended approach
use official API access instead - it's legal, reliable, feature-complete, and often cheaper for automation: