Can declining a malicious calendar invitation stop the attack?

Declining may remove one retrieval path, depending on the calendar product and assistant behavior. It is a user action rather than a dependable security boundary. Some systems may retain declined events and process invitation text before a response, or retrieve event data through another connected surface. Test the exact product state with a synthetic invitation and inspect the request assembled for the model. The control should rely on source trust and least privilege, plus action authorization and evidence instead of assuming that an RSVP state strips the content from every assistant workflow.

Is a calendar invite attack different from ordinary indirect prompt injection?

The model-level mechanism is the same: attacker-controlled content enters context through retrieval. Calendar infrastructure makes the delivery path operationally distinct. Events carry organizer identity and recurrence, plus attendee comments and conference data, along with attachments. They can arrive before the user opens an assistant, then surface during routine questions about meetings. That combination gives security teams a concrete source object to label and test, then trace. The dedicated review artifact follows the event into the request and any resulting action.

Can a gateway block every malicious instruction in an event?

No classifier provides a complete guarantee against prompt injection. A gateway can classify routed content and attach provenance to policy, restrict destinations and inspect responses, then produce an independent decision record. The larger containment design limits what follows a missed detection. Calendar ACLs constrain source access. OAuth scopes restrict application authority. Human approval protects consequential actions. Browser and endpoint controls cover activity outside the routed HTTP model call.

What should security teams preserve after a suspected event-based injection?

Preserve the event identifier and organizer, plus the relevant update history and attachment identifiers, along with calendar audit entries. Collect the assistant run ID and model request correlation value, plus the source trust label and policy version, along with the decision and any response treatment. Retrieve connector or browser records for actions that followed. Protect copied event text as potentially sensitive evidence and record who can access it. This set lets investigators reconstruct the handoff without pretending that one log observed the calendar and model systems plus the endpoint at once.

Calendar Invite Prompt Injection: Treat Event Text as Untrusted Input

A calendar invite becomes a prompt-injection carrier when an AI assistant retrieves its title and description plus attendee comments, conference notes, links, or attachments and places that text beside the user's request. The attacker only needs a path into the event. The malicious instruction fires later, when the assistant answers a question about the day or acts on the user's behalf. Retrieval activates the payload before acceptance matters.

TL;DR

Treat event text and attachments from external organizers as untrusted data before an assistant receives them.
Bind every model call and proposed action to the user and source event, plus the policy version and destination.
Require fresh authorization for consequential actions instead of inheriting the assistant's broad session permissions.
Keep browser and calendar controls separate from endpoint and application policy on customer-routed HTTP model calls.

The invitation reaches the model through retrieval

The Google Calendar Events API shows why an event is richer than a date and title. An event resource can contain a description, location, attendee comments, conference notes, links, and file attachments. An assistant that answers "What should I prepare for tomorrow?" may retrieve several of those fields and add them to a model request.

Researchers behind Invitation Is All You Need demonstrated the attack against Gemini-based assistants using calendar invitations and emails, along with shared documents. Their threat model starts with an attacker sending a resource to the victim's account. The resource carries an indirect instruction. Retrieval then moves attacker-controlled text into the assistant's context, where it can redirect later behavior.

A calendar view can look harmless: a blue meeting block and a 10:30 start time, plus a familiar company name and two lines hidden below the fold. The model reads the whole description even when the user never expands it.

Calendar content needs a trust label

Calendar systems already know useful provenance. They know the organizer and attendee response, plus the event owner and update time, along with attachment identifiers. The assistant should preserve that provenance when it builds the model request. External organizer content deserves a lower trust level than text authored by the signed-in user. A forwarded event needs its original source retained as well.

The OWASP LLM01 prompt-injection guidance describes indirect injection as instructions arriving through external sources such as websites or files. OWASP recommends identifying external content and limiting the model's privileges. Those controls apply directly to event descriptions and attachments.

I would reject a design that strips source metadata before prompt assembly. Once an event description becomes an unlabeled paragraph inside the context window, the policy layer loses the strongest fact it had: an external party supplied those words. Our indirect prompt injection guide covers the broader retrieval pattern. Calendar systems provide unusually clean provenance, so throwing it away is a choice.

Action authorization contains the blast radius

An injected event becomes dangerous when the assistant can turn model output into an action. Sending mail, changing another event, opening a link, starting a meeting, or invoking a connected application each crosses a separate authorization boundary. The assistant's ability to read a calendar entry should never imply permission to perform all available actions.

Use a per-action decision. Bind it to the authenticated user and the initiating request, plus the source event and requested operation, along with the destination. Low-risk read operations can proceed under narrow scopes. Deleting an event or sharing information outside the tenant should require a fresh policy decision. High-consequence operations need human approval in the application that owns the action.

Product boundaries divide the controls. Calendar ACLs and OAuth scopes belong to the calendar platform. Browser page loads and local clicks belong to the browser or endpoint layer. DeepInspect can evaluate a deliberately routed HTTP model request and response. It cannot repair an overbroad Calendar API token or govern a local click that bypasses the model route.

A production test should start with a synthetic event

Create a test principal and send it an invitation from an external test account. Put a visible marker such as CAL-PI-042 in the description alongside a benign instruction that conflicts with the user's later request. Add a harmless attachment with the same marker. The payload should never ask the system to expose real data or perform a damaging action.

Ask the assistant to summarize the day's events. Then ask it to prepare a permitted follow-up. The test record should show which event fields entered the prompt and the event's trust label, plus the authenticated principal and model route. It should also show the proposed action and applied policy, plus the approval state and destination, along with the final outcome.

Repeat the run after removing the source label. The application should fail according to its documented design rather than silently treating the event as trusted. Run another case with a direct provider route blocked, since a hidden fallback can bypass the control under test. AI agent red teaming explains how to extend this replay across other retrieved sources without turning one calendar test into a claim about the whole agent.

The incident record joins the event to the decision

A useful audit record needs the calendar event identifier and organizer domain, plus the retrieval time and content trust label. It also needs the user or agent identity and model destination, plus the policy version and decision, along with a correlation value for any downstream action. Sensitive event text can be redacted or represented by protected evidence according to retention policy.

Application logs alone often split this timeline. The calendar service records retrieval. The model provider records a call. A connector records an action. Investigators then try to align three clocks after the event. A request-level correlation value gives those records a shared spine. The signed AI audit log guide describes the integrity requirement for the model decision itself.

Keep claims bounded to the evidence. A gateway record can prove that a routed model request carried content from event CAL-PI-042 and received a policy decision. Endpoint telemetry must prove a local browser action. Calendar audit data must prove an event change. One control plane should never claim custody of the gateway and endpoint records plus the calendar evidence.

DeepInspect

DeepInspect inspects authenticated HTTP traffic that an application deliberately routes between a user or agent and an LLM. For a calendar assistant built on a customer-controlled model route, the application can attach event provenance and acting identity, plus the requested destination and workflow context. DeepInspect evaluates that request against versioned policy before it reaches the model, then applies response policy and records the decision.

Calendar permissions and OAuth tokens remain outside that request boundary, along with local browser actions and provider-hosted assistant sessions. Those controls stay with the systems that own them. The DeepInspect record covers the routed model decision and gives incident responders a correlation point for the adjacent logs.

Book a demo today.