OAuth-connected accounts widen the blast radius because the AI assistant may inherit access to mail, files, calendars, and other linked services. If an attacker can manipulate the assistant into executing hidden instructions, they may pivot into those connected systems without stealing credentials directly. The risk is not the protocol itself, but the trust chain created when delegated access is too broad.
Why This Matters for Security Teams
OAuth-connected accounts turn a single assistant compromise into a multi-service access problem. If an AI agent can read mail, search files, or interact with calendars through delegated tokens, prompt injection can redirect legitimate permissions toward harmful actions without cracking passwords. That changes the risk from isolated output manipulation to cross-platform abuse of trust, scope, and workflow integrity.
This matters because many teams still treat OAuth consent as a one-time onboarding step rather than an ongoing control surface. In practice, the dangerous part is not just the token, but what the token can do once the model is tricked into following attacker-authored instructions. Guidance from NIST AI Risk Management Framework and the emerging agentic security guidance from OWASP Agentic AI Top 10 both point to the same operational issue: delegated authority must be constrained, monitored, and revocable. In practice, many security teams encounter this only after an assistant has already forwarded data, approved a workflow, or exposed sensitive content through an overbroad integration.
How It Works in Practice
OAuth-connected assistants usually operate through access tokens, refresh tokens, and scoped API permissions. If the assistant is allowed to act on behalf of a user, prompt injection can persuade it to perform actions that are legitimate from the platform’s perspective but harmful from the organisation’s perspective. That can include reading messages, pulling attachments, sharing files, creating calendar events, or initiating downstream actions in integrated services.
The blast radius expands when three conditions line up: broad scopes, weak separation between user intent and model instructions, and permissive tool execution. A prompt injection embedded in a document, email, ticket, or webpage can cause the model to treat attacker content as higher priority than the user’s actual request. Once the assistant calls an API with valid delegated credentials, the result is often indistinguishable from normal use unless logging and policy enforcement are designed to detect anomalous sequences.
Practical controls usually need to sit at multiple layers:
- Minimise OAuth scopes so the assistant gets only the specific permissions required.
- Separate read-only actions from write or share actions, especially for mail and file systems.
- Require step-up confirmation for sensitive operations, even when the token is valid.
- Log tool calls, token use, and data access in a way that supports incident review.
- Validate AI outputs before they trigger external side effects.
Threat modelling should also map these paths to known abuse patterns in MITRE ATT&CK Enterprise Matrix and AI-specific injection techniques in MITRE ATLAS adversarial AI threat matrix. These controls tend to break down in highly integrated SaaS environments where the assistant can chain actions across multiple tenants and internal apps because the permission graph becomes too dense to reason about operationally.
Common Variations and Edge Cases
Tighter OAuth scoping often increases friction for users and support teams, requiring organisations to balance convenience against exposure reduction. The right answer depends on whether the assistant is merely summarising content or can take irreversible actions such as sending mail, approving access, or modifying records.
There is no universal standard for this yet, but current guidance suggests treating high-impact tools as privileged workflows rather than ordinary productivity features. That means stronger approval gates, narrower token lifetimes, and explicit policy checks before an AI agent can cross a trust boundary. The distinction matters because an assistant with read access to a mailbox may still become dangerous if that mailbox contains secrets, reset links, or social engineering lures that trigger downstream actions.
The edge cases are usually the ones teams underestimate: shared mailboxes, service accounts, delegated admin integrations, and cross-domain connectors. A model that is safe in a single-user sandbox can become risky when it inherits enterprise-wide access through a consented connector. CISA’s cyber threat advisories regularly show how attackers exploit trusted workflows rather than obvious malware. For that reason, the practical control objective is not just to block malicious prompts, but to prevent a single manipulated instruction from inheriting broad authority across connected systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF addresses governance and risk controls for delegated AI behaviour. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance covers tool abuse and prompt injection in connected assistants. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits the blast radius of delegated OAuth scopes. |
| MITRE ATLAS | AML.T0049 | Prompt injection is an AI attack path that manipulates model behaviour through inputs. |
| MITRE ATT&CK | T1078 | Valid accounts explains abuse of legitimate delegated credentials after compromise. |
Define ownership, monitor model behaviour, and manage AI risk across the full delegated-access lifecycle.
Related resources from NHI Mgmt Group
- Why do AI agents increase blast radius compared with prompt-based GenAI tools?
- Why do cloud and AI-tool credentials increase the blast radius of supply-chain attacks?
- Why do public AI workflow services increase the blast radius when a code injection flaw exists?
- Why do AI agents and connected integrations increase the blast radius of a compromise?
