top of page

Agent Reach Review: Whose Login Is Your AI Agent Using?

12 minutes ago
9 min read
A woman at her laptop looks on in surprise as her small black and tan dog trots off with the key to her login in its mouth

Giving your AI agent the internet is easy. Giving it your logins is the part to think about.


Every week someone on a client team sends me a GitHub link with the same question: "Erick, can we use this?" Lately the links are almost always AI agent tools, and the one I get most is Agent Reach. When we first looked at it on October 16, it had 97,952 stars on GitHub. As I write this on October 29, it has 106,295 (GitHub). That is a lot of people handing a new tool access to their accounts.


So we did what we do with every project in our Before You Install series. We read the repo before anyone on our team installed it, looking for nefarious prompts, risky code and anything that quietly asks for more than it should. Here is what we found, what changed since, and the four rules I would give any business owner before they try it.



Watch the short version first

If you want the quick take before the deep dive, here is our Short (under three minutes):




What Agent Reach actually is

Agent Reach is an open source Python command line tool plus an "agent skill" that gives an AI agent read and search access to Twitter/X, Reddit, YouTube, LinkedIn, Facebook, Instagram, GitHub and any web page, among others. The pitch on the repo is simple: "Give your AI agent eyes to see the entire internet," with zero API fees (GitHub).


Here is the important part. Agent Reach does not do most of the scraping itself. It picks, installs, health checks and routes to other open source tools that do. The authors describe it as "the selector, installer, health checker and router, never a wrapper" (install guide, Oct 2026 scan).


Public pages need no setup. The logged in channels are where it gets interesting, because those work by reusing your session.



Why this matters: a session cookie is a key, not a note

Think of a session cookie like the wristband you get at a concert. You show your ID once at the door. After that, nobody checks your ID again. They just look at the wristband.


When you log in to LinkedIn or Reddit, the site hands your browser one of those wristbands. OWASP, the nonprofit Open Worldwide Application Security Project, puts it plainly: once you are logged in, the session token "is temporarily equivalent to the strongest authentication method used by the application," meaning your password, your one time code, even your biometrics (OWASP Session Management Cheat Sheet).


So when a tool says "we use your existing login," what it means is "we use your wristband." Whoever holds it, or whatever holds it, is you as far as that site is concerned.


That is not automatically bad. It is just the question that matters. The real question is not what an agent can read. It is whose login it is using to read it.



The good news first

I want to be fair, because this is honestly one of the more careful projects we have reviewed. Our scan verdict was not malicious, and unusually security aware for its category.


Two coworkers reviewing open source code with a magnifying glass before anyone installs it

Here is what we verified in the files on October 16:


  • MIT license and public source. Anyone can read every line (GitHub).

  • A check only installer by default. System changes required an explicit --system flag (install guide).

  • Hard limits for the agent doing the install: no sudo without approval, no changes outside its own folder, no turning off firewalls or security settings (install guide).

  • The authors tell you, in writing, to use a secondary account, because cookie and browser session access can get an account banned and "cookies grant full account access" (install guide).

  • A clear anti scam notice: no official token, coin or crypto project (README).


We also ran our pattern checks for the usual red flags: piping a download straight into a shell, hidden instructions aimed at the AI, data sent to paste sites or webhooks, invisible characters. We found none.



The fine print we found on October 16

None of this is malware. It is about what the workflow asks of you. On the version we scanned, five things stood out.


1. The installer was a prompt. You pasted a link to a markdown file on the project's main branch into your agent, and your agent followed whatever that file said on the day it read it (README). The Python package also installed from main (install guide). Nothing was pinned. This is a new kind of supply chain risk, and it is worth understanding. OWASP lists prompt injection as the number one risk for AI applications, and notes the instructions "do not need to be human-visible/readable, as long as the content is parsed by the model" (OWASP LLM01:2025). An install file your agent obeys is exactly that kind of content.


2. Twitter setup asked you to paste cookies into the chat. The guide told the agent to ask you to export your cookies with a browser extension "and paste it to me" (install guide). The README said cookies "stay local" (README). Inside the tool, sure. But once you paste a wristband into an AI chat, it lives in that transcript and wherever that chat is stored.


3. Your real browser session became the agent's key. Reddit, Facebook and Instagram ran through a tool that "reuses your logged-in Chrome session" (README), and LinkedIn kept a saved logged in profile on disk (install guide).


4. Unpinned installs. The LinkedIn connector was set to run the @latest release on every start (install guide), and several helper tools installed globally from npm with no version (source, source). "Latest" means whatever was published most recently, by whoever controls that package that day.


5. Third party relays. Every "read this link" went through Jina Reader at r.jina.ai (source) and search went to Exa's hosted service (config). Fine for public pages. Not fine for a client portal or an internal link.



The backstory: version 1.6 shipped a week later

Here is where it gets interesting, and why I like doing these deeper write ups. On October 23, the same day our Short went live, the project released v1.6.0, which its own changelog calls "a rebuild" (release, changelog). We pulled the current code on October 29 and checked our findings against it.


What we flagged on Oct 16

What v1.6 does now (Oct 29 check)

Installer followed a file on the main branch

Installs from the latest GitHub release, and warns that a PyPI package with the same name is not this project (install guide)

Twitter cookies pasted into the chat

