Who is accountable when an AI agent posts sensitive information or modifies Teams conversations incorrectly?

Accountability stays with the organisation that granted the permissions and approved the workflow. The control decision belongs to the security, compliance, and identity teams that define scopes, policies, and monitoring. If an agent is allowed to read or write in Teams, those teams must ensure there is evidence of scope limitation, redaction, and audit logging.

Why This Matters for Security Teams

When an AI agent posts sensitive information or rewrites a Teams conversation, the issue is not just a messaging mistake. It is a control failure in delegated authority, data handling, and auditability. Current guidance suggests treating the agent as an active workload with its own identity and policy envelope, not as a passive automation script. That distinction matters because agent behaviour can change at runtime, especially when prompt injection, tool chaining, or overbroad scopes are present.

OWASP’s OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework both point toward runtime governance, traceability, and human accountability. NHIMG research shows why that matters in practice: in AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope, including inappropriately sharing sensitive data. In practice, many security teams encounter the incident only after the message has already been sent, rather than through intentional policy testing.

How It Works in Practice

Accountability stays with the organisation that granted the permissions and approved the workflow, but operational ownership must be explicit. Security, compliance, and identity teams need to define what the agent may read, what it may write, and what must be redacted before any Teams action occurs. Best practice is evolving toward workload identity, short-lived tokens, and policy decisions made at request time rather than assuming a fixed role is enough. That means the agent should prove what it is, what task it is performing, and what context it is operating under.

In practice, that usually means:

• Using workload identity for the agent rather than shared human credentials.
• Issuing just-in-time, task-scoped credentials that expire automatically after completion.
• Evaluating policy at runtime with context such as channel sensitivity, message content, and destination.
• Logging every read, redact, post, edit, and delete action with enough detail for audit and incident response.
• Separating approval to execute from approval to expose content, especially in regulated or client-facing channels.

NHIMG’s OWASP NHI Top 10 and the CoPhish OAuth Token Theft via Copilot Studio analysis both reinforce the same point: if the agent can access a Teams context, it can also become a path for overexposure unless scopes are tightly constrained. This aligns with the CSA MAESTRO agentic AI threat modeling framework, which stresses tool-level control and scenario-based validation. These controls tend to break down when Teams permissions are inherited from broad group membership because the agent can inherit more reach than its task actually requires.

Common Variations and Edge Cases

Tighter controls often increase operational overhead, requiring organisations to balance rapid automation against approval, review, and monitoring costs. There is no universal standard for this yet, especially when agents must operate across multiple Teams channels, SharePoint files, or downstream apps. The practical tradeoff is between speed and containment: the narrower the scope, the lower the blast radius, but the more frequently workflows need redesign.

Several edge cases deserve special attention. First, a read-only agent can still cause harm if it summarises or republishes restricted content into a broader channel. Second, an agent that can “edit” conversations may accidentally alter meaning, retention evidence, or legal records. Third, delegated access through shared service accounts or overbroad app registrations makes root-cause analysis difficult because the action no longer maps cleanly to a single workload identity. Fourth, where message content is generated from retrieved context, redaction must happen before the model sees sensitive material, not after publication.

For this reason, current guidance suggests pairing policy-as-code with explicit human approval for high-impact posting actions. The State of Secrets in AppSec report is also relevant here: sensitive data exposure is often worsened by weak secrets discipline, and that same failure pattern appears when agents are allowed to retrieve or forward credentials, tokens, or private channel content. In environments with real-time collaboration, multi-tenant data, or compliance retention holds, even well-designed controls can fail if the workflow assumes the agent will behave like a predictable script rather than an autonomous actor.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?
• Who is accountable when an AI agent uses delegated access incorrectly?