User Scanner has evolved from a large email-and-username OSINT utility into something more consequential for AI systems: an agent-callable investigation capability. Version 1.5.1 adds native Model Context Protocol support, while the preceding v1.5.0 release introduced cross-scanning that can extract new identifiers from one result, pivot into another scan and assign confidence labels to the resulting links.
That combination matters more than the project’s current GitHub momentum. An analyst using a command-line OSINT tool normally decides whether each newly discovered handle, email address or profile is relevant before continuing. When the same capability is exposed to an AI agent through MCP, the technical question changes. The issue is no longer only “is the tool allowed to scan?” but “how far is the agent allowed to expand the investigation from the identifier it was originally given?”
Cross-scanning changes the unit of automation
The User Scanner repository describes a modular OSINT engine that checks email addresses and usernames across hundreds of public-facing services, extracts profile metadata, supports bulk scans and can export structured results. It also integrates external breach-intelligence checks and explicitly states that it operates on publicly accessible information and authorized defensive use rather than bypassing authentication or accessing non-public data.
Version 1.5.0 introduced a more important workflow change. According to the release mirror, a completed scan can feed a cross-scan that separates newly discovered usernames and email addresses into follow-up tasks, re-checks them with specialized modules and assigns confidence levels.
That means the output of one lookup can become the input to another. A profile can expose another handle; that handle can resolve to another public account; that account can expose another identifier. The system is no longer only enumerating one value against a fixed list of sites. It is building a trail.
This is useful for legitimate investigations because it reduces manual pivoting. It also creates an accuracy problem that cannot be solved by automation alone. Common usernames collide. Public profile fields may be stale, copied or deliberately misleading. A candidate match is not identity proof merely because multiple public services contain the same string.
MCP moves investigative judgment into the agent loop
In a first-person v1.5.1 announcement, a User Scanner maintainer says the release adds a native MCP server so AI clients can invoke OSINT scans directly. The announcement also describes automated recursive cross-scanning and confidence states including confirmed, likely, candidate and conflicting.
An independent sandbox review by MrKeyoor provides useful corroboration. Its test of v1.5.1 found three MCP tools for username scans, email scans and module listing, and noted that an agent can select scan modules and request cross-scans. The review also found that the MCP dependency was optional and that the project’s test run passed 375 tests before one collection error related to the missing MCP module in that environment.
The engineering implication is not that MCP makes User Scanner inherently unsafe. MCP is only the interface. The important change is that a model can now participate in the decision about what to scan next.
A human investigator may stop after discovering an unrelated account with the same username. An autonomous or semi-autonomous agent may treat the new identifier as another tool-call opportunity unless the surrounding system constrains that behavior.
Tool permission is not the same as investigation permission
This exposes a governance gap that appears in many agent systems.
Traditional agent permission models tend to answer questions such as: Can this agent call the OSINT tool? Can it access the network? Can it write a file? Those are necessary controls, but they do not define the investigative scope.
Suppose an agent is authorized to investigate identifier A. The first scan returns a profile that mentions identifier B. B leads to email C, and C produces accounts D and E. A tool-level allowlist may consider every call valid because the same approved MCP tool is being used each time. Yet the investigation may have moved far beyond the original target.
For identity-oriented tools, production governance therefore needs another control dimension: scope lineage. Each new pivot should carry the reason it was derived, its confidence level, the original authorized subject and whether expanding to it requires a human decision.
That is different from ordinary rate limiting. A depth budget can stop infinite recursion, but it cannot decide whether a particular branch is relevant, proportionate or legally justified.
Confidence scores reduce noise, not responsibility
User Scanner’s cross-scan design is directionally careful because it distinguishes confidence states instead of treating every matching username as the same person. The independent review notes that the project’s guidance recognizes collisions and warns against feeding candidate matches directly into enforcement or identity decisions.
That distinction is essential for agentic use. An agent can use confidence to prioritize evidence, but confidence should not silently become authorization.
A “likely” link may be useful for an analyst to review while still being inappropriate for automatic expansion. A “conflicting” result may be a reason to stop. A public email discovered in profile text may have a different evidentiary value from an address exposed through a structured profile field.
The safest architecture keeps these differences visible in the agent trace rather than collapsing them into one boolean “match.”
What production teams should control
If User Scanner is connected to an internal AI agent, the control plane should treat it as an investigative capability rather than a generic read-only utility.
At minimum, the system should preserve the original authorized target, record every derived identifier and why it was followed, limit recursion and scan breadth, separate low-confidence leads from verified associations and require human review before a pivot materially widens the subject of the investigation.
Network and privacy controls still matter, especially because the project supports bulk scanning and proxy use. But the harder governance problem is semantic: the agent needs rules about what it is investigating, not only what function it is technically allowed to call.
User Scanner is valuable to Aipolix readers for precisely this reason. It shows how a conventional open-source security utility changes when it becomes an agent tool. MCP does not merely make OSINT easier to invoke. Combined with recursive cross-scanning, it turns investigation scope into part of the agent runtime.
The next generation of agent governance will need to track not just permissions, but provenance: what the agent started with, what it inferred, what it discovered and why it was allowed to continue.