No cookie paste in the current docs. Logins happen in the tool's own browser, and the README says "Never paste keys into a chat" (README)

Helper tools on "latest"

Tools with a tested version stay on that version; others get the newest version in a supported range (changelog)

Agent rides your real Chrome

A dedicated browser, but a site's login is copied once from your Chrome if it is connected (skill file)

Reads and searches go to outside services

Still true: r.jina.ai and mcp.exa.ai (source)


That is real progress, and credit to the maintainers for it. The README now also says the tool is read only: it "never posts, comments, likes or sends messages" (README).


But look closely at row four. The login question did not go away. It moved.


A dog wearing a copy of a man's green wristband gets waved through the door while the man who owns the band looks on, the way a session cookie works

The current README says it directly: "The reused login is usually your main account" (README). A code comment in the session reuse module goes further: "The user removed the dedicated-only policy. Use existing connected browsers, then saved Reach state, before requesting a human login" (source).


Two more numbers from the changelog worth knowing. Before release, 28 of 40 actions passed real acceptance testing, and the ones that shipped untested include LinkedIn, Reddit and Instagram (changelog). I appreciate that they wrote that down. Most projects do not. It also tells you the logged in channels are the newest, least tested part of the tool.



Deeper analysis: read only is not risk free

"Read only" sounds harmless. Here is why I still treat it carefully.


Reading as you is still you. A read only agent on your LinkedIn sees what your account sees: your feed, your connections' posts, and anything shared only with your network. If that agent is also reading web pages that someone else wrote, those pages can carry instructions the agent follows. OWASP calls the result "Excessive Agency," and names its root causes: "excessive functionality; excessive permissions; excessive autonomy" (OWASP LLM06:2025). Your main account login is the permissions part.


Ban risk is business risk. The authors themselves warn that platforms may restrict or ban accounts used for automation (install guide, README). If that account is your company LinkedIn page admin, or the profile you use to sell, losing it is not a tech problem. It is a revenue problem.


"Latest release" is better than "main," but it still moves. The industry habit for anything that runs with your permissions is to pin to an exact version. GitHub's own hardening guide recommends pinning to a full length commit SHA so a bad actor cannot quietly swap what you run (GitHub Docs). The same logic applies to an install link your agent follows.


Outside services see your links. Jina Reader and Exa are legitimate services, and for public pages this is a reasonable design. But the URL itself can be sensitive. A link to a shared client folder, a private document, or an internal dashboard is information. Know where it goes before your agent sends it. You can read their terms at Jina and Exa.



How to try it without handing over your keys

Two coworkers holding a four item checklist with every box checked, next to a locked laptop

If your team wants to try Agent Reach, these are the four rules we use, updated for v1.6:


  1. Use a dedicated account for every platform you connect. Never your main LinkedIn, never a company admin account. On v1.6, before first use, make sure the browser extension is not connected to the Chrome profile where your main accounts live, so there is nothing to copy. Then sign in to the dedicated account yourself in the tool's own window. Per the project's session notes, once you have logged in there yourself, it stops copying from your browser (sessions notes).

  2. Never paste cookies or keys into an AI chat. The current README agrees. Enter keys in your own terminal, or skip that channel.

  3. Install from a pinned release, not "latest." For example, the v1.6.0 release page is here. Read the install file yourself before your agent reads it, and only move to a new version after you have looked at what changed.

  4. Keep internal and client URLs away from the reader and search services. Public pages only. If a link needs a login to open, it does not belong in a third party reader.


A quick checklist for business owners:


  • Do we know which accounts each AI tool is logged in as?

  • Is any AI tool using an account that can post, pay, or administer for the company?

  • Who approves a new AI tool before it touches a work account?

  • Do we have a way to log every AI tool out in one afternoon if we need to?


If any answer is "I'm not sure," that is your starting point.



Key Points of Agent Reach

  • Agent Reach is a popular open source tool that gives AI agents read and search access to social sites and the web. It is not malicious, and it is more careful than most tools in its category.

  • Logged in channels work by reusing your session, and a session cookie is as good as your password while it is valid.

  • Our October 16 scan flagged a prompt based installer on a moving branch, cookies pasted into chat, your real browser as the key, unpinned installs, and third party relays.

  • Version 1.6, released October 23, fixed several of those, but still copies a site's login from your Chrome when connected, and the authors say that login is usually your main account.

  • LinkedIn, Reddit and Instagram shipped in 1.6 without passing release acceptance tests, per the project's own changelog.

  • Use dedicated accounts, never paste cookies, pin your install, and keep private links out of outside services.


Over one hundred thousand stars means a lot of people want this. Your logins are still your logins.



Let's talk

At Chibitek, we help businesses adopt AI tools with their eyes open: we read the code, check what each tool can reach, and set up the accounts and guardrails so your team gets the benefit without handing over the keys. Don't let a trending repo become the newest login on your company accounts. Contact us today at hello@chibitek.com or 888-585-6823 to learn how we can review the AI tools your team already wants to use.



Sources

Every claim above links to its source inline. Full list: Agent Reach repository, v1.6.0 release and changelog, install guide and README at both the scanned commit (94f06c1) and the current commit (14c2134); OWASP Session Management Cheat Sheet; OWASP LLM01:2025 and LLM06:2025; GitHub Docs secure use reference; Jina and Exa terms; Chibitek YouTube Short.


Comments


bottom of page