TLDR;
An AI agent that registers with a real-looking identifier is stored, billed, and modeled as a genuine customer, and you pay for it multiple times over inside your CDP. The fix is not a taller wall at the form. It is building personhood as a custom, scored signal that lives on the profile itself and then excluding marked profiles from the merge universe.
For a decade, non-human traffic meant dumb scrapers that grabbed a page and left. The new wave of AI agents is built to act: an agentic browser opens your product pages, adds to cart, fills the checkout form, and completes the purchase — the exact sequence your systems read as a high-intent human. To your CDP, an agent working through checkout is indistinguishable from a customer working through checkout, because right up to the resolved profile, it is the same.
Here is the problem these Agents present. Your CDP charges you to hold and process profiles, and a growing share of the profiles it holds belong to no human. Automated traffic is now over 53% of all web activity (Imperva’s 2026 Bad Bot Report), fraudulent or bot registrations run 20–30% of new signups and up to 42% in finance and legal, and 68% of organisations say they cannot reliably tell an AI agent apart from a human (Cloud Security Alliance). The bots that reach your database do not sit in a “suspected fraud” table. They become clean, unified, model-ready customer profiles.
How CDPs charge: Storage and Usage dimensions
- Profile entitlement. Platforms like Salesforce Data 360 count known unified individuals against a licensed limit. A record with a real, resolvable identifier — an email, a phone — becomes a known profile and consumes entitlement.
- Consumption credits. Ingestion, identity resolution processing, storage, and segmentation are billed by usage. Even a profile that never becomes “known” still burns credits every time it is ingested, matched, and stored.
The key here is the anonymous-vs-known split. A visitor with only a cookie or IP stays anonymous and largely does not count against your billed profile limit. This changes the moment this record is identified using a known indicator (email, phone etc.)
The trick to exclude AI agents records from being billed lies in attaching a personhood indicator and then adjusting the merge rulesets to explicitly ignore these from ID resolution runs.
Why current guardrails are broken
- CAPTCHA decides, at the instant of form submission, “did something human-ish clear this challenge?” It is binary and ephemeral. Once cleared, nothing about the doubt survives.
- Login / auth proves “this session holds valid credentials.” It says nothing about whether a human is behind the session, and most of what your identity graph resolves — anonymous browsing, pixel events, guest checkout, newsletter signups — never touches login at all.
- The anonymous-vs-known split decides “is there a strong identifier?” — which is a billing question, not a humanity question.
What none of them does is write a personhood signal onto the resulting profile inside the identity graph — the place where segments are built, models are trained, and bills are calculated. So the moment a signup clears the gate, the CDP holds a “known customer” with no record that its humanness was ever in question. Downstream, there is nothing to exclude on, because the doubt was thrown away at the door.
This is why bolting on more edge defence does not fix it. You can stack a harder CAPTCHA and stricter auth and still end up with the same polluted graph, because the pollution is not about how many bots reach the form — it is about the fact that the ones who get through become indistinguishable from customers the instant they are resolved.
AI agents defeat junk detection because their identifiers are real
The classic defence against junk signups is to inspect the identifier: bounce-test the email, pattern-match for gibberish, block disposable domains. That worked when a bot left xrt99zz@mailinator.com. It is failing now, and AI is the reason.
- CAPTCHA is effectively priced-in for automation. LLM agents solve CAPTCHAs at roughly 63% in benchmarks, and some bots hit 99.8% bypass on reCAPTCHA-style challenges. More to the point, agents no longer solve them in-house — they call a token farm (CapSolver, GateSolve) that returns a valid token for a fraction of a cent, while an anti-detect browser patches the fingerprint to look human. Only 2.8% of sites are considered fully protected against bot threats going into 2026.
- Agents now self-provision real mailboxes. An AI agent can register an account and stand up a working, deliverable inbox with a single API call — there are “email for AI agents” services built for exactly this. The identifier bounces clean because it is real.
- Masked-but-valid identifiers pass every check. Apple Hide My Email and similar relays hand out addresses that forward to a real inbox. They are indistinguishable from a first-party email to a deliverability test.
So the signal your junk-detection stack relies on — “is this identifier real and deliverable?” — has inverted. A real identifier used to be evidence of a real person. Now it is table stakes for a bot. The junk is no longer gibberish you can bounce; it is a clean, valid, resolvable identity that your CDP will happily unify into a profile and treat as a customer.
When it isn't a problem: agents acting for real customers
The argument has a hard boundary, and pretending it doesn’t would make it wrong.
Not every agent signup is junk. When an AI agent acts on behalf of a real user who genuinely wants the service — books the trial, completes the form, subscribes using the person’s own (or masked-but-owned) email — there is a real human with real intent behind that profile. That is not pollution. That is a new channel, and treating it as fraud would be a costly false positive: you would be blocking your own customers at exactly the moment agent-mediated buying is growing.
The distinction the graph needs to make is therefore not “human vs. automated.” It is “is there real human intent behind this identity, or not?”
- Real intent, agent-mediated: a customer’s assistant subscribes them to a service they asked for. Keep it. Real profile.
- No intent: promo and coupon abuse, scraping-with-registration, speculative or test signups, mass account creation. This is the profile you are paying to store for nothing.
This is why the answer is a score, not a block. A binary gate at the door cannot see intent. A confidence signal on the profile can carry the ambiguity forward and let each downstream consumer decide how much to trust it — which is the opposite of throwing the doubt away at submission.
Fix it in the identity layer: personhood as a scored signal
- Score, don’t block. Attach a personhood confidence value (say 0–1) to each unified profile, derived from signals the graph already sees.
- Use behavioural and technical signals, not the identifier alone: session cadence (eight product pages in twenty seconds is not a human), absence of mouse/scroll entropy, datacenter vs. residential IP, automation fingerprints, velocity of account creation from a source, and whether any downstream human action ever follows (a real customer eventually opens an email, returns, or buys; a junk profile never does).
- Let every consumer threshold on it. Segmentation excludes low-personhood profiles from ad audiences. Model training drops them from lookalike seeds. Billing and profile-count reporting discount them. The score is computed once and read everywhere.
- Make it reversible. Personhood is not a life sentence. A profile that later takes genuine human action gets its score revised upward, the same way an anonymous profile becomes known.
This is where owning your identity graph matters. If your resolution runs warehouse-native — on your own data in your own store — you can compute a personhood score from the raw behavioural signals and write it back onto the profile, because you control the ruleset and the columns. A packaged CDP that resolves identity in a black box gives you no column to write personhood into and no hook to score it; you get the vendor’s match logic and nothing else. This is the same gap that lets probabilistic matches slip through a strong-key-only platform — the resolution layer decides what you can and cannot see, and if you do not own it, you cannot add the signal that is missing.
Concede the limit honestly: a personhood score is probabilistic and will never be perfect. A determined adversary with residential proxies and human-paced automation will still score as borderline-human. But the goal is not a perfect wall — it is to stop treating obvious non-humans as full-value customers, and to carry the uncertainty forward instead of discarding it at the form. Even a coarse score beats the current state, which is no signal at all.
Closing Thoughts
None of this is a security failure. CAPTCHA, auth, and the anonymous-versus-known split all do their jobs — they just never ask “is this a person?”, and leave no mark on the profile they wave through, so non-humans get resolved into Unified Individuals and billed like everyone else. And a personhood score only helps if it lands before resolution: flag the record early and it stays cheap raw events; score it after the ruleset runs and you’ve already bought the profile. So the question isn’t how tall to build the wall at the form — it’s whether you can see your own non-human tax, and whether you gate it upstream before identity resolution counts it. Personhood belongs on the identity, decided before the profile is counted, not on the login page.
Where to go next
If you are working out where personhood should sit in your resolution logic, start with how identity resolution is actually staged — deterministic keys, probabilistic matching, and the confidence scoring a personhood signal would plug into. Our identity resolution pillar walks through that architecture end to end, and it is the right next read before you decide what to score and where to write it back.
Proof of Personhood Identity Resolution — FAQ
How is personhood scoring different from ordinary bot detection?
Bot detection makes a block-or-allow decision at the edge — the form, the WAF, the login — and does not persist anything onto the customer record. Personhood scoring runs at identity-resolution time and writes a confidence value onto the unified profile itself, so segmentation, model training, and billing can each read it. Detection keeps bots out; scoring stops the ones that get through from being treated as full-value customers.
Don't CAPTCHA and email verification already handle this?
They handle the crude cases and increasingly little else. AI agents pass CAPTCHAs at high rates or buy valid tokens from solving services for cents, and they now register with real, deliverable mailboxes — including masked relays like Hide My Email — that pass bounce tests and disposable-domain checks. Both defences inspect the moment of signup, not the identity over time, so a valid-looking bot clears them and lands in your graph as a customer.
How much of a typical CDP's profile base is likely non-human?
There is no single number, but the inputs are large: automated traffic is over half of all web activity, and bot or fraudulent registrations run 20–30% of new signups, higher in some verticals. The honest way to size it for your own data is to count profiles created in a period that show no human-paced session and no post-signup engagement or return. That subset is your realistic floor for non-human profiles.
Can Salesforce Data 360 flag non-human profiles today?
Not natively. Data 360 has guardrails for cost (the anonymous-vs-known split) and for match quality (confidence scoring on identity resolution rules), but neither scores whether an identity is human. An agent that registers with a real identifier becomes a known, billable profile like any other. Adding a personhood signal means computing it from behavioural data and writing it back — which is far easier when you own the resolution layer than when it runs inside a packaged black box.
How do I score personhood without blocking legitimate AI agents acting for customers?
Score, don't gate — the distinction that matters is intent, not automation. An agent acting for a real user who wants the service leaves downstream human traces: the person opens the email, returns, or buys. Weight your score toward those post-signup human actions rather than toward whether the session was automated, and keep the score reversible so a profile that later shows real intent is re-rated upward.
