Who is accountable when an AI assistant turns a document into remote code execution?

Why This Matters for Security Teams

An AI assistant that can read documents and invoke tools is no longer a passive productivity layer. Once it has retrieval plus execution privileges, a single poisoned prompt, malformed attachment, or overbroad tool chain can turn content processing into code execution. The accountability question is therefore not philosophical: it is about who approved the agent’s reach, who bounded its authority, and who left secrets available to be abused. NIST Cybersecurity Framework 2.0 treats this as a governance and access control problem, not just an application defect.

That distinction matters because modern assistants often sit across document stores, ticketing systems, shells, and API bridges. If those connections are not individually constrained, the blast radius expands faster than most reviewers expect. The same pattern has shown up in NHI incidents and secret exposure cases documented by NHI Management Group, including the LLMjacking research and the State of Secrets in AppSec findings. In practice, many security teams encounter abuse only after an assistant has already chained access from a document into a shell, rather than through intentional control design.

How It Works in Practice

Accountability follows control of the enabling environment. If a team grants the assistant access to retrieval, command execution, or developer secrets, that team owns the resulting risk, even if a downstream model produced the unsafe action. The operational question is whether the agent had standing authority, whether each action was reviewed in real time, and whether the credential surface was limited to the task at hand.

For document-to-RCE scenarios, good practice is to separate four layers:

• Content access so the assistant can read only approved documents, not arbitrary file paths or whole repositories.
• Tool execution so commands, scripts, and build actions require explicit policy checks before launch.
• Workload identity so the agent authenticates as a distinct non-human identity, not as a shared human account.
• Secrets containment so tokens, API keys, and certificates are short-lived and scoped to a single task.

This is where frameworks and implementation guidance converge. NIST AI Risk Management Framework emphasizes governance, mapping, and measurement of AI risk, while NIST Cybersecurity Framework 2.0 reinforces identity, access, and monitoring discipline. For agentic systems, current guidance suggests intent-based authorization and just-in-time credential issuance rather than broad role grants. The practical goal is to make every dangerous step attributable to a policy decision, not to an opaque model output. NHIMG’s Analysis of Claude Code Security underscores why code-adjacent assistants need tighter containment than ordinary chat systems.

These controls tend to break down when the assistant runs inside a developer workstation with persistent shell access, shared environment variables, and long-lived cloud credentials because the model can pivot from document content to executable context without a clean policy boundary.

Common Variations and Edge Cases

Tighter control over AI assistants often increases workflow friction, requiring organisations to balance speed against containment. That tradeoff is real, especially in engineering teams that want autonomous drafting, testing, and deployment assistance. There is no universal standard for this yet, but current guidance leans toward separating review-only assistants from action-capable assistants.

A few edge cases change the accountability picture:

• If the assistant can only summarize documents, the primary risk is data exposure, not execution. Accountability remains with the party that exposed sensitive content to the model.
• If the assistant can trigger CI/CD, container, or script execution, the owning team must treat it like a privileged workload and enforce approval, logging, and rollback.
• If secrets are inherited from developer shells or shared orchestration layers, the problem is often not the model itself but the surrounding identity sprawl and poor secret hygiene.
• If multiple teams compose the assistant through MCP-like integrations, accountability becomes shared across platform, application, and security owners, with governance needing to be explicit in advance.

NHIMG’s reporting on the DeepSeek breach and Schneider Electric credentials breach shows how quickly exposed secrets and overexposed systems can widen impact once attackers or agents gain a foothold. The practical rule is simple: whoever approved the assistant’s execution path, credential scope, and containment boundary is accountable for the outcome.

Related resources from NHI Mgmt Group

• Who is accountable when an AI workflow turns a calendar event into code execution?
• Who is accountable when an exposed backup service is used for remote code execution?
• Who is accountable when an AI assistant surfaces private code from a cached repository?
• Who is accountable when an AI assistant memory poisoning incident affects code or systems?