Topic starter
23/01/2026 2:31 pm
TL;DR: Unosecur says the Google Gemini incident let malicious calendar invites use indirect prompt injection to surface private schedule data without stolen credentials, malware, or a permissions change. The control gap is contextual and intent-based governance, because authorization alone does not stop AI from combining legitimate actions into unintended data exposure.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “AI Prompt Injection & Identity Security Gaps”.
Key questions
Q: What breaks when an AI service is authorized but still unsafe to trust?
A: Static authorisation breaks down when the service can interpret untrusted language and chain legitimate actions into an unintended outcome.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts.
Q: What are the signs that prompt injection is affecting identity-controlled workflows?
A: Look for unexpected cross-system writes, summaries that contain attacker-supplied wording, output that reveals data not asked for, and action sequences that do not match the user’s intent.
Practitioner guidance
- Govern AI services as first-class identities Inventory AI systems alongside service accounts, APIs, and other non-human identities, then document exactly which systems they can read from and write to.
- Separate read and write paths for AI workflows Where possible, prevent the same AI service from both consuming untrusted content and creating externally visible records without an intermediate control point.
- Treat untrusted prompts as hostile input Apply content filtering, provenance checks, or isolation steps to calendar invites, emails, documents, and other text that an AI may parse as instructions.
Bottom line: The Gemini incident shows that AI systems can expose data while remaining inside granted permissions, which makes context a governance issue rather than a pure access-control issue.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how the malicious calendar invite influenced Gemini's reasoning path
- Unosecur's recommended visibility and behavioural monitoring approach for AI services
- Examples of context-aware oversight and audit logging for identity actions in AI workflows
- Practical guidance on reducing blast radius when AI systems can read and write across services
👉 Read Unosecur's analysis of the Google Gemini AI identity control gap →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
07/10/2026 6:01 pm
Context, not entitlement, is now part of identity governance for AI services: This incident shows that a system can be fully authorised and still unsafe if it processes attacker-controlled context. Traditional IAM proves access, but not intent, data provenance, or safe sequencing. The practitioner conclusion is that AI identity governance has to treat context as a control boundary, not a commentary layer.
A question worth separating out:
Q: How should teams govern non-human identities in AI-heavy environments?
A: Teams should govern non-human identities the same way they govern other privileged assets: assign ownership, minimise scope, rotate credentials regularly, and monitor for abnormal use. The key difference is speed. AI-driven workflows can exploit exposed access quickly, so detection and revocation must be automated and tied to lifecycle controls.
👉 Read our full editorial: Google Gemini incident shows the AI identity control gap