I connected Perplexity Computer to my personal GitHub account. The authorization screen requested sixteen OAuth scopes. One was delete_repo. Another was workflow - write access to GitHub Actions files. A third was admin:public_key, which lets the connected app add SSH keys to my account. I wanted to search my code.
The Trust Model Your Infrastructure Assumes
When you connect an agentic AI tool to a service via OAuth, you hand the agent a set of keys. Each grants a class of actions. Traditional GitHub OAuth App tokens have no scheduled expiry while actively used; they remain valid until revoked or invalidated by specific GitHub controls.
Every perimeter control you run assumes the threat originates outside the boundary. Identity-Aware Proxy on Cloud Run validates the inbound HTTP request, but it never sees the Gmail API call that goes straight to gmail.googleapis.com. As I argued in my IAP article, IAP guards the request path, not the scope of a token once that token has been issued. The gap is architectural.
OAuth was designed for human-delegated access. You consent once, use the app, revisit when something feels wrong. Agentic tools break that model: the token has no scheduled expiry while in use, and the agent operates across multiple services at machine speed.
What One Connector Exposed
I tested the GitHub connector against my personal account (jrehagen) and a sandboxed Gmail test account. Both used real OAuth flows and real scope grants. GitHub findings are operational, first-person. Gmail findings are controlled, sandboxed. Slack and Notion are analyzed from documentation only.
GitHub's connector requests repo - full read and write to every repository I can access. GitHub's OAuth model offers no read-only equivalent. Any app that needs to read private code requests the same scope that grants write and delete. Perplexity chose an OAuth App over a GitHub App, forgoing repository-level scoping and short-lived tokens.[^8][^10]
The Gmail connector requests gmail.modify - Google's second-most permissive email scope.[^14] A 2018 IEEE paper found email access alone compromises 81.1% of high-traffic websites via password reset flows.[^1] The connector's consent request bundles it with calendar events, contacts, and the full Workspace directory.
The Structural Argument
None of this is an implementation bug waiting to be patched. It is what OAuth becomes when the client is an autonomous agent instead of a person, and it shows up three ways.
First, the tokens persist. A GitHub OAuth App token has no scheduled expiry while it is in active use; GitHub will kill it after prolonged inactivity, a public leak, enterprise action, or an explicit revocation, but nothing short of those.[^2] So a breach at Perplexity inherits every scope you granted, and keeps it. The Salesloft/Drift incident of August 2025 showed the blast radius: tokens stolen from one AI vendor opened Salesforce data at more than 700 organizations.[^3]
Second, processing untrusted input is the whole job. An agent reads your email, summarizes web pages, and works through documents it was handed by someone else. Simon Willison's "lethal trifecta" names the danger: private-data access, exposure to untrusted content, and a way to exfiltrate.[^4] Every multi-connector setup has all three at once. CometJacking put that to work, riding pre-existing OAuth grants and Base64-encoding the payload to slip past Perplexity's exfiltration detection.[^5]
Third, the attacks actually land. A meta-analysis of 78 studies put success rates between 66.9% and 84.1% in agentic systems with auto-execution.[^6] Vendors have begun bolting on defenses - CrowdStrike's Falcon integration with Comet Enterprise (March 2026) adds a runtime inspection layer[^7] - but a runtime filter sits downstream of the grant. It shrinks the blast radius without changing what the token is allowed to reach.
The Practitioner Posture
I run Bevis (personal finance) and Trellis (honeypot platform) behind IAP on Cloud Run. Connecting either to a multi-connector agent gives the agent indirect paths to protected data - through email, calendar, or any tool containing service URLs or credentials.
My current posture: I have not connected Gmail. I connected GitHub to a personal account only. Before connecting any enterprise service, I will audit scopes, model what prompt injection could reach, and treat the token as a persistent service account credential.
For any team enabling these connectors: review scopes before authorizing, separate personal and organizational grants, establish a revocation procedure. Check grants at github.com/settings/applications and myaccount.google.com/permissions.
These tokens are active, persistent, and largely invisible to your existing security stack.
Evidence Tiers
This article uses three evidence tiers. Every claim below is labeled so you can weight it accordingly.
| Tier | Label | Description |
|---|---|---|
| 1 | Operational | Tested on my own jrehagen GitHub account connected to Perplexity Computer |
| 2 | Controlled test | Tested against a dedicated Gmail test account with real OAuth flows |
| 3 | Architectural analysis | Derived from vendor documentation and published security research. Not tested against a live connector. |
What GitHub OAuth Actually Grants (Tier 1 - Operational)
Perplexity's help documentation lists the GitHub connector's required permissions.[^8] Cross-referenced against GitHub's OAuth scope definitions,[^9] the full scope set is:
repo, admin:org, admin:org_hook, admin:repo_hook, admin:gpg_key,
admin:public_key, codespace, write:packages, delete:packages,
delete_repo, gist, notifications, project, read:audit_log, user, workflow
The most consequential scopes and their practical implications follow.
repo - Full repository read/write. GitHub's documentation: "Grants full access to public and private repositories including read and write access to code, commit statuses, repository invitations, collaborators, deployment statuses, and repository webhooks."[^9] The scope also grants access to org-owned projects, invitations, and team memberships. There is no read-only variant. GitHub's community has documented this limitation since 2015.[^10] A Builder.io review confirmed Computer uses this scope to directly add and remove files via the GitHub API, bypassing any local git workflow.[^11]
admin:org - Full organization administration. Enumerates and modifies org membership, team structures, and projects. For enterprise users, this scope exposes the org chart and allows membership modification.
admin:public_key - SSH key management. Creates, lists, and deletes SSH public keys on the user's account. A compromised session can add an attacker's SSH key, providing persistent git access independent of the OAuth token.
delete_repo - Permanent repository deletion. There is no undo. The consent screen presents it as "Ability to delete any adminable repository."
workflow - GitHub Actions modification. Creates and modifies .github/workflows/*.yml files. GitHub's own documentation flags the risk: "Workflow files can expose GITHUB_TOKEN which may have a different set of scopes."[^9] A workflow that exfiltrates secrets constitutes a serious security incident.
codespace - Codespace management. GitHub warns: "Codespaces can expose a GITHUB_TOKEN which may have a different set of scopes."[^9] A secondary token exposure path.
OAuth App vs. GitHub App
Perplexity uses an OAuth App, not a GitHub App. The distinction matters for token lifetime, scope granularity, and organizational risk.
| Property | OAuth App (Perplexity's choice) | GitHub App (more restrictive) |
|---|---|---|
| Token lifetime | No scheduled expiry while in use; ends on inactivity, leak, or revocation | Short-lived (1 hour); auto-refreshed |
| Repository scope | All repos the user can access | User selects specific repos during install |
| Permission granularity | Coarse (repo = full read/write) |
Fine-grained (e.g., Issues: Read-only) |
| Identity | Acts as the user | Acts as a named bot |
| Post-departure access | Retains access until revoked or invalidated by GitHub | Tied to org installation |
Source: GitHub documentation on OAuth App vs. GitHub App differences.[^12]
The Heroku/Travis-CI incident (April 2022) demonstrated the real-world attack path: stolen GitHub OAuth tokens gave attackers access to private npm repositories across dozens of organizations.[^13]
Confirmed Computer Actions via GitHub
User reports and documentation confirm Computer reads source code, writes files via the API, creates PRs, forks repos, and pushes commits as the authenticated user.[^11][^30]
What Gmail OAuth Reaches (Tier 2 - Controlled Test)
Evidence tier: controlled test - sandboxed account, real OAuth flow, synthetic data.
Perplexity's Gmail connector requests gmail.modify - Google's Restricted classification, covering read, compose, and send.[^14] The connector bundles calendar.events (view and edit), contacts.readonly, contacts.other.readonly, and directory.readonly (full G Suite org directory).
I confirmed these scopes by completing the OAuth flow against a test account. The consent screen listed: manage drafts and send emails, download contacts, view and edit calendar events, and access the organization's employee directory.[^15]
The IEEE INFOCOM paper (2018) analyzed 239 high-traffic websites. 92.5% use email for password reset. 81.1% are fully compromisable via inbox access alone.[^1] An agent holding gmail.modify can read incoming reset links and intercept 2FA codes without knowing the user's passwords.
The bundled scopes compound the exposure:
- Calendar events reveal meeting attendees, project names, org hierarchy, and physical locations from event descriptions
- The
directory.readonlyscope hands over the full employee directory - names, emails, titles, reporting lines - which is a ready-made target list for spear-phishing. - The
gmail.modifysend capability enables impersonation from the user's legitimate address. Email gateways pass these messages because they originate from the authentic account.
Straiker STAR Labs demonstrated a zero-click Drive wiper. An attacker sends a crafted email with "cleanup" instructions. The user asks Comet to complete recent tasks. The agent deletes Drive files. Google classified this as "won't fix (intended behavior)."[^16]
Perplexity's privacy policy prohibits using Gmail data to train AI models.[^17] Email content is stored and processed server-side. Retention specifics are not publicly documented.
Slack and Notion: The Connector Surface (Tier 3 - Architectural Analysis)
Evidence tier: architectural analysis. I have not connected either service.
Slack
Perplexity offers two Slack integrations with different permission models.
The bot app (Slack Marketplace) requests 19 scopes.[^18] The high-sensitivity subset: groups:history (private channels the bot joins), im:history (direct messages), files:read (files in channels the bot is in), im:write (start new DMs with any workspace member), and users:read.email (email addresses of all members). The bot holds these scopes once a workspace admin authorizes the app.
The user connector (OAuth) is more permissive. It acts under the user's identity. It inherits all Slack permissions the user holds - all private channels and DMs they belong to - without per-channel addition.[^19]
im:write is the scope to watch: it lets the bot open a direct message with any workspace member. Pair it with users:read.email and you have the makings of social engineering at machine speed across the whole workspace.
Notion
Notion's model is structurally better. Integrations declare capability categories and operate only on pages the user explicitly shares during the OAuth flow.[^23] This is resource-scoped by design.
Perplexity's Notion connector mirrors the user's access level (read and write) and accesses the workspace user directory with emails.[^20]
A critical audit gap: Perplexity logs which queries used Notion but does not record which pages were accessed or what content generated the answer.[^20] Admins can confirm Notion was used as a source. They cannot see what was read.
The Aggregate Risk
When an agent holds tokens for multiple services, cross-service attack chains emerge. A concrete sequence: an attacker embeds instructions in a Notion page. A user queries Computer using both Slack and Notion as sources. The injected instruction executes, directing the agent to exfiltrate DM content via chat:write. Every API call used authorized tokens.
This satisfies Willison's lethal trifecta. It also mirrors EchoLeak (CVE-2025-32711, CVSS 9.3) - a zero-click M365 Copilot attack confirming the pattern applies to any system meeting the trifecta conditions.[^26]
Where IAP Stops and OAuth Starts (Tier 1 and 3)
I wrote about IAP as a strong perimeter control for Cloud Run. It is. But IAP does not protect against access that never touches it.
IAP intercepts inbound HTTPS requests to a Cloud Run service and checks for a valid Google identity.[^21] An agent holding a Gmail token calls gmail.googleapis.com directly - outside the GCP request path entirely. Token audiences are separate: Gmail tokens carry aud=gmail.googleapis.com, IAP tokens carry the IAP client ID. These are separate authorization universes.
I run Bevis and Trellis behind IAP, and my inbox holds deployment notifications from both: service URLs, configuration notes, alert triggers. If an attacker compromised a Computer session that held my Gmail token, IAP would log nothing. The session reads the inbox over OAuth, the inbox yields a service URL and a credential, and the attacker then walks in through IAP as a fully authenticated user.
The March 2026 --iap flag closed the gap where run.app URLs were previously unprotected.[^22] It changed nothing about OAuth API calls to external services.
Obsidian Security states it directly: "Traditional perimeter defenses don't inspect the authorization layer where tokens operate."[^24a] SquareX confirmed that SASE, SSE, and EDR solutions cannot differentiate agent API calls from user calls.[^24]
The Prompt Injection Evidence Layer (Tier 3)
The attack surface is documented, not theoretical.
CometJacking (LayerX, October 2025). A single malicious URL hijacked Comet, read Gmail and Calendar data, Base64-encoded the payload to bypass exfiltration detection, and POSTed it to an attacker-controlled server. No new OAuth grants required. All pre-existing authorized permissions.[^25] Perplexity downplayed the finding. Bruce Schneier covered it independently.[^31]
Zero-click Drive wiper (Straiker, December 2025). Crafted email with "cleanup" instructions. Benign user prompt. Agent deleted Drive files without confirmation. Google: "won't fix."[^16]
EchoLeak (CVE-2025-32711, CVSS 9.3). Zero-click M365 Copilot attack. Crafted email retrieved by Copilot's RAG system. Injected instructions executed across the user's full M365 environment. Used RAG spraying for reliable retrieval.[^26]
Trail of Bits pre-launch audit. Before releasing Comet, Perplexity hired Trail of Bits. They found four prompt injection techniques that extracted private Gmail data.[^32] Perplexity launched anyway.
OpenAI Codex token injection. Branch name injection in Codex allowed shell command execution and exfiltration of the agent's own GitHub OAuth token - inheriting all cross-service permissions.[^27]
OWASP ranks prompt injection #1 among LLM risks (2023 and 2025 editions). Meta-analysis: 66.9% to 84.1% success rates in agentic systems with auto-execution.[^6]
"AI Proposes, Humans Verify" vs. Autonomous Execution
I wrote in Article 03 that AI multiplies thinking, not judgment. The rule: AI proposes, humans verify. Agentic AI tools skip that step by design.
The value proposition of Perplexity Computer is autonomous execution: give it a goal, it figures out the steps, it completes them. The authorization model is equally autonomous. Once you grant a connector, the agent acts on those grants without per-action confirmation.
The "AI proposes, humans verify" rule holds for tasks producing documents or analysis. It breaks when the agent executes write operations against live systems. Pushing a file to GitHub, sending a Slack message as you, editing a calendar event - these state changes happen before you see them.
Obsidian Security found that 90% of AI agents hold ten times more privilege than their tasks require.[^28] That over-provisioning is a choice, not an accident: broad scopes make setup frictionless, and the cost only comes due during an incident.
The mental model that changed how I grant these: treat every connector as a long-lived service account, holding exactly the permissions you approved, sitting on a third party's server, live until you revoke it or the provider cuts it off.[^29] Once you picture it that way, you authorize far less.
This piece covers the connector and OAuth-scope perimeter. The memory-layer version of the same problem - untrusted content that reaches an agent through its own retrieval store rather than a connector - needs a structural fix, which I work through in The Trust Boundary Lives in Your Vector Store, Not Your Prompt.
What I Plan to Test Next
The following items are in my testing queue. I will document findings in separate articles.
- GitHub organization connector. The
admin:orgscope's implications for org membership enumeration need first-person verification against a controlled organizational environment. - Slack connector scope behavior. Does the bot hold 19 scopes against all channels after a single workspace install, or does access require explicit per-channel authorization?
- Prompt injection via Notion. Can a crafted instruction in a Notion page influence Computer's behavior when Notion is selected as a source?
- Token persistence across sessions. Does Perplexity re-request the OAuth token per session, or persist it server-side? The latter is more dangerous.
- IAP log correlation. Instrument IAP logs on Bevis and Trellis to confirm that a Computer session with Gmail access generates zero IAP events - the one piece of first-person evidence the architectural claim is still missing.
References
[^1]: He, W., et al. (2018). "Email as a Master Key: Analyzing Account Recovery in the Wild." IEEE INFOCOM 2018. https://www.eecis.udel.edu/~hnw/paper/infocom18a.pdf
[^2]: GitHub Documentation. "Token expiration and revocation." https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation
[^3]: Okta. "AI Security: When Your Agent Crosses Multiple Systems." https://www.okta.com/blog/ai/ai-security-agent-cross-system-trust/
[^4]: Willison, Simon. "Lethal Trifecta" framework. Referenced in LayerX Security, CometJacking research. https://layerxsecurity.com/blog/cometjacking-how-one-click-can-turn-perplexitys-comet-ai-browser-against-you/
[^5]: LayerX Security. "CometJacking: How One Click Can Turn Perplexity's Comet AI Browser Against You." October 2025. https://layerxsecurity.com/blog/cometjacking-how-one-click-can-turn-perplexitys-comet-ai-browser-against-you/
[^6]: ArXiv. "Security Threat Modeling for Emerging AI-Agent Protocols." https://arxiv.org/html/2602.11327v1
[^7]: CrowdStrike. "CrowdStrike and Perplexity Partner to Deliver Enhanced Security for Comet Enterprise." March 2026. https://www.crowdstrike.com/en-us/press-releases/crowdstrike-perplexity-extend-enterprise-grade-security-to-comet-enterprise/
[^8]: Perplexity Help Center. "Github Connector for Enterprise." https://www.perplexity.ai/help-center/en/articles/12275669-github-connector-for-enterprise
[^9]: GitHub Documentation. "Scopes for OAuth apps." https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps
[^10]: GitHub Community Discussions. "Read-Only OAuth scope for private repos." https://github.com/orgs/community/discussions/7891
[^11]: Builder.io. "Perplexity Computer Review: What It Gets Right (and Wrong)." 2026. https://www.builder.io/blog/perplexity-computer
[^12]: GitHub Documentation. "Differences between GitHub Apps and OAuth apps." https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps
[^13]: Legit Security. "Latest GitHub OAuth Tokens Attack Explained." April 2022. https://www.legitsecurity.com/blog/latest-github-access-token-attack-explained-and-how-to-protect-yourself
[^14]: Perplexity Help Center. "Connecting Perplexity with Gmail and Google Calendar." https://www.perplexity.ai/help-center/en/articles/12168040-connecting-perplexity-with-gmail-and-google-calendar
[^15]: TechCrunch. "For Privacy and Security, Think Twice Before Granting AI Access to Your Personal Data." July 2025. https://techcrunch.com/2025/07/19/for-privacy-and-security-think-twice-before-granting-ai-access-to-your-personal-data/
[^16]: Straiker STAR Labs. "From Inbox to Wipeout: Perplexity Comet's AI Browser Quietly Erasing Google Drive." December 2025. https://www.straiker.ai/blog/from-inbox-to-wipeout-perplexity-comets-ai-browser-quietly-erasing-google-drive
[^17]: Perplexity. Privacy Policy. https://www.perplexity.ai/hub/legal/privacy-policy
[^18]: Perplexity Help Center. "Using Perplexity in Slack." https://www.perplexity.ai/help-center/en/articles/14016915-using-perplexity-in-slack
[^19]: Perplexity Help Center. "Using the Connector for Slack." https://www.perplexity.ai/help-center/en/articles/12167980-using-the-connector-for-slack
[^20]: Perplexity Help Center. "Connecting Perplexity with Notion." https://www.perplexity.ai/help-center/en/articles/12167654-connecting-perplexity-with-notion
[^21]: Google Cloud Documentation. "Identity-Aware Proxy overview." https://docs.cloud.google.com/iap/docs/concepts-overview
[^22]: Google Cloud Blog. "IAP integration with Cloud Run." March 2026. https://cloud.google.com/blog/products/serverless/iap-integration-with-cloud-run
[^23]: Notion Developers. "Authorization Guide." https://developers.notion.com/guides/get-started/authorization
[^24a]: Obsidian Security. "Consent Phishing: How OAuth Attacks Bypass MFA and Traditional Security Controls." February 2026. https://www.obsidiansecurity.com/blog/consent-phishing-how-oauth-attacks-bypass-mfa-and-traditional-security-controls
[^24]: SquareX. "SquareX Shows AI Browsers Fall Prey to OAuth Attacks." October 2025. https://www.prnewswire.com/news-releases/squarex-shows-ai-browsers-fall-prey-to-oauth-attacks-malware-downloads-and-malicious-link-distribution-302578513.html
[^25]: LayerX Security. "CometJacking." October 2025. https://layerxsecurity.com/blog/cometjacking-how-one-click-can-turn-perplexitys-comet-ai-browser-against-you/
[^26]: ExploitOne. "The Invisible Breach: How AI Agents Became the Most Dangerous Attack Surface of 2025-2026." https://www.exploitone.com/cyber-security/the-invisible-breach-how-ai-agents-became-the-most-dangerous-attack-surface-of-2025-2026/
[^27]: ExploitOne. "The Invisible Breach." https://www.exploitone.com/cyber-security/the-invisible-breach-how-ai-agents-became-the-most-dangerous-attack-surface-of-2025-2026/
[^28]: Obsidian Security. "AI Agent Market Landscape." October 2025. https://www.obsidiansecurity.com/blog/ai-agent-market-landscape
[^29]: Oso. "OAuth Isn't Enough for Agents." https://www.osohq.com/post/oauth-isnt-enough-for-agents
[^30]: Product Growth Newsletter. "Perplexity Computer Guide." https://www.news.aakashg.com/p/perplexity-computer-guide-product-managers
[^31]: Bruce Schneier. "Prompt Injection in AI Browsers." November 2025. https://www.schneier.com/blog/archives/2025/11/prompt-injection-in-ai-browsers.html
[^32]: Trail of Bits. "Using Threat Modeling and Prompt Injection to Audit Comet." February 2026. https://blog.trailofbits.com/2026/02/20/using-threat-modeling-and-prompt-injection-to-audit-comet/