Untrusted instructions
A web page, email, or document can contain hidden instructions that try to hijack the agent.
EVALUACION DE SEGURIDAD
El riesgo es real, pero no es uniforme. Un navegador agentico se vuelve peligroso cuando paginas no confiables pueden guiar acciones con credenciales, dinero o sistemas privilegiados.
Most security failures come from a small set of conditions. If more than one appears at the same time, the risk compounds quickly.
A web page, email, or document can contain hidden instructions that try to hijack the agent.
Once the browser is logged in, a bad decision can affect real accounts and real data.
Risk rises when the agent can click submit, transfer money, change settings, or invite users.
The browser can chain multiple sites together, which expands the blast radius of one bad prompt.
The safer question is not “is it safe?” but “safe for what kind of task?”
| Workflow | Risk | Why it matters | Safer handling |
|---|---|---|---|
| Reading public articles | Low | No credentials and no side effects. | Good default use case for an agentic browser. |
| Research with logged-in tools | Medium | The agent sees more context and can touch private data. | Use isolated sessions and review outputs before sharing. |
| Filling internal forms | Medium | A wrong field or wrong destination can create business errors. | Require approval before submit and show a final diff. |
| Inbox triage or calendar changes | High | Email and calendar are powerful pivot points for attackers. | Use scoped permissions and human confirmation for every external action. |
| Payments or purchases | High | Prompt injection plus payment authority can cause immediate damage. | Never allow silent execution. Require explicit step-up approval. |
| Admin or production consoles | High | One wrong action can impact users, infrastructure, or data integrity. | Prefer read-only mode or do not delegate this flow at all. |
A safer product does not promise zero risk. It narrows what the agent can do, asks for approval at the right time, and keeps actions reviewable.
Sensitive steps such as payments, password entry, or destructive actions should pause for explicit approval.
Run automation in a separate tab group or context so it does not spill into your active browsing session.
The agent should have task-scoped access rather than broad authority over every open tab and account.
Users need a clear action log, preview, or diff before the browser commits a meaningful change.
Tabbit is built around agentic workflows, but it should still be used with judgment. The goal is safer delegation, not blind delegation.
Tabbit is designed for task execution with checkpoints instead of treating automation as invisible background magic.
High-consequence steps can be reviewed before the browser commits them.
Tabbit is especially strong for deep research, synthesis, and exploratory browsing where the value is high and side effects are low.
It can be safe for low-risk research tasks, but it becomes much riskier when it can act inside logged-in, high-privilege, or financial workflows.
Indirect prompt injection is the main risk. Untrusted content can try to override the agent’s instructions and push it toward unsafe actions.
Not exactly. Phishing tricks the user directly, while prompt injection tries to trick the model or agent through content it reads.
Not without explicit approval gates. Payment actions should always require a final human confirmation step.
Yes. Logged-in sessions give the agent real authority, which makes mistakes or adversarial content far more costly.
Public web research, summarization, comparison, note-taking, and draft generation are the safest starting points.
Yes, but only with scoped permissions, approval checkpoints, isolated execution, and a clear policy for high-risk systems.
Tabbit emphasizes supervised task execution, approval checkpoints, and a safer workflow model instead of pretending delegation is risk-free.
Use Tabbit for research-heavy workflows first, then expand carefully as your trust and policies mature.