In The Privileges I Gave Away (Article 09) I documented the sixteen OAuth scopes I granted when I connected Perplexity Computer to my GitHub account. Delete repos. Modify GitHub Actions. Add SSH keys. The scope list read like a penetration test wishlist. I wrote it up, published it, and then stared at the question every security practitioner asks after a finding: now what?
This article is the answer. Not a vendor evaluation. A containment procedure I built and tested.
The Scale of the Problem
Non-human identities outnumber human identities by 8.6 to 1 in the average enterprise.[^1] CyberArk research puts some environments at 45 to 1.[^1] DoControl's 2026 analysis found that 70% of SaaS activity originates from non-human identities.[^2] Forty percent of Google Drive events come from NHIs indistinguishable from human behavior in audit logs.[^2] These tokens sit outside the perimeter controls most organizations rely on. SASE, SSE, and EDR cannot differentiate an agent's API calls from a user's.[^3]
I needed a procedure. I built one around four phases: Audit, Scope, Monitor, Respond. Each phase leads with what to do. Tooling enters only where it accelerates or automates a step.
The Four Phases
Audit starts with enumeration. I walked my GitHub grants, catalogued every scope, and used enterprise SaaS-discovery controls to surface shadow AI integrations outside the expected inventory. You cannot scope what you have not inventoried.
Scope reduces each grant to its minimum viable permission set. Where the platform allows it, restrict. Where it does not - GitHub still offers no read-only scope for private repositories - make a conscious risk acceptance or remove the connector.
Monitor establishes behavioral baselines and alerts on anomalies. In an enterprise environment, I validated agent-inventory, SaaS-discovery, and automated-response controls against representative connector activity. The transferable point is the control pattern, not a particular vendor stack.
Respond defines the playbook for when a token is compromised. Revoke, assess blast radius, re-grant with tighter scope, and document the gap that allowed it.
What the Framework Cannot Solve
Containment reduces exposure. It does not eliminate the structural risks underneath. No platform can assert what an agent intended - only what it did. No tool blocks an OAuth API call inline before it executes. GitHub still bundles read and write into a single repo scope. These gaps are architectural, not operational. They remain open until the protocols change.
The honest position: this framework limits blast radius and speeds detection. It does not make agentic AI connectors safe. It makes them manageable.
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 or validated as a control class in an enterprise environment |
| 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. |
Phase 1: Audit What You Granted
The first step is enumeration. Before restricting anything, build a complete inventory of every OAuth grant, API key, and service account token that touches an AI agent.
The GitHub Walkthrough (Tier 1 - Operational)
I started with my own account. Navigating to github.com/settings/applications revealed Perplexity Computer's OAuth App with the sixteen scopes from Article 09.[^4][^5] The full list:
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
Each scope carries a grant date but no last-used timestamp at the user level. GitHub's audit log (enterprise only) records API calls, but personal accounts lack this visibility. I had no way to confirm which scopes Perplexity had actually exercised without inspecting server-side logs I do not control.[^6]
Shadow AI Discovery (Tier 1 - Operational)
A personal audit covers one account. Organizational exposure requires a different approach. In an enterprise environment, I validated the SaaS-discovery control class against representative integrations. Controls in this category identify shadow AI integrations that bypass expected approval paths and show what classes of data flow to them without depending entirely on endpoint telemetry.
The validation surfaced integrations outside the expected inventory. That is the point. You cannot govern what you have not inventoried.
Manual Audit Endpoints
Every practitioner should check these URLs as a starting point:
- GitHub: github.com/settings/applications - lists all authorized OAuth apps and their scopes
- Google: myaccount.google.com/permissions - lists all third-party apps with access to your Google account
- Slack: Workspace Settings > Manage Apps - lists installed apps and their permission scopes
- Notion: Settings & Members > Connections - lists connected integrations
Audit Deliverable
The output of Phase 1 is an inventory table with these columns for every grant:
| Field | Purpose |
|---|---|
| Service | Which SaaS app the token accesses |
| Connector/App | Which AI tool holds the token |
| Scopes granted | Full list of OAuth scopes |
| Grant date | When the user authorized the connection |
| Last confirmed use | Most recent evidence of the token being exercised |
| Owner | Which user or service account authorized it |
| Risk tier | Initial classification based on scope breadth |
If you cannot fill every column, that gap itself is a finding.
Phase 2: Scope to Least Privilege
With the inventory complete, evaluate each grant against its minimum viable permission set.
The Decision Framework
For every entry in the audit table, answer three questions:
What does the connector actually need? Map the stated use case to the minimum scopes required. Perplexity Computer reads code and creates PRs. That requires read access to repositories and write access to branches. It does not require
delete_repo,admin:public_key, orworkflow.[^4]Does the platform allow restriction? GitHub's OAuth model bundles read and write into the single
reposcope. No read-only variant exists for private repositories.[^8] Google'sgmail.modifyis the second-most permissive email scope - no narrower option covers both read and compose.[^9] Some scopes cannot be reduced without breaking the integration.Accept, restrict, or remove? Three outcomes per grant:
- Accept: The risk is understood, documented, and within tolerance. Proceed with monitoring.
- Restrict: Narrow the scope, move to a less-permissive connector type, or limit to a non-sensitive account.
- Remove: The risk exceeds the value. Revoke the grant.
What I Chose (Tier 1 - Operational)
I kept the GitHub connector on my personal jrehagen account only. I did not connect it to any organizational GitHub instance. I did not connect Gmail to my production account. The connector's consent screen bundles gmail.modify with calendar, contacts, and directory scopes. That blast radius exceeds my risk tolerance without inline monitoring I do not yet have.[^10]
I run Bevis and Trellis behind IAP on Cloud Run. Connecting Gmail to an agent creates an indirect path to those services. My inbox contains deployment notifications, service URLs, and configuration details. IAP does not see Gmail API calls. That bypass path is documented in Article 09.[^11]
Where Tooling Supports This Phase (Tier 3 - Architectural Analysis)
Token Security's NHI lifecycle management ties non-human identities to infrastructure-as-code for auditability, automates key rotation, and enforces least-privilege policies.[^12] Obsidian Security's Integration Attestation adds cryptographic proof to API requests, verifying that calls originate from legitimate integrations rather than stolen bearer tokens.[^13] Both address the "restrict" path at scale. Neither solves the structural scope limitations in GitHub or Google's OAuth models.
Phase 3: Monitor the Token Surface
Scoping reduces the blast radius. Monitoring detects when something inside that radius moves wrong.
CrowdStrike Falcon Shield (Tier 3 - Architectural Analysis)
CrowdStrike positions Falcon Shield as an AI-agent visibility layer for SaaS environments. It inventories agents such as Copilot, ChatGPT Enterprise, Agentforce, and Gemini Enterprise; maps each to its human creator; and flags overprivileged configurations.[^14][^15]
The operational differentiator in CrowdStrike's published design is Falcon Fusion SOAR automation. When Falcon Shield detects anomalous agent behavior, Fusion can execute a response playbook - suspend the agent, notify the security team, preserve the evidence. This runs in near-real-time, closer to inline blocking than inventory-only approaches.[^14]
The constraint: Falcon Shield requires the Falcon ecosystem. Teams not already running Falcon for endpoint or identity pay for platform breadth they may not use.[^16]
Harmonic for Data Flow Monitoring (Tier 3 - Architectural Analysis)
Harmonic combines shadow-AI discovery with data-flow monitoring. Beyond identifying which AI tools exist, it tracks what sensitive data enters those tools and flags policy violations. When an employee pastes source code into an AI assistant or uploads a confidential document to an agent connector, Harmonic detects and alerts.[^7]
This covers a gap that token-focused platforms miss. Falcon Shield is designed to monitor what agents do inside SaaS apps. Harmonic is designed to monitor what data humans and agents push into AI tools. The two approaches address complementary parts of the problem.
Alternative Platforms (Tier 3 - Architectural Analysis)
Reco launched dedicated AI Agent Security in March 2026.[^17] It targets behavioral detection of autonomous agent call patterns across Copilot, ChatGPT Enterprise, Agentforce, Make, and n8n. Reco's Identity Interaction Graph connects behaviors, SaaS activities, and risk signals into a continuous risk model.[^18]
Obsidian Security's Knowledge Graph baselines behavior for both human and non-human identities and detects when a token behaves anomalously for its identity type.[^13][^19] Obsidian offers a free tier (up to 1,000 users) covering shadow SaaS and AI discovery.[^20]
The Async Blocking Gap
A critical limitation applies to every platform in this space: most revoke tokens or disable integrations after detection. They do not sit in the API call path to block a specific request before it executes.[^21] CrowdStrike's SOAR suspension comes closest to real-time, but latency remains. Between detection and suspension, the agent can complete additional actions at machine speed.
This gap is structural. OAuth API calls go directly to the service provider (gmail.googleapis.com, api.github.com). No intermediary inspects them in flight. Monitoring platforms observe the audit trail, not the live call.
Phase 4: Respond to Token Compromise
Detection means nothing without a response playbook. Define these steps before an incident forces improvisation.
The Revocation Playbook
When a token compromise is suspected, execute in order:
Revoke immediately. Remove the OAuth grant from the service provider's settings (GitHub, Google, Slack). Do not wait for investigation to complete. Revocation is non-destructive and re-grantable.
Assess blast radius. Determine which services the compromised token could reach. Cross-reference the scope list from your Phase 1 inventory. For multi-connector agents, every connected service is potentially affected.
Check for persistence. The
admin:public_keyscope on GitHub means a compromised session could have added an attacker's SSH key. Check github.com/settings/keys. Theworkflowscope means GitHub Actions files may have been modified to exfiltrate secrets. Review recent commits to.github/workflows/across all accessible repositories.[^5]Correlate logs. Pull audit logs from every service the token accessed. GitHub's audit log (enterprise), Google Workspace admin logs, Slack's audit API. Look for API calls outside normal patterns: bulk reads, permission changes, webhook modifications.
Re-grant with tighter scope. If the connector is still needed, re-authorize with the minimum scope set identified in Phase 2. Document the incident and the new risk acceptance.
Update the inventory. Add the incident to your Phase 1 audit table. Record what was compromised, what was accessed, and what scope change resulted.
The Attack-Path Models
Two documented incidents illustrate the response scenarios to plan for.
Token theft at scale. The Salesloft/Drift incident (August 2025) demonstrated supply-chain token compromise.[^22] A single AI vendor's breach opened Salesforce data at 700+ organizations through persisted OAuth tokens. The response required mass revocation across hundreds of tenants.
Session hijacking via prompt injection. CometJacking (October 2025) showed the single-user path.[^23] One malicious URL hijacked a Perplexity Computer session. It read Gmail and Calendar data through pre-existing OAuth grants, Base64-encoded the payload, and POSTed it to an attacker server. No new authorization was needed. The response required revoking all connected service tokens, not just the one being exploited.
IAP Log Correlation (Tier 1 and 3)
For anyone running services behind IAP: instrument your logs to confirm the bypass. I run Bevis and Trellis behind IAP on Cloud Run. A Computer session with Gmail access can read deployment emails containing service URLs. IAP would log nothing, because the Gmail API call never touches the IAP proxy.[^11] Confirming this absence in your logs validates the threat model from Article 09 and justifies the scope restrictions from Phase 2.
What Remains Unsolved
The containment framework limits blast radius and speeds detection. Five structural risks remain open, and no current tooling addresses them.
Risk 1: Intent vs. Behavior
Every monitoring platform detects anomalous behavior patterns. None can assert intent. An AI agent operating within its granted OAuth scopes but reading sensitive data for exfiltration looks legitimate until the behavioral baseline diverges.[^21] The gap: "authorized and normal-looking" is not the same as "authorized and safe." Behavioral detection catches the deviation. It cannot catch the agent that stays inside its baseline while doing something semantically harmful.
Risk 2: Async Blocking Latency
No platform blocks an OAuth API call inline before execution. Detection and revocation happen after the fact. CrowdStrike's Falcon Fusion SOAR is the closest to real-time automated response, but even near-real-time has latency.[^14] An agent operating at machine speed can complete dozens of API calls between detection and suspension. The gap closes only when authorization infrastructure supports call-level inspection, which OAuth was not designed for.
Risk 3: Structural Over-Permissioning in OAuth
GitHub still bundles read and write into repo. Google still requires gmail.modify for read-and-compose. These platforms designed their OAuth scopes before autonomous agents existed. The scopes assume a human user who needs a reasonable bundle of capabilities.[^8][^9] Until service providers ship agent-specific scope models (GitHub Apps are closer but not universal), every connector inherits more privilege than it needs. This is an upstream problem. No security platform can fix it.
Risk 4: Cross-Service Chain Reasoning
Monitoring platforms observe activity within individual SaaS applications. No platform correlates attack chains across multiple services simultaneously in real time.[^21] The cross-service scenario from Article 09 - injected instructions in Notion directing exfiltration via Slack using Gmail data - spans three authorization boundaries. Each platform sees its own slice. Obsidian's Knowledge Graph correlates identities across services, which is a step toward this.[^19] Full cross-service chain detection remains an open problem. Where the injected instruction arrives through an agent's own memory or retrieval store rather than a connector, the fix is structural, not monitoring: I work through that version of the trust boundary in The Trust Boundary Lives in Your Vector Store, Not Your Prompt.
Risk 5: Token Persistence Opacity
When you grant an OAuth token to Perplexity, the token persists on Perplexity's servers. How long? Where? Under what encryption? With what access controls? Perplexity's privacy policy prohibits using Gmail data for AI training but does not publish token retention specifics.[^24] GitHub OAuth App tokens have no scheduled expiry while in use; only prolonged inactivity, a detected leak, enterprise action, or explicit revocation ends them.[^6] The gap: you granted the credential, but you do not control - or even observe - its storage lifecycle on the vendor's infrastructure.
The Framework Mapped to the NHI Landscape
This table maps the four containment phases to the NHI platforms evaluated in my research. Each entry reflects a specific capability, not a general endorsement. Evidence tiers indicate my level of direct experience.
| Phase | Procedure | Supporting Platforms | Evidence Tier |
|---|---|---|---|
| Audit | Enumerate all OAuth grants, API keys, service account tokens | Harmonic (shadow AI discovery), Grip Security (shadow SaaS discovery), Obsidian (integration inventory) | Tier 3 |
| Scope | Reduce each grant to minimum viable permissions | Token Security (NHI lifecycle, least-privilege enforcement), Obsidian (Integration Attestation) | Tier 3 |
| Monitor | Establish baselines, alert on anomalies, track data flows | CrowdStrike Falcon Shield (agent inventory, SOAR suspension), Harmonic (data flow monitoring), Reco (AI agent behavioral detection), Obsidian (behavioral baselines) | Tier 3 |
| Respond | Revoke, assess blast radius, re-grant with tighter scope | CrowdStrike Falcon Fusion (automated suspension), AppOmni (per-app configuration control), DoControl (sensitive data access flagging) | Tier 3 |
References
[^1]: DoControl. "2026 Non-Human Identities (NHI) Report." https://www.docontrol.io/blog/2026-non-human-identities-nhi-report
[^2]: DoControl. "SaaS Activity Now Dominated by Non-Human Identities." LinkedIn, 2026. https://www.linkedin.com/posts/do-control_saas-activity-today-isnt-just-human-anymore-activity-7425194531295514624-8JMa
[^3]: 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
[^4]: Perplexity Help Center. "Github Connector for Enterprise." https://www.perplexity.ai/help-center/en/articles/12275669-github-connector-for-enterprise
[^5]: GitHub Documentation. "Scopes for OAuth apps." https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps
[^6]: GitHub Documentation. "Token expiration and revocation." https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation
[^7]: Harmonic Security. AI data protection and shadow AI discovery platform. https://www.harmonic.security/
[^8]: GitHub Community Discussions. "Read-Only OAuth scope for private repos." https://github.com/orgs/community/discussions/7891
[^9]: 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
[^10]: 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
[^11]: Rehagen, J. "The Privileges I Gave Away: When Agentic AI Meets Your Trust Boundaries." Article 09, jon.rehagen.net.
[^12]: Token Security. "NHI Lifecycle Management." https://www.token.security/product/nhi-lifecycle-management
[^13]: Obsidian Security. "Obsidian Security Announces End-to-End SaaS Supply Chain Security." January 2026. https://www.obsidiansecurity.com/news/obsidian-security-announces-end-to-end-saas-supply-chain-security
[^14]: CrowdStrike. "Falcon Shield: AI Agent Visibility, Falcon Next-Gen SIEM Integration." March 2026. https://www.crowdstrike.com/en-us/blog/falcon-shield-evolves-ai-agent-visibility/
[^15]: CrowdStrike. "How CrowdStrike Secures AI Agents Across SaaS Environments." https://www.crowdstrike.com/en-us/blog/how-crowdstrike-secures-ai-agents-pervading-saas-environments/
[^16]: Reco. "CrowdStrike Shield vs AppOmni: Comprehensive Comparison." https://www.reco.ai/compare/crowdstrike-shield-vs-appomni
[^17]: CSO Online. "Reco targets AI agent blind spots with new security capability." March 2026. https://www.csoonline.com/article/4146915/reco-targets-ai-agent-blind-spots-with-new-security-capability.html
[^18]: Reco. "Reco Launches AI Agent Security for SaaS Environments." March 2026. https://www.reco.ai/blog/reco-launches-industry-first-ai-agent-security-to-tackle-agent-sprawl-across-saas
[^19]: Obsidian Security. "Obsidian Security targets rising tide of SaaS integration threats." SiliconAngle, January 2026. https://siliconangle.com/2026/01/22/obsidian-security-targets-rising-tide-saas-integration-threats/
[^20]: Obsidian Security. "Get Started Free." https://www.obsidiansecurity.com/obsidian-security-get-started-for-free
[^21]: Obsidian Security. "The bearer token problem hidden inside your AI Agent strategy." https://www.obsidiansecurity.com/blog/the-bearer-token-problem-hidden-inside-your-ai-agent-strategy
[^22]: Okta. "AI Security: When Your Agent Crosses Multiple Systems." https://www.okta.com/blog/ai/ai-security-agent-cross-system-trust/
[^23]: 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/
[^24]: Perplexity. Privacy Policy. https://www.perplexity.ai/hub/legal/privacy-policy