What breaks when an AI agent can browse and act under a user’s identity?

Why This Matters for Security Teams

When an AI agent can browse and act under a user’s identity, the problem is not just “automation.” The agent can inherit browser cookies, SSO context, file access, and approved SaaS permissions while still being influenced by page content, email content, or retrieved documents. That combination creates a high-trust execution path for untrusted instructions, which is exactly the sort of failure pattern highlighted in the OWASP Agentic AI Top 10.

Security teams often miss that the risk is not limited to model output quality. The real issue is delegated authority: the agent may be able to read, click, approve, transmit, or change data faster and more broadly than the human would have acted in practice. That turns prompt injection, indirect prompt injection, and malicious content into operational compromise paths rather than simple misinformation problems.

This matters most where a user session connects to email, internal portals, customer records, finance tools, or admin consoles. In those environments, a single unsafe tool call can cross a boundary that would normally require review, dual control, or step-up verification. In practice, many security teams encounter this only after an agent has already sent data, approved an action, or navigated into a sensitive workflow, rather than through intentional delegated-access design.

How It Works in Practice

In a typical setup, the agent is given browser access, session state, and tool permissions so it can complete tasks on behalf of a person. The security failure appears when the agent treats everything it sees as task-relevant, including hidden instructions inside webpages, attachments, tickets, or chat threads. A malicious page can therefore steer the agent toward leaking content, opening risky links, submitting forms, or performing actions that appear legitimate because they occurred inside an authenticated session.

Good practice is to separate human identity, agent identity, and action authority. The human may authenticate, but the agent should still operate with scoped permissions, explicit task boundaries, and controls that prevent free-form lateral movement. NIST’s NIST AI Risk Management Framework is useful here because it frames the need for governance, mapping, measurement, and monitoring around AI system behaviour rather than assuming ordinary application controls are enough.

• Restrict the agent to approved domains, tools, and data classes.
• Use step-up approval for destructive, external, or irreversible actions.
• Log prompts, tool calls, and output so investigations can reconstruct decision paths.
• Validate outputs before execution, especially when actions touch identity, finance, or admin functions.
• Assume webpages, emails, and documents are untrusted inputs, not instructions.

For threat analysis, the MITRE ATLAS adversarial AI threat matrix helps teams think about manipulation of AI behavior, while CSA MAESTRO agentic AI threat modeling framework is useful for mapping agent workflows, trust boundaries, and control points. These controls tend to break down when the agent is allowed to chain browser actions across multiple SaaS apps because the original session trust silently expands into a cross-system execution path.

Common Variations and Edge Cases

Tighter delegated-action controls often increase friction, requiring organisations to balance task speed against blast-radius reduction. That tradeoff is real, especially when users expect an agent to behave like a helpful assistant rather than a constrained workflow engine.

There is no universal standard for this yet, but current guidance suggests treating “browse and act” agents differently from read-only copilots. A read-only agent may be acceptable with content filtering and output review, while an acting agent needs stronger policy enforcement, scoped tokens, and clearer separation between user intent and machine execution. The difference is especially important when the agent can access identity workflows, because a compromised session can trigger password resets, mailbox rules, consent grants, or privileged approvals.

Edge cases matter. If the agent operates inside a VDI, a managed browser, or a hardened enterprise container, the environment may reduce exposure but not eliminate prompt injection or unsafe tool use. If the agent only summarizes content and never executes actions, the risk profile changes, but hidden instructions can still shape the summary and downstream human decisions. Where the agent handles regulated data or customer-impacting actions, teams should align governance to security controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls and, where relevant, the emerging expectations around agentic systems in the OWASP Top 10 for Agentic Applications 2026.

For NHIMG, the key distinction is simple: if the agent is acting under a user’s identity, then identity governance, action authorization, and AI input trust all collapse into the same control problem.

Related resources from NHI Mgmt Group

• What breaks when an AI SRE agent can both diagnose and act?
• What breaks when data governance is used as a substitute for AI agent identity controls?
• What breaks when AI agent data access is not tied to identity governance?
• What breaks when AI agent identity context is not preserved across sessions?