Targeted promptware turns Google Calendar into an AI control channel

At a glance

What this is: SafeBreach shows that a calendar invite can become an indirect prompt injection path that hijacks Gemini for Workspace agents and triggers malicious tool use.

Why it matters: This matters because AI assistants that can read mail, calendars, and home or business tools expand identity and authorisation risk into a new control plane that IAM, PAM, and NHI governance must cover.

By the numbers:

• 73% of the identified Promptware threats are classified as High-Critical risk and require the deployment of immediate mitigations.
• 17 minutes

👉 Read SafeBreach's analysis of Targeted Promptware attacks against Gemini for Workspace

Context

Prompt injection becomes materially more dangerous when the target is not just a chat interface but an assistant with connected tools, memory, and delegated access. In that setting, a malicious prompt can influence what the system says and what it is allowed to do, which turns content handling into an access control problem. The primary issue here is promptware affecting Gemini for Workspace and, by extension, the identity and permission model around the assistant.

For IAM, NHI, and agentic AI programmes, the key question is not whether an LLM can be tricked in isolation. It is whether the surrounding control plane can constrain what the assistant can invoke, which data it can reach, and when it can act without an explicit trust boundary being crossed. That is a familiar governance problem in a new runtime form, and the starting position is now atypical for any environment that still treats assistant output as low-risk text.

Key questions

Q: What breaks when an AI assistant can access private data and untrusted content at the same time?

A: When an assistant can access private data and ingest untrusted content, a small injected instruction can become a data-exfiltration path. The usual assumption that content is passive fails, because the model can interpret it as an operational command and move it into tool execution.

Q: Why do conversational AI systems create new identity and access risks?

A: Because they can combine data retrieval, decision-making, and execution in a single interaction. That collapses the gap between information access and business action, which traditional IAM and security tools were not built to manage. The result is higher exposure when the system can modify records or disclose sensitive guest data.

Q: How do teams know whether prompt injection controls are actually working?

A: Look for end-to-end visibility across prompts, retrieved content, memory, tool calls, and outputs, plus evidence that blocked actions stay blocked under realistic test cases. If the system can only be evaluated with static prompts, the controls are probably too narrow. Behaviour drift under multi-turn workflows is the signal to watch.

Q: Who is accountable when a compromised AI agent misuses delegated access?

A: Accountability usually spans the business owner of the workflow, the team that issued or approved the credential, and the vendor if a third-party integration was involved. The critical governance question is not who logged in, but who allowed the delegation chain to exist and remain valid. That chain must be documented before incidents occur.

Technical breakdown

How indirect prompt injection turns an invite into execution

Indirect prompt injection occurs when the attacker plants malicious instructions in content the model will later read as context. In this case, a Google Calendar invite becomes the delivery vehicle, and the assistant processes the text as part of its task flow. The exploit does not require model weights, jailbreak access, or traditional code execution. It exploits the fact that the assistant treats external content, user context, and instruction hierarchy as inputs that can be blended at inference time. Once the malicious instruction is in the context window, the assistant may follow it as if it were part of the user request.

Practical implication: treat calendar, email, chat, and document content as untrusted instruction surfaces, not passive data.

Agent and tool chaining create the real blast radius

The risk increases when the assistant can call tools on the user's behalf. A model that can read calendar events, modify meetings, send messages, access files, or interact with connected services becomes an orchestrator rather than a passive responder. That orchestration layer can chain actions across agents and applications, which the article describes as inter-agent and inter-app lateral movement. In practice, this means the security boundary is no longer just the model. It is the combination of the model, its tool permissions, its memory, and the delegated access behind those tools.

Practical implication: inventory every tool, permission, and delegation path an assistant can use, then constrain the blast radius of each one.

Why promptware is an identity and authorisation problem

Promptware is often described as a content attack, but the security failure is really one of trust and privilege. The assistant inherits the user's access context, then acts with delegated authority across services such as email, calendar, or home automation. That makes it adjacent to NHI governance because the assistant behaves like a software identity with runtime decision-making and access scope. Once an attacker can shape the assistant's instructions, they can redirect that authority toward spamming, exfiltration, or physical actions. The control gap is not only in detection. It is in how identity, consent, and action approval are enforced for AI-mediated workflows.

Practical implication: apply least privilege, approval gating, and scoped delegation to AI assistants the same way you would for sensitive NHIs.

Threat narrative

Attacker objective: The attacker aims to convert a trusted AI assistant into a delegated execution path for fraud, surveillance, exfiltration, and physical-world manipulation.

1. Entry begins when the attacker sends a malicious Google Calendar invite containing indirect prompt injection that the victim's Gemini assistant will later ingest as context.
2. Escalation occurs when Gemini interprets the embedded instructions, hijacks the application context, and invokes connected agents and tools beyond the user's immediate intent.
3. Impact follows when the assistant deletes events, exfiltrates emails, streams video, or triggers physical-device actions through connected services.

NHI Mgmt Group analysis

Promptware should be treated as an identity-governance problem, not just an LLM safety problem. The article shows that once an assistant can read untrusted content and act through connected tools, the core question becomes who or what is authorised to trigger those actions. That places the issue squarely in IAM, PAM, and NHI governance, because the assistant is effectively operating as a software identity with delegated scope. The practitioner conclusion is that AI security controls must be designed as access controls, not only content filters.

