Fingerprint's new tools separate verified AI agents from spoofed automation

A shopping agent opens a retailer's product page to compare options for someone who intends to buy. According to SiliconANGLE, that visit may carry legitimate purchase intent, and an attacker can impersonate the same system to get past bot controls or scrape sensitive content ^[10]. The article says e-commerce and financial services firms that block both risk breaking the legitimate interaction, and firms that trust both invite scraping, fraud and impersonation ^[8].

Teams tend to assume the bot script on the page sees every visitor. But a user can ask an assistant instead, and the assistant requests the page directly, often without executing the client-side JavaScript that many security products rely on ^[5]. The article also counts that kind of assistant fetch as a possible new referral channel ^[11].

SiliconANGLE describes the release as a move from conventional bot detection to governing a web shared by humans and machines ^[13], but the products that ship are narrower and easier to test. For agents driving a browser, Fingerprint says it can cryptographically verify signed agents from OpenAI, AWS AgentCore, Browserbase, Manus and Anchor Browser ^[3]. For assistants, the check asks whether a request that calls itself ChatGPT arrives from the network its provider has published ^[6]. That check is only as current as the provider's own published list.

Both checks establish who is asking. What the request is trying to do is a separate question, and the article lists it among the things security teams now need to know ^[14]. The Automation Intelligence API, the part that works without JavaScript, is still in preview ^[15]. The article does not include a price, an accuracy rate or any measure of how much of a site's traffic comes from AI systems. Its only figures describe companies deploying agents ^[9].

In the article's example, verified assistant traffic might be fine on a public page. An unverified request using that name might not be, and neither might an agent attempting a sensitive transaction ^[12]. Put identity on one axis and the action on the other.

- Verified, public read: allow it and log it as referral traffic. - Unverified, public read: treat it as ordinary automation and rate-limit it. - Verified, sensitive transaction: let it in, and keep the account and payment checks you run on people, because the signature identifies the platform, not the person behind the request. - Unverified, sensitive transaction: block it or require a human step.

I'd switch on the assistant check for public pages first, where a wrong call costs a scrape or a lost referral. I'd leave sensitive transactions on existing rules until the API leaves preview. The tradeoff is that honest agents from platforms outside the five on the signing list ^[1] get the unverified treatment in the meantime, and some of them may be carrying a buyer. The question for Monday is how many of the four cells the current bot rule can tell apart. If the answer is one, the team is still making the block-all or trust-all choice the article describes ^[8].