Who is accountable when an AI assistant performs a sensitive action after DOM manipulation?

Why This Matters for Security Teams

When an AI assistant is allowed to act on what it sees in the DOM, the security boundary shifts from the model to the web page itself. That is dangerous because DOM text, labels, hidden fields, and injected prompts can be manipulated by an attacker to steer the assistant into a sensitive action. The accountability question is therefore not about blaming the model, but about whether the organisation treated the UI as untrusted input and the action as privileged.

This is the same pattern NHI Management Group highlights in incident research such as the DeepSeek breach, where exposed data and weak trust boundaries became operational risk. In practice, the problem maps to governance and control design, not just prompt quality. NIST’s NIST Cybersecurity Framework 2.0 is relevant here because it pushes organisations to define ownership, reduce ambiguity, and enforce protective controls around high-impact actions.

In practice, many security teams encounter this only after the assistant has already clicked, sent, approved, or disclosed something it should never have been allowed to decide alone.

How It Works in Practice

Accountability in these cases usually follows the control owner, the workflow owner, and the organisation that approved the assistant’s authority model. If the assistant can interpret page state and then perform a privileged action, the organisation must assume the DOM can be attacker-influenced unless it is explicitly protected. That means the action should require a separate trust decision, not just a successful UI parse.

Current guidance suggests four practical controls. First, treat page content as untrusted and separate observation from execution. Second, require step-up confirmation or policy checks for sensitive actions such as payments, sharing, deletion, or permission grants. Third, use context-aware authorization so the assistant can only act when the policy engine approves the specific request, not just the general task. Fourth, log the chain of evidence so reviewers can see what the assistant observed, what it decided, and who approved its authority.

For broader AI governance context, the State of Secrets in AppSec shows how quickly confidence can outpace actual control maturity when sensitive material is involved. The NIST Cybersecurity Framework 2.0 supports this approach by tying protection to clear control ownership and repeatable oversight rather than implicit trust in interfaces.

• Do not let a model infer intent from labels alone when the action has security impact.
• Use policy-as-code or approval gates for high-risk actions.
• Instrument the assistant so its reads, decisions, and executions are separately auditable.
• Constrain tool access so DOM manipulation cannot directly become privileged execution.

These controls tend to break down in browser-based agents that can chain multiple tools and sessions because the trust boundary becomes distributed across plugins, pages, and automated clicks.

Common Variations and Edge Cases

Tighter confirmation and policy gating often increases workflow friction, requiring organisations to balance automation speed against the risk of unintended execution. That tradeoff is especially visible when teams want assistants to complete tasks without human intervention, but the underlying page is partially adversarial or user-generated.

Best practice is evolving, and there is no universal standard for every agent workflow yet. A low-risk assistant that drafts responses is not the same as one that can submit forms, move funds, or change access rights. In higher-risk environments, accountability often depends on whether the organisation formally classified the assistant as a privileged operator and assigned a human or system owner for those decisions.

Another edge case appears when the DOM is manipulated indirectly through third-party content, embedded widgets, or hidden instructions. In those situations, the assistant may appear to “misbehave,” but the real failure is that the organisation allowed external page state to influence a privileged action path. The practical question is not whether the model was fooled, but whether the control framework expected it to be fooled and still allowed execution.

This is why NHI Management Group treats UI trust as a governance issue and not just a product issue, especially when automation crosses into sensitive actions that should have been protected by clear boundary design.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent performs an unauthorized action after injection?
• Who is accountable when an AI agent performs an unauthorized action in a SaaS product?
• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?