Subscribe to the Non-Human & AI Identity Journal

What breaks when an AI agent is given real user sessions and tool access?

The main failure is that a single injected instruction can inherit the user’s active permissions and convert a reading task into exfiltration, command execution, or message sending. When browser cookies, connectors, and desktop access are all in scope, the agent’s effective identity becomes the security boundary, not the model itself.

Why This Matters for Security Teams

An AI agent with live user sessions is not just “helpful automation.” It is a delegated actor operating inside a real trust context, which means prompt injection, tool abuse, and session hijacking can all collapse into one incident. That is why guidance such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework treat autonomy, permissions, and output control as risk issues, not just product features.

The practical problem is identity expansion. Once an agent can read mailbox content, open browser tabs, call APIs, or send messages, it may inherit the user’s active permissions without inheriting the user’s judgment. That creates a mismatch between what the human intended and what the system can actually do. Security teams often focus on model accuracy, but the bigger exposure is authorization drift across connectors, cookies, tokens, and desktop tooling. In practice, many security teams encounter agent abuse only after an innocuous read request has already become data exfiltration or unauthorized action.

How It Works in Practice

Real user sessions give an agent access to the same authenticated state a person would use, so the security boundary moves from the model to the surrounding identity and session controls. If a browser cookie, OAuth token, or desktop session is valid, the agent may be able to act through it unless every downstream tool enforces task-scoped restrictions, human confirmation, and content filtering. This is where the distinction between “can observe” and “can act” becomes critical.

Operationally, teams should assume the agent can be induced to follow hostile instructions embedded in web pages, documents, tickets, or messages. The MITRE ATLAS adversarial AI threat matrix is useful for mapping these attack paths, while the CSA MAESTRO agentic AI threat modeling framework helps teams separate model risk from orchestration risk. A practical control set usually includes:

  • Short-lived, scoped sessions for the agent rather than full user session reuse.
  • Tool-level allowlists and explicit deny rules for sending, deleting, purchasing, or exporting data.
  • Step-up approval when the agent crosses from read-only work into a write or external-action path.
  • Content sanitisation and instruction hierarchy checks for untrusted inputs.
  • Logging that ties each tool call to a purpose, identity, and session boundary.

Where this guidance matters most is in environments with broad SaaS connectors, remote browser automation, and desktop agents that can see multiple apps at once, because the agent can chain permissions across systems faster than a human reviewer can intervene. These controls tend to break down when sessions are long-lived and tool permissions are inherited wholesale from the end user, because the agent effectively becomes the user from the platform’s perspective.

Common Variations and Edge Cases

Tighter session scoping often improves containment, but it also adds friction, latency, and operational overhead, so organisations must balance safety against usability. Best practice is evolving here, and there is no universal standard for how much autonomy a production agent should receive before a human must intervene.

Some deployments need read access to sensitive systems, but not write access; others need bounded write access for ticket updates or customer support workflows. The right answer depends on whether the agent is handling regulated data, internal secrets, or externally exposed communications. This is where identity governance matters: if an agent is attached to a human account, the organisation should review whether that account is the right trust anchor or whether a dedicated OWASP Non-Human Identity Top 10 approach is more appropriate for credentials, tokens, and service boundaries. For teams building control baselines, the control logic should also map to NIST SP 800-53 Rev 5 Security and Privacy Controls so that access, auditability, and least privilege remain explicit.

The edge case that causes the most trouble is when the agent must act across multiple systems with inconsistent permissions, such as reading an email, fetching a file, and posting a response. In those environments, the weakest connector defines the effective security posture, not the strongest one, and that is where over-permissioned sessions become the primary failure mode.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, MITRE ATLAS, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 TBD Agentic app risks center on prompt injection, tool abuse, and unsafe action paths.
NIST AI RMF AI RMF addresses governance, mapping, measurement, and management of AI-related risk.
MITRE ATLAS TBD ATLAS models adversarial techniques against AI systems, including manipulation and abuse paths.
CSA MAESTRO MAESTRO is designed for agentic AI threat modeling across orchestration and tools.
OWASP Non-Human Identity Top 10 Agents rely on tokens and service credentials that should be governed as non-human identities.

Review every tool pathway for injection resistance, authorization checks, and user-confirmed actions.