Who is accountable when an AI agent processes malicious instructions embedded in a calendar invite or advertisement?

Why This Matters for Security Teams

Malicious instructions hidden inside calendar invites, documents, ads, or emails are not just a user-awareness issue. They are an agent governance issue, because the AI agent is acting with delegated authority and tool access once it ingests the content. The practical question is whether the organisation has defined which sources the agent may trust, which actions it may take, and who is responsible when the workflow is abused. That aligns with the governance emphasis in the NIST AI Risk Management Framework.

Teams often assume the problem sits with the attacker who wrote the prompt injection, but security accountability does not disappear because the attack was indirect. If an agent can read untrusted content and then trigger actions, send messages, alter records, or retrieve secrets, the operating organisation owns the risk created by that design choice. Current guidance in OWASP Agentic AI Top 10 treats this as a control failure around input trust, action gating, and tool authorization rather than a pure content moderation problem. In practice, many security teams encounter this only after an agent has already executed a poisoned instruction from a routine business message, rather than through intentional testing.

How It Works in Practice

Operationally, accountability should be split across the teams that selected the integration, approved the permissions, and monitor the resulting activity. The business owner defines the use case. Security defines the guardrails. Platform or application teams implement the controls. Governance teams verify that autonomy is acceptable for the data and actions involved. That model is consistent with the control intent found in the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where input validation, access restriction, logging, and approval workflows are concerned.

In practice, secure agent design usually includes:

• Source allowlisting so the agent does not treat every calendar item, ad, or attachment as trustworthy.
• Content inspection before retrieval or action, with explicit handling for hidden instructions and malformed payloads.
• Action gating for risky behaviours such as sending email, moving money, creating tickets, or changing records.
• Human approval for high-impact actions, especially where the agent can reach privileged systems or sensitive data.
• Logging that preserves both the source content and the triggered action for later review and incident response.

Threat modelling should also cover how the agent behaves when untrusted text is mixed with legitimate business context. MITRE’s MITRE ATLAS adversarial AI threat matrix is useful for mapping prompt injection, goal hijacking, and downstream abuse patterns to defensive tests. Where organisations are building longer-lived autonomous workflows, the CSA MAESTRO agentic AI threat modeling framework provides a practical way to reason about trust boundaries, control points, and escalation paths. These controls tend to break down when the agent is wired directly into high-trust inboxes or calendars because the system quietly inherits the trust of routine business communications.

Common Variations and Edge Cases

Tighter agent controls often increase workflow friction, requiring organisations to balance speed against the risk of hidden instructions. That tradeoff becomes visible when teams want an assistant to be “helpful” across every message source, yet also expect it to behave like a tightly governed system.

There is no universal standard for exactly where the accountability boundary should sit between the AI platform owner, the application owner, and the business sponsor, so current guidance suggests documenting responsibility in the AI governance model and incident response plan. A calendar invite injected with malicious instructions is different from a malicious advertisement, but both can become execution paths if the agent is allowed to browse, summarise, click, or act without source validation. The same is true for connected email, chat, and document workflows.

Teams should pay special attention to agents that can reach credentials, internal tools, or external APIs. If the agent has broad permissions, the issue is no longer only prompt injection. It becomes an identity and privilege problem as well, because the organisation has effectively created a software actor that can be manipulated through ordinary content. That is why the agentic security conversation increasingly overlaps with NHI governance, even when the original attack started as a simple calendar invite. The strongest design is to define which content sources are safe, which actions are reversible, and which decisions always require human confirmation.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent changes prices or processes a refund incorrectly?
• Who is accountable when an AI assistant follows malicious repository instructions?
• Who is accountable when an AI agent installs a malicious skill?
• Who is accountable when an AI agent or build pipeline introduces malicious code?