Unlike a normal chatbot, an agent may be able to browse pages, use tools, access accounts and take actions on your behalf. That creates a new security problem: AI agent hijacking.
NIST describes agent hijacking as a form of indirect prompt injection where malicious instructions are placed inside data an agent processes, potentially causing unintended actions.
What an AI Agent Can Actually Do on the Web
An AI agent can potentially:
- Open and read webpages
- Navigate websites
- Fill forms and click buttons
- Access connected applications
- Call APIs
- Read information from authenticated services
- Modify content when given write permissions
The important difference is simple: a chatbot primarily gives you an answer; an AI agent can take action.
AI Chatbot vs. AI Agent
| Feature | AI Chatbot | AI Agent |
|---|---|---|
| Primary role | Answers questions | Completes tasks |
| Web interaction | Usually limited | Can browse and interact |
| Tool access | Limited or none | Can use connected tools |
| Autonomous actions | Low | Potentially high |
| Security impact | Mostly output-based | Can affect connected systems |
Think of it like this: a chatbot is an advisor telling you what button to press. An agent can potentially press the button for you.
Browser-Based AI Agents vs. API-Based Agents
Browser-based agents interact with websites through a browser environment. Depending on their design, they may operate within authenticated sessions.
API-based agents communicate directly with services through APIs and access tokens.
| Type | Main security concern |
|---|---|
| Browser agent | Session and authentication exposure |
| API agent | Token, API-key and permission abuse |
The risk depends heavily on what access the agent receives.
How Agents Interact With Websites
An agent may retrieve webpage content, interpret it and use that information to decide what to do next.
That creates an unusual security boundary: the website itself can become part of the agent’s input.
If that content contains malicious instructions, the agent could potentially interpret those instructions as something it should follow.
Tool Access and Permissions
Agents become more powerful when connected to tools such as email, cloud storage, code repositories or other applications.
But every additional tool can expand the attack surface.
OWASP calls this Excessive Agency: problems can occur when an AI system has excessive functionality, permissions or autonomy.
The basic security principle is straightforward:
Give the agent only the access it actually needs.
Agent Access to Login Credentials
An agent may operate using authenticated sessions, access tokens or API credentials.
That means a compromised agent doesn’t necessarily need to “break into” an account in the traditional sense. If it already has legitimate access, misuse of that access can become the bigger concern.
This is why credential exposure, session security and permission boundaries matter so much for agentic systems.
Session and Authentication Risks
Browser Session Hijacking
If an agent operates within an authenticated browser session, that session becomes an important security boundary.
A compromised session could potentially allow actions to be performed with the permissions associated with that session.
API Key Misuse
API-based agents introduce another concern: exposed or overly powerful API keys.
If an API key provides write access when an agent only needs to read information, the consequences of misuse can be much greater.
NIST is also examining identity, authorization, auditing and non-repudiation specifically for software and AI agents.
Prompt Injection as an Agent Security Risk
Prompt injection occurs when specially crafted content influences an AI model to behave differently from the intended instructions.
OWASP identifies prompt injection as a major AI security risk and notes that malicious instructions can come through external content, not just direct user input.
Indirect Prompt Injection Through Webpages
Here’s the important part:
- An attacker places malicious instructions in external content.
- The AI agent visits or retrieves that content.
- The agent processes the instructions as part of its context.
- The instructions influence the agent’s behavior.
- The agent may then use its available tools in an unintended way.
The malicious instruction doesn’t necessarily need to be visible to a normal visitor. OWASP notes that prompt injections can be imperceptible to humans while still being parsed by a model.
Malicious Instructions Hidden in Website Content
Potential sources include:
- Webpages
- Documents
- Emails
- Code repositories
- API responses
This is why indirect prompt injection is particularly interesting: the attacker may control the information the agent reads, rather than the agent itself.
Excessive Agent Permissions and Credential Exposure
Suppose an agent only needs to read a document but has permission to edit files, send emails and access other applications.
A malicious instruction could potentially turn that broad access into a much bigger problem.
OWASP recommends limiting agent tools and permissions to the minimum necessary.
Agent-to-Tool Security Boundaries
An important question is: Who actually authorizes an action—the AI model or the external system?
Security should not depend solely on the model deciding whether an action is safe.
Tool-level authorization, restricted permissions and logging can create a stronger boundary between the agent’s reasoning and the systems it controls.
Why Autonomous Actions Create Different Risks
A chatbot can produce a harmful answer.
An autonomous agent could potentially turn a harmful instruction into an action.
That difference matters because agents can:
- Make multiple tool calls
- Operate without constant human intervention
- Access connected systems
- Perform actions using legitimate permissions
NIST’s research highlights the growing security challenges created when agents process external data and independently act on real-world systems.
Human Approval vs. Autonomous Execution
One important security boundary is human approval.
For high-impact actions, an agent can be designed to stop and ask the user before proceeding.
However, even approval mechanisms need careful design. OWASP has documented scenarios where attacker-controlled content can potentially manipulate what a human sees during an approval interaction.
How an Agent Could Potentially Modify Website Content
If an agent has write access, a hijacked workflow could potentially result in changes to:
- Website content
- Documentation
- Code repositories
- Account settings
- Other connected services
The key word is potentially. An agent cannot modify something simply because it is an AI agent; it needs the appropriate tool access and authorization.
What Technical Evidence Would Prove an AI-Agent-Driven Compromise?
Claiming that an AI agent caused a compromise requires more than finding suspicious website content.
Useful evidence could include:
- Agent activity logs: showing what tools were called.
- Prompt/context records: showing the instructions the agent processed.
- Authentication logs: connecting the activity to a particular session or token.
- Network records: showing suspicious outbound activity.
- Application audit logs: showing exactly what changed and when.
This distinction is important for credible reporting: a suspicious AI-generated action is not automatically proof that an AI agent was hijacked.
The Bottom Line
AI-agent hijacking is fundamentally about the combination of AI reasoning + external content + tool access + permissions + autonomy.
The more an agent can see and do, the more important those security boundaries become.