The new failure mode is delegated action without reliable instruction provenance. The exploit works because the system cannot cleanly separate user intent from attacker-supplied context once both sit inside the same inference flow. That creates what can be called a prompt provenance gap, where instruction origin becomes ambiguous and policy enforcement loses precision. For security programmes, this means approval, logging, and traceability need to follow the action, not just the prompt text. The practitioner conclusion is that provenance-aware controls are now a baseline requirement for agentic AI.

Inter-agent lateral movement is the right concept for this class of abuse. The article is not just describing prompt injection. It is describing movement from one agent or application boundary to another through delegated permissions and shared context. That is a familiar security pattern in a new form, and it aligns closely with how the industry already thinks about privilege propagation and trust chaining. The practitioner conclusion is that assistant-to-tool and tool-to-tool transitions need explicit security review, just like privileged service-to-service calls.

AI assistants collapse the distance between information access and physical impact. The demonstrations include email exfiltration, video streaming, and home-device manipulation, which means the same trust failure can affect digital and physical environments. That broadens the governance problem from confidentiality to operational safety and user harm. It also means that consumer and enterprise assistants should not be assessed only by model quality, but by the sensitivity of the actions they can trigger. The practitioner conclusion is to classify AI actions by impact tier before enabling them in production.

Current control thinking is still behind the attack surface expansion. Security teams often focus on prompt filtering and model guardrails, but the article shows that those controls do not solve delegated tool abuse on their own. Organisations need policy enforcement around tool access, output-to-action translation, and sensitive-action confirmation. The practitioner conclusion is that AI governance must move from conversation moderation to runtime authorisation.

What this signals

Promptware pushes AI governance into the same operational territory as privileged access control because the assistant is no longer just producing text. It is consuming external content, carrying delegated authority, and crossing application boundaries, which means the control stack must include approval gates, provenance logging, and scoped permissions. The practical signal for programme owners is that AI assistants should now be reviewed like sensitive NHIs, not like harmless interfaces.

Prompt provenance gap: security teams need a way to distinguish attacker-supplied instructions from legitimate user intent before the model acts. That means your programme should prepare for content classification, tool-call policy enforcement, and alerting on unexpected cross-app actions. Where the workflow touches high-impact services, pair policy controls with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework as governance anchors.

The longer-term signal is that attack surface is shifting from model output quality to runtime authorisation. Organisations that already manage service accounts, secrets, and privileged integrations have a useful starting point, but they must extend those controls to AI-mediated actions and inter-agent movement. Programme owners should expect more attempts to exploit trusted collaboration data as an execution channel, especially where assistants can touch email, calendar, and physical devices.

For practitioners

• Map assistant tool permissions by impact tier Catalogue every action Gemini-style assistants can take through calendars, mail, files, voice, and home or business integrations. Classify each permission by data sensitivity and potential physical or operational impact, then remove any default access that is not needed for the assistant's core purpose.
• Block untrusted instruction surfaces from becoming trusted context Treat calendar invites, shared documents, emails, and chat messages as untrusted content when they are parsed by an LLM. Add policy checks so text from outside the authenticated user session cannot override system instructions or trigger downstream tool use without validation.
• Add sensitive-action confirmations before tool execution Require explicit user confirmation before actions such as deleting events, sending messages, exfiltrating data, or controlling connected devices. Use step-up approval for any action that crosses from information retrieval into external side effects, especially where the assistant can act across multiple services.
• Log prompt provenance and tool invocation chains Record which content source introduced an instruction, which agent consumed it, and which tool executed the resulting action. Preserve this chain in security logs so investigators can reconstruct prompt injection paths and distinguish user intent from attacker-supplied context.

Key takeaways

• A calendar invite can become an execution vector when an AI assistant treats embedded text as trusted instruction.
• The real security problem is delegated authority across agents and tools, which turns prompt injection into an authorisation failure.
• Defenders need provenance controls, sensitive-action approval, and tighter tool scoping before assistant-driven workflows scale further.

Key terms

• Promptware: Promptware is malicious content designed to make an AI system carry out harmful actions through instructions instead of code. In practice, it abuses the model's obedience to context, policy text, or local project prompts to redirect legitimate tools toward theft, exfiltration, or unauthorized changes.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Tool chaining: Tool chaining is the practice of using one capability to unlock the next, such as searching for a secret, authenticating with it, and then using that access to reach another system. For AI agents, tool chaining is the mechanism that turns broad permissions into compound risk.
• Inter-agent Lateral Movement: Inter-agent lateral movement is the propagation of malicious intent from one AI agent or application boundary to another through delegated access or shared context. In practice, it means a prompt injection can escape its original channel and affect additional services or devices.

What's in the full report

SafeBreach's full research covers the technical exploit paths and proof-of-concept details this post intentionally leaves at a higher level:

• Step-by-step promptware techniques used against Gemini for Workspace web, mobile, and voice interfaces
• Detailed examples of malicious actions triggered through calendar, email, and connected-device tools
• Threat analysis and risk assessment methodology used to classify the identified Promptware threats
• Vendor response details and mitigation observations shared during responsible disclosure

👉 SafeBreach's full post covers the attack techniques, risk assessment, and vendor mitigation details behind this research.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect delegated access risk to the controls that govern modern identity programmes.