Category: Security

How to Grow AI Search Visibility Without Workflow Risk

Your AI visibility report shows more citations, but your team still can’t tell whether buyers saw your name. Meanwhile, AI agents are consuming the same webpages, documents, emails, images, and transcripts as inputs to workflows that can touch customer data or business systems.

These aren’t separate SEO and security problems. They are two questions about the same content supply chain: does an AI system represent your brand clearly, and can it handle the underlying content without obeying instructions that don’t belong there? You need both answers before you call an AI search program successful.

Your citation dashboard may be overstating visibility

A citation and a brand mention are different events. A citation connects an answer to your URL. A mention puts your brand name in the generated answer. When the URL appears but the brand does not, you have a ghost citation: the engine used your content, yet the reader may never connect the information to you.

That gap is large enough to change how you interpret an AI visibility report. Writesonic analyzed roughly 16 million brand appearances and found that about 40% of AI citations did not name the source brand. Because this is vendor-supplied observational data and a founder of the vendor co-authored the published analysis, treat it as directional evidence rather than a universal benchmark for every industry or query set.

The engine-level differences are still operationally useful. Within that dataset, the ghost-citation rate ranged from 19% to 52%:

AI engine	Cited appearances without a brand mention	What to verify in your own tracking
Perplexity	52%	Whether frequent source links translate into answer-text recognition
Google AI Mode	49%	Whether your organization is named beside the information it supplied
Google AI Overviews	41%	Whether citation growth is accompanied by visible attribution
ChatGPT	37%	Whether mentions and citations occur in the same response
Gemini	25%	Whether visible mentions also provide a route back to your site
Grok	22%	Whether the brand is named accurately and in the intended context
Microsoft Copilot	19%	Whether stronger naming is matched by consistent source links

Do not turn this table into a forecast for your site. Use it to identify the measurement error in a citation-only KPI. Two brands can have the same citation count while receiving very different levels of recognition, recommendation, and referral opportunity.

You can make attribution easier to preserve without stuffing your name into every paragraph. Put the organization name next to the evidence that an answer engine is likely to extract. A reusable evidence unit should make the actor, scope, and finding explicit in one or two sentences. A pattern such as [Brand] analyzed [defined dataset] and found [specific result] is harder to detach from its owner than one analysis found.

Use the same canonical organization name in the visible copy, author or publisher information, and Organization and Article JSON-LD.
Name first-party datasets, methods, tools, and recurring reports consistently so the evidence has a stable branded identity.
Keep the brand and its claim in the same passage. A logo, navigation label, or distant boilerplate mention is not a substitute for textual attribution.
Link to the original methodology or evidence page when one exists. A copied statistic with no clear origin weakens both attribution and trust.
Write naturally. Entity consistency helps interpretation; repetitive brand insertion makes the page worse for readers and does not guarantee an AI mention.

Structured data can reinforce who published the page and how entities relate, but it cannot force an engine to name you. The visible passage still has to carry the attribution on its own.

Measure the four outcomes an AI answer can produce

Replace the single citation total with a two-signal model. Every tracked answer belongs in one of four buckets:

Mention plus citation: the reader sees the brand and has a path to the supporting page. This is the strongest attribution outcome.
Mention without citation: the brand is visible, but the answer provides no direct route to your evidence or website.
Citation without mention: your page appears as a source, but the answer leaves the brand unnamed. This is the ghost-citation bucket.
Neither: the brand and its page are absent from the response.

From those buckets, calculate four separate metrics for the responses in a fixed prompt panel:

Citation coverage: responses containing a link to one of your approved domains divided by all tracked responses.
Mention coverage: responses containing your canonical brand name or an approved alias divided by all tracked responses.
Paired visibility: responses containing both a mention and a citation divided by all tracked responses.
Ghost-citation rate: cited responses without a brand mention divided by all cited responses.

The denominator matters. A ghost-citation rate is a diagnosis of cited responses, while citation coverage and mention coverage describe the whole prompt panel. Combining them into one percentage hides the exact failure you need to fix.

Build the panel around unbranded discovery questions that a buyer would realistically ask. Keep branded validation prompts in a separate group. If your brand name appears in the prompt, its appearance in the answer is prompted recall, not evidence that the engine selected your brand independently.

Define the exact prompts and group them by problem, consideration stage, and market.
Record the engine, date, locale, account state, and visible model or search mode for each run.
Capture the full answer, cited URLs, brand mentions, mention context, and whether the brand was recommended, compared, criticized, or merely listed.
Normalize domains and approved brand aliases before calculating the four metrics.
Rerun the same panel on a regular cadence and compare like with like. Add new prompts as a separate cohort instead of silently changing the historical panel.
Investigate answer-level examples when a metric moves. A negative mention, an incorrect citation, or a source-panel link that no reader notices should not be celebrated as equivalent to a recommendation with attribution.

Referral sessions, assisted conversions, branded search demand, and sales feedback remain useful downstream indicators. They answer what happened after exposure. The four-bucket model answers the earlier question your analytics cannot: what representation of your brand did the AI user actually receive?

The content earning visibility can also carry instructions

The same retrieval process that makes your content eligible for an AI answer creates a workflow risk. A model or agent reads text from outside its trusted instruction layer. If that material contains language that looks like a command, the system may have trouble separating the information it should analyze from the instruction it should ignore.

Old prompt-injection tricks such as white-on-white text, HTML comments, and invisible Unicode are no longer the most useful threat model for modern systems. Defenses can recognize many obvious patterns. The harder problem is structural: LLMs cannot reliably distinguish ordinary content from sophisticated instructions woven into that content.

This matters even if nobody breaches your AI provider. A compromised help page, an unmoderated comment, a third-party comparison page, an incoming email, or a retrieved document can become the delivery path.

Customer-facing deception: the ChatGPhish technique demonstrated how a malicious webpage could cause an AI summary to present a fake account alert and malicious QR code inside the chat interface. Protections focused on suspicious external URLs may not catch content rendered natively in a trusted AI product.
Recommendation manipulation: an instruction can be written as legitimate-sounding prose that attempts to make a browsing agent favor one product or disparage another. The attack does not need access to your website to affect how an agent represents your brand.
Multimodal injection: images and audio can carry signals or concealed commands that people do not notice. Podcasts, videos, uploaded screenshots, call recordings, and voice interfaces therefore belong in the same input-risk inventory as webpages and email.
Privileged agent abuse: an agent that reads untrusted content and can also send messages, change CRM records, expose data, or issue refunds has the classic confused-deputy shape. The input supplies the instruction; your agent supplies the authority.

The severity depends less on whether an injected sentence influences the model and more on what the surrounding workflow permits. A summarizer that can only draft text creates a review problem. An autonomous agent with customer data and write access can create a security, financial, and reputation incident.

Domain allowlists do not solve this by themselves. A trusted domain can be compromised, and a legitimate page can include untrusted user content. Trust has to attach to the content and the permitted action, not merely to the hostname.

Build guardrails around inputs, tools, and side effects

You cannot prompt your way out of a structural trust problem. An instruction telling the model to ignore malicious instructions is useful context, but it is not a security boundary. Put enforceable controls before and after the model.

Control what enters the workflow

Inventory every input class. Include webpages, search results, emails, attachments, support tickets, comments, PDFs, OCR output, transcripts, images, audio, logs, and model-generated summaries. If content can reach the context window, it belongs on the map.
Assign provenance and trust labels. Distinguish organization-authored instructions, reviewed internal data, approved external references, and untrusted public or customer content. Preserve that label when content is chunked, retrieved, summarized, or passed between agents.
Compare rendered and extracted content. Flag text that exists in HTML or machine extraction but is not reasonably visible to a reader, including comments, invisible characters, and display mismatches. Do not indiscriminately delete Unicode or formatting that may be legitimate; quarantine discrepancies for review.
Process every modality. Apply the same provenance rules to OCR, image descriptions, speech-to-text output, and audio transcripts. Converting media into text does not make the input trusted.
Retrieve the minimum necessary material. Smaller, purpose-specific context reduces the amount of untrusted content available to influence the model and makes later review easier.

Keep content separate from authority

Place fixed workflow instructions outside retrieved content and mark external passages as quoted data with explicit boundaries. Boundary isolation and spotlighting reduce ambiguity, but they should be treated as one layer rather than a complete defense.
Separate read-only research from action-taking. The component that browses a webpage should not automatically inherit permission to send email, modify records, disclose customer data, or approve money movement.
Grant the narrowest tool scope needed for the task. Restrict permitted actions, record types, recipients, destinations, and fields outside the model wherever possible.
Require deterministic approval for consequential side effects. Refunds, account recovery, credential changes, bulk messages, record deletion, and data export should not occur solely because a model interpreted untrusted content as an instruction.
Do not ask the same model to be the only judge of whether its proposed action is safe. Enforce schemas, authorization rules, value limits, destination allowlists, and policy checks in code or an independent control layer.

Make failures observable and reversible

Log the retrieved chunks, provenance labels, tool requests, approvals, outputs, and final side effects for each run. Redact secrets while retaining enough evidence to reconstruct what happened.
Create alerts for unexpected tools, recipients, record types, or action sequences. A valid-looking model response can still request an invalid business action.
Provide a kill switch that can remove tool access without waiting for a new prompt or model deployment.
Use reversible operations where the system allows them: draft before send, stage before publish, queue before refund, and soft-delete before permanent removal.
When testing prompt-injection defenses, use harmless canary instructions in an isolated environment with production side effects disabled. The expected result is that the system treats the canary as content, records the attempt, and refuses unauthorized action.

Your owned content needs a parallel integrity check. Limit publishing permissions, review changes to templates and metadata, moderate user-generated material before it enters retrieval systems, and monitor unexpected differences between approved copy and machine-extracted copy. A clean editorial review does not protect a page that changes after approval.

Use one release gate for both sides of the program. Before a high-value page goes live or enters an agent knowledge base, confirm that its main claims retain visible brand attribution, its structured identity is consistent, its extracted content matches the approved rendering, and any consuming workflow has an explicit permission and rollback plan. Publishing approval and agent-safety approval are related checks, not interchangeable ones.

Key takeaways for your next reporting cycle

A source link proves less than most citation dashboards imply. Measure citations and visible brand mentions separately.
Your primary success metric should show how often a response contains both the brand and its supporting URL, while ghost-citation rate diagnoses attribution loss among cited responses.
Put the brand beside the evidence an engine is likely to extract, and keep visible copy, publisher data, and JSON-LD consistent. Treat this as attribution support, not a guarantee.
Assume public webpages, customer messages, documents, images, audio, and transcripts are untrusted inputs when an AI workflow consumes them.
The critical security boundary is the agent’s authority. Browsing and summarization should not silently inherit permission to perform consequential actions.
Track visibility quality and blocked workflow risk side by side. More AI exposure is not a clean win if the system cannot preserve attribution or safely process the content creating that exposure.

Start with your highest-value unbranded prompt group and the AI workflow with the broadest write access. Reclassify the prompt results into the four visibility outcomes, then trace every untrusted input that can reach that workflow’s tools. Those two exercises will show you where recognition is being lost and where a content problem could become an operational incident.

References

July 29, 2026

Claude Chat Privacy: When Shared Links Enter Search Results
If you’ve used Claude for something sensitive, hearing that Claude chats appeared in search results can make it sound as though every private prompt is searchable. That isn’t what the documented exposure established.

The affected pages were chat snapshots made available through user-created public share URLs. The practical lesson is still serious: once you turn a conversation into a shareable web page, you should treat that page as public unless access control proves otherwise.

A shared Claude link is a web page, not a private message

A conversation inside your authenticated Claude account and a snapshot exposed through a share URL occupy different privacy states. The first sits behind your account session. The second is designed to be opened outside that session, which means the URL can be forwarded, linked from another page, collected by automated systems, or discovered by a search crawler.

Creating the share URL does not guarantee that Google or Bing will index it. It does, however, create the conditions under which indexing can happen. There are three separate stages:
1. Public access: A person who has the URL can load the page without signing in.
2. Discovery and crawling: A search engine finds the URL, often through a link or another crawlable source, and requests the page.
3. Indexing: The search engine decides that the URL or its contents can appear in search results.
The first stage is the privacy boundary. Indexing increases discoverability, but a page was already exposed before it appeared in search. An unindexed URL is therefore not the same thing as a private URL.

This also separates search exposure from other questions about AI services, such as conversation retention or model training. Those issues depend on the service’s policies and settings. The incident at issue concerned public share pages reaching search indexes; it does not, by itself, establish that ordinary unshared chats were searchable.

At one point, a site:claude.ai/share query surfaced hundreds of shared conversations, including sensitive health and political discussions. Those results were later removed. Removal from a search index reduces discovery, but it cannot establish that nobody opened, copied, forwarded, or captured a page while it was accessible.

Key takeaways
- An ordinary Claude conversation and a user-created share page are not the same privacy state.
- A public page can be accessed before a search engine indexes it, so no search result does not mean no exposure.
- If a shared conversation contains sensitive material, remove or revoke the page at its host before concentrating on search-result removal.
- Robots.txt is a crawler-management file, not an access-control or privacy system.
- A noindex instruction must remain visible to crawlers; blocking the same page in robots.txt can prevent them from seeing it.
What to do if you created a Claude share link

Start at the original page, not at Google. Search results are a downstream copy of a more important condition: whether the conversation is still publicly accessible.
1. Inventory the links you created. Check any sharing controls currently available in your Claude account, then review places where you may have pasted links: email, chat messages, tickets, documents, notes, social posts, or team workspaces. Do not assume you created only one snapshot.
2. Test each link while signed out. Open it in a private browser window where you are not logged into Claude. If the conversation loads without authentication or another access check, treat it as public. Avoid submitting the URL to unrelated scanning sites or public forums, because that creates additional copies and routes of discovery.
3. Revoke or remove access at Claude. Use the platform’s current sharing controls to disable the link. If no self-service control is available, contact Anthropic through its support process and identify the exact share URL. Search delisting alone is not enough while the original page remains open.
4. Record the minimum evidence you need. Keep the URL, when you noticed the exposure, and a private screenshot of any relevant search result if you may need an organizational incident record. Do not republish the conversation merely to document it.
5. Respond to the contents, not just the page. Revoke exposed API keys, access tokens, invitation links, or session credentials. Change any exposed password wherever it was reused. If the chat contains client records, employee information, regulated data, or confidential business material, notify the appropriate security, privacy, or legal owner through your organization’s incident process. Removing a page does not make a disclosed credential safe again.
6. Check search visibility after access is closed. Search for the exact URL, a distinctive non-sensitive phrase, and the site:claude.ai/share pattern in the relevant search engines. Treat these as spot checks rather than a complete audit. If a result remains, use the search engine’s webmaster or personal-information removal process, but keep the origin page disabled.
If the page contained no identifying information, credentials, confidential records, or material tied to another person, revoking the link and checking for residual results may be proportionate. If any of those elements were present, escalation matters more than repeatedly searching your own name. The consequence comes from what was exposed and who could act on it, not merely from whether a result still ranks.

For site owners, robots.txt is not a privacy control

The technical failure behind this kind of exposure is easy to repeat. A team wants to keep pages out of search, so it disallows their paths in robots.txt and adds a noindex directive to the pages. That combination looks cautious, but the two instructions can work against each other.

A noindex directive works only after a crawler retrieves the page and reads the directive in its HTML or HTTP response. When robots.txt prevents that retrieval, the crawler cannot see noindex. Google explicitly warns that a robots-blocked URL can still appear in results when the engine learns about it elsewhere, such as through links.

The right configuration depends on the access policy you actually intend:
- Private conversation: Require authentication and verify that the signed-in user is authorized to access that specific conversation. Add noindex as defense in depth, not as the lock on the door.
- Public share page that should not appear in search: Allow compliant crawlers to request the page, then serve a noindex meta directive or X-Robots-Tag response header. Do not disallow the same URL in robots.txt while depending on noindex.
- Public and indexable publication: Make the publishing consequence explicit before the user creates the URL. Let the user preview and redact the content, identify what metadata will be visible, and provide a reliable revocation control.
- Revoked or deleted share: Remove public access at the origin. Require authorization again or return a genuine not-found or gone response. Search-removal requests can accelerate cleanup, but they should follow the access change.
Noindex does not encrypt content, restrict direct visitors, stop forwarding, or prevent every scraper and archive from collecting a page. Robots.txt does none of those things either. If viewing the content would itself be a privacy failure, the content belongs behind authentication and server-side authorization.

Test the privacy boundary as a stranger would

A logged-in product test can hide the most important failure. Include these checks in every release that affects chat sharing:
- Open a newly shared link in a clean, signed-out browser session.
- Confirm whether the user made an explicit public-sharing choice before the URL was created.
- Inspect the rendered meta robots value and response headers on the actual share template.
- Verify that robots.txt does not block crawlers from reading a noindex directive you expect them to obey.
- Revoke the link and confirm that the same signed-out request no longer reveals the conversation.
- Maintain a server-side inventory of active share URLs instead of relying on site: searches, which are useful for discovery but incomplete as an audit.
Before your next sensitive Claude session, decide whether the content should remain inside an authenticated conversation or become a shareable web page. If you choose to share, redact first and act as though the link may travel. For product teams, make that same distinction structural: private content needs access control, public-but-unlisted content needs a crawlable noindex directive, and revoked content needs to stop loading.

References
- Search Engine Land – Google indexed Claude Chats because Anthropic didn’t block your private chats from search engines
July 28, 2026

Google Ads Access and Compliance Controls: A Practical Runbook

If you manage Google Ads through an API, an agency workflow, or connected reporting tools, your next access failure may not be a broken integration. It could be a human user who cannot complete a new authorization because no trusted passkey is ready. A campaign approval can stall for a separate reason: the account has not completed the certification required for a particular use.

You need to manage those as two control planes. Authentication determines who or what can connect to Google Ads. Certification determines whether an account has completed a policy approval for a particular advertising activity. Keeping separate owners and status records for each makes both problems easier to prevent and diagnose.

Key takeaways

A passkey is required when a user generates a new OAuth 2.0 refresh token through the Google Ads API user-authentication workflow. This is not a blanket invalidation of every existing connection.
Existing OAuth refresh tokens continue working and do not need reauthorization solely because of this change.
A newly created passkey may face a seven-day security delay before it becomes fully trusted. Prepare it before a scheduled onboarding or authorization event.
Service-account automation is not affected, but Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are included in the broader passkey rollout.
Some certification applications are moving into Admin > Policy > Account. Availability varies, and the Help Center remains the fallback when the in-account workflow is absent.

Treat authentication and certification as separate controls

An OAuth refresh token is a credential that lets an application obtain new access tokens without asking the user to sign in for every request. A certification is an account-level policy approval for a defined advertising use. Both can block work, but they answer different questions.

Control area	Question it answers	What you should record
Authentication	Can this user, service account, application, or connected tool authenticate?	Credential type, human owner, passkey readiness, token state, affected system, and last successful authorization
Certification	Has this Google Ads account completed the required policy application for the intended advertising use?	Customer account, certification type, submission route, accountable approver, submission status, and decision

A passkey cannot establish that you have the right to use copyrighted material. A Social Casino Games certification cannot restore an invalid OAuth credential. When a team tracks both under a vague label such as “Google access,” the wrong person receives the incident and the actual blocker remains untouched.

Assign an access owner and a policy owner for each account. They can be the same person in a small organization, but the responsibilities should remain distinct. The access owner manages identities, credentials, connected products, and authorization events. The policy owner confirms the intended ad use, controls certification submissions, and keeps the supporting internal approval trail.

Prepare new OAuth authorizations before they become urgent

The passkey requirement has a narrow but important scope. Under the announced rollout, which begins Aug. 5 and expands over the following weeks, a human following the Google Ads API user-authentication flow must use a passkey to generate a new OAuth 2.0 refresh token. Password-only authentication and familiar second-factor routes such as SMS codes and time-based one-time passwords no longer satisfy this particular workflow. A user without a passkey is prompted to create one.

Do not interpret that as an instruction to rotate every refresh token. Existing refresh tokens remain valid without reauthorization. Revoking a working credential merely to “comply” can create the exact new-token event for which your team is not yet prepared. Rotate or revoke a token when your normal security process requires it, but do not manufacture a migration that Google does not require.

The planning risk sits at the next authorization event. A newly created passkey may be subject to a seven-day security delay before Google fully trusts it. That means a user who creates a passkey when onboarding begins may not be able to finish the workflow on the date you promised.

Identify the human Google accounts expected to authorize new integrations or reconnect deliberately.
Have those users create their passkeys before the authorization window, not during it.
Put the possible seven-day delay into onboarding plans and change windows that depend on a new refresh token.
Keep existing refresh tokens in place while they remain valid and authorized.
Never paste a refresh token, passkey material, or other secret into a ticket, spreadsheet, or certification record. Track status and ownership, not secret values.

Also distinguish an expiring access token from a request for a new refresh token. A healthy OAuth integration normally uses its existing refresh token to obtain new access tokens. The passkey change does not mean a person must intervene every time a short-lived access token expires.

Build the runbook around the credential type

Three organized credential setups for a staff user, an application, and an agency account surround a central advertising platform device.

A single instruction that says “set up a passkey for Google Ads” is too broad to be operationally useful. Start by classifying every connection according to how it authenticates and who owns the authorization.

Create an inventory with the Google Ads customer or manager account, connected application, environment, credential type, human or service owner, and business purpose.
Mark each connection as user-authorized OAuth or service-account automation. Applications that use service accounts for automated workflows are not affected by the new user passkey requirement.
For user-authorized OAuth, record whether the current refresh token is working and whether the authorizing user has a passkey ready for a future authorization.
List connected Google Ads products separately. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are also affected; a user accessing them without a passkey can be prompted to create one.
Add a named backup owner for the process, but do not create shared human accounts or copy credentials between people. The backup should know the recovery and reauthorization procedure, not possess another user’s secret.
Review the inventory before onboarding a client, changing the authorizing identity, or intentionally replacing a refresh token.

This classification also shortens incident triage. If a previously healthy API sync fails while using an existing refresh token, do not assume the passkey rollout invalidated it; existing tokens were explicitly left in place. Investigate the normal credential, permission, application, and account conditions. If a new user-consent flow cannot complete, check passkey readiness and the possible trust delay first. If service-account automation fails, the new user passkey rule is unlikely to be the cause.

Connected products deserve named owners even when the API integration itself is stable. A reporting team may meet the prompt in Looker Studio or BigQuery Data Transfer Service while the central API pipeline continues normally. Without a product-level inventory, that prompt can be misreported as an account-wide outage.

Turn in-account certifications into a controlled workflow

Compliance specialists move an account dossier through evidence review, approval, and secure archiving while an incomplete folder remains separated.

Google is gradually placing some certification applications inside Google Ads. Eligible advertisers may see the Social Casino Games workflow under Admin > Policy > Account. Not every account receives the option at the same time, so a missing menu is not evidence that an application was denied. Advertisers without the in-account option can continue using the existing Help Center process.

The interface rollout does not change the underlying advertising policy. It changes where some advertisers submit and manage the application. Existing Social Casino Games certifications remain valid, and pending applications are not affected. Do not submit a replacement merely because another account has gained the new interface.

A copyright-certification beta has also appeared as an account-level notice in Google Ads Manager. It opens a form that asks the advertiser to certify the right to use copyrighted content. Treat that availability as account-specific rather than universal.

Check Admin > Policy > Account in the exact customer or manager account involved.
If the appropriate certification workflow is present, record that the in-account route is available before submitting.
If it is absent, use the existing Help Center route instead of waiting indefinitely for the gradual rollout.
Check your internal register for a valid certification or pending application before creating another submission. Existing and pending Social Casino Games cases do not need to be restarted because of the interface change.
Record the account, certification type, submission route, submission date, accountable person, current status, and decision in a system your policy owner can review.
For a copyright attestation, route the submission to someone authorized to confirm ownership or licensing. The form records a certification; it does not create rights that the advertiser does not already hold. If the rights are unclear, pause the submission and have the appropriate rights or legal owner verify them.

Do not let the easier placement reduce the quality of your review. An in-account button makes submission more convenient, but convenience is not evidence. The person submitting should still be able to identify the account, the intended use, the authority for the claim, and the internal owner who approved it.

Before your next onboarding or certification deadline, create the two registers, classify every credential, and assign the two owners. Then have affected human users prepare passkeys early and check the exact account for its available certification route. The immediate job is not to reauthorize everything. It is to remove uncertainty about who can authorize access, who can certify compliance, and what happens when either control changes.

References

July 27, 2026

How AI Recommendations Can Be Manipulated and Defended
AI recommendation manipulation is emerging through two related routes: attackers can seed public pages with text designed to influence research agents, while marketers can manufacture paid brand mentions in hopes of increasing visibility in AI-generated answers. Both exploit the same dependency: an AI system must rely on information published elsewhere.

Putting the technical research beside reported GEO vendor practices reveals a broader trust problem. Retrieval, citation, and repetition can make a recommendation look well supported without establishing that the underlying claim is independent, authentic, or reliable.

Key takeaways
- Manipulators do not necessarily need access to an AI model. They can target public pages that research agents are likely to retrieve.
- Short injected passages and high-volume paid mentions are different tactics, but both try to influence the evidence environment surrounding an AI answer.
- A citation establishes where a statement came from; it does not prove that the source is independent or that the recommendation is trustworthy.
- The available evidence has different strengths: one source describes controlled research simulations, while the other presents an industry critique based partly on vendor audits and examples.
- Effective risk reduction requires source scrutiny, claim corroboration, commercial disclosure, and clearer treatment of user-generated content.
One manipulation pipeline, two ways to enter it

An AI research system generally moves through a chain: it searches, retrieves pages, extracts information, synthesizes claims, and presents an answer. Manipulation can enter at the publication stage, well before the model starts working. If planted material is retrieved and treated as ordinary evidence, the rest of the pipeline can carry it into a polished recommendation.

Retrieval poisoning targets pages the agent already trusts enough to use

A CrushPress.AI summary of Cornell Tech research described Web Agent Retrieval Poisoning, or WARP. In the simulated attack, text promoting fabricated entities was inserted into content returned to deep-research agents. The attacker did not need to alter the model, its prompts, the search engine, or the retrieval software. The intervention occurred in the public-content layer that those components consumed.

The research summary reported that a passage of about 13 words could affect a recommendation. In one example, a 15-word statement led Co-STORM to include the fictitious BananaCoin as an emerging long-term investment option. The resulting report placed that recommendation alongside legitimate cryptocurrency material, illustrating how synthesis can blur the boundary between planted and authentic claims.

Manufactured mentions try to reshape the same evidence environment

A separate CrushPress.AI article examined a commercial version of the problem: GEO vendors selling paid brand mentions, private-blog-network placements, irrelevant listicle insertions, and Reddit astroturfing as visibility services. Instead of adding one adversarial sentence to a page, these practices attempt to create a larger web footprint that an AI system might encounter and interpret as outside validation.

The article reported PBN mentions priced at roughly 10 to 15 times the cost of a typical SEO backlink and described one proposed insertion carrying a $250 publisher fee. It also said many mass-posted Reddit mentions it reviewed were removed within 30 days. These are observations from that author’s audits and examples, not a controlled measurement of whether such placements caused greater AI visibility. They nevertheless show the commercial incentives developing around influence over AI recommendations.

What the evidence establishes, and what remains uncertain

The WARP findings provide experimental evidence that retrieved user-generated content can influence research-agent output. According to the research summary, user-generated platforms supplied 17% to 23% of the URLs retrieved by STORM, Co-STORM, and OmniThink. Reddit represented 54% to 71% of those user-generated URLs, making it a particularly prominent route in the systems tested.

When a manipulated page was retrieved, the fabricated target appeared in 38% to 51% of reports across the tested systems, the summary said. Targeting multiple pages increased the reported range to 42% to 62%. In tests using complete Reddit threads, injected material representing less than 4% of the retrieved content still produced mentions in 30% to 53% of reports when the affected page was retrieved.

Those results should be read within their stated boundaries. The researchers used GeoStorm to simulate alterations rather than changing live websites. They ran the full attack against three open-source systems. Although they examined citations produced by OpenAI Deep Research and Gemini Deep Research, the source says they did not conduct live poisoning tests against those products because doing so would have required publishing manipulated material on the open web.

The GEO vendor article supplies a different kind of evidence. It reports observed sales practices and argues that mention-volume programs resemble a new form of black-hat link building. It does not establish a general causal rate between a paid placement and appearance in AI answers. Its prediction that immature AI citation systems may temporarily reward low-quality mention volume is explicitly an assessment, not a demonstrated timetable.

Together, the sources support a narrower but important conclusion: the public web is an attack surface for recommendation systems, and businesses are already being offered services designed to alter that surface. They do not show that every third-party mention is manipulative, that all AI products respond identically, or that any particular paid mention will change an answer.

Why a cited recommendation can still be misleading

Citations improve traceability, but traceability is not validation. A citation can help a reader locate a claim while leaving several questions unresolved: who placed it, whether money changed hands, whether the page is topically credible, and whether independent sources agree.

This distinction matters because AI synthesis can provide what might be called contextual laundering. A weak promotional statement can appear less conspicuous after the agent combines it with established information, adopts a neutral tone, and attaches a source link. The WARP research summary reported that report-level checks struggled because manipulated reports resembled clean ones after the agent incorporated the planted recommendation into otherwise normal output.

Paid mention campaigns create a related independence problem. Ten pages that repeat a negotiated claim do not necessarily represent ten independent judgments. A system that counts mentions or citations without assessing their relationships may mistake coordinated distribution for corroboration. Topical mismatch is another warning sign: a publisher covering unrelated commercial categories may offer reach without meaningful subject authority.

Commercial transparency adds a separate layer of risk. The GEO vendor critique raised potential disclosure concerns, reporting that pages were not always updated to identify paid or negotiated insertions and pointing to FTC expectations for clear advertising disclosures. That observation does not determine the legal status of any specific placement, but it shows why procurement, compliance, and reputation teams should not treat GEO outreach as a purely technical visibility exercise.

A defensible standard for platforms, marketers, and readers

Marketing teams should evaluate provenance, not just placement counts

A credible off-site strategy should be explainable in terms of audience relevance and editorial value. Before approving a placement, a team should determine who controls the page, why the brand belongs in the discussion, whether compensation or negotiation is disclosed, and whether the statement would remain defensible if an AI system never cited it.

Vendor reporting should separate earned coverage, sponsored content, affiliate relationships, community participation, and direct insertions. Combining them into one mention-rate metric conceals differences that matter for both reputation and AI trust. Contracts should also make account ownership, publisher fees, removal risk, disclosure responsibility, and placement methods visible to decision-makers rather than leaving approval to a domain-authority or citation-rate score.

AI systems need controls at more than one layer

The research summary reported that blocking user-generated domains prevented the tested attack route, but at the cost of losing firsthand experiences and local knowledge. It also said the evaluated text filters were unreliable: fluent injected passages could appear normal, while perplexity-based methods could flag authentic user writing instead. These tradeoffs suggest that one broad domain rule or writing-style detector is unlikely to be sufficient.

A stronger approach would combine source-type labeling, claim-level corroboration, checks for genuine source independence, and visible uncertainty when recommendations depend heavily on community or commercial pages. Systems should distinguish a page that contains a claim from evidence that confirms it. Repeated promotional language, abrupt commercial insertions, weak topical fit, and clusters of related placements can then be treated as reasons for additional scrutiny rather than automatic proof of manipulation.

Readers should inspect the recommendation before trusting the bibliography

For consequential decisions, the useful question is not merely whether an answer has citations. Readers should examine whether the cited page actually supports the recommendation, whether the source has relevant expertise, whether other sources independently agree, and whether the language appears promotional. A polished research format should increase the opportunity for inspection, not substitute for it.

As AI recommendations become more influential, durable visibility will depend on authentic evidence that can survive scrutiny. Platforms that expose source quality and marketers that build verifiable reputations will be better positioned than those relying on planted sentences or rented mentions.

References
- CrushPress.AI — How 13 Words Can Poison Deep-Research AI Recommendations
- CrushPress.AI — Paid Brand Mentions in GEO: The Risky Trap I See
July 3, 2026

Locked Out of Facebook? A Practical Account Recovery Plan

If Facebook rejects your password, asks you to prove your identity, or says your account has been disabled, pay close attention to the exact wording. Those messages can point to different systems, and choosing the wrong recovery route can leave you repeating forms that were never designed for your problem.

Your immediate goal is to identify the type of lockout, protect any access you still have, and give Facebook one clear, well-documented case. The same approach applies whether you use Facebook personally or depend on it to manage Pages, advertising, and client assets.

Key takeaways

A changed email address, changed password, unfamiliar activity, or an unknown login points toward an account takeover. Use the dedicated hacked-account process at facebook.com/hacked.
An identity check after travel, a device change, or VPN use is more likely to be a security checkpoint. Complete it from a familiar device and connection if possible.
A notice that names a Community Standards or policy violation belongs in the enforcement appeal route, unless you also have concrete signs that someone took over the account.
Preserve screenshots, Facebook emails, your profile URL, affected business asset IDs, and a short timeline before submitting a claim.
A linked Instagram account may provide another recovery route. Meta Verified can sometimes add access to chat support, but it is paid and does not guarantee reinstatement.
After recovery, enable two-factor authentication, save the recovery codes somewhere secure, and make sure business access does not depend on one personal profile.

Identify which system locked you out

A Facebook lockout is not one problem with one form. It may be a security response to suspicious access, an automated enforcement decision, an identity-verification failure, or a permissions problem affecting a Page or business account.

Facebook evaluates signals such as unfamiliar devices, unusual locations, repeated settings changes, and unexpected posting or messaging patterns. Legitimate travel, VPN use, a new phone, or a rapid sequence of account changes can resemble the behavior of an attacker.

Content enforcement creates a separate problem. Automated moderation operates across an enormous number of accounts, but pattern detection cannot always understand intention or context. That means ordinary activity can become a false positive. If the notice refers to a standards violation rather than suspicious access, treat it as an appeal problem first.

What you see	Likely recovery lane	First action	What to avoid
Your email or password changed, unfamiliar content appeared, or an unknown device accessed the account	Account takeover	Secure your email account, preserve evidence, and use facebook.com/hacked	Submitting only a general policy appeal
An identity or security check appeared after travel, VPN use, or a device change	Security checkpoint	Return to a recognized device and normal connection, then complete the verification shown	Switching repeatedly between devices, networks, and recovery methods
A disabled or restricted notice names a policy or Community Standards issue	Enforcement appeal	Use the appeal attached to that decision and address the stated issue directly	Claiming the account was hacked without evidence of a takeover
Your personal profile works, but a Page, ad account, or business account is inaccessible	Business asset or permissions issue	Record the affected asset’s URL or ID and use the relevant business support route	Describing the case only as a personal login failure

Some cases genuinely cross lanes. An attacker may take over a profile, change business permissions, publish prohibited material, and trigger an enforcement action. Do not force that sequence into one vague sentence. Describe each event in order and identify the first thing that went wrong.

Recover access in the right order

Recovery becomes harder when every attempt changes a different variable. Work through the following sequence once, document what happens, and use the result to decide whether escalation is necessary.

Preserve any working session. If Facebook or a linked Instagram account is still open on a trusted device, do not log out reflexively. Record the profile URL, current contact information, connected accounts, and any visible security alerts first.
Capture the full lockout message. Take a screenshot that includes the message, the page or app where it appeared, and any case number, appeal button, deadline, or stated reason. Copy the exact wording into your notes.
Secure the email account connected to Facebook if you suspect a takeover. Change the email password, enable its multi-factor authentication, and review whether its recovery address or phone number was altered. Facebook recovery cannot remain secure if an attacker still controls the inbox receiving its messages.
Use the route that matches the evidence. Go to facebook.com/hacked for changed credentials or unauthorized activity. Complete the displayed security checkpoint for an unusual-login flag. Use the decision-specific appeal for an enforcement restriction.
Submit identity documents only through an official Facebook or Meta flow that explicitly requests them. Do not send an ID, password, recovery code, or one-time authentication code to someone who contacts you through a direct message.
Record the submission. Save the date, account used, route followed, files supplied, confirmation screen, and reference number. If you later reach another support channel, this record lets you continue the same case instead of creating a contradictory account of events.

Avoid repeatedly changing the email address, password, phone number, and device during the same recovery attempt. Frequent settings changes are among the behaviors that can look suspicious, so frantic experimentation may add more risk signals to an already difficult case.

Build a case that automated support can route

Hands organize a phone, laptop, blank identification card, receipt, calendar, and security key into an account recovery evidence folder.

Facebook’s support workflows are organized around predefined categories such as a hacked account, login failure, or rejected ad. A case that mixes several problems without explaining their sequence can be sent back into the wrong workflow. Your documentation should make the category and requested outcome unmistakable.

Prepare one recovery folder containing:

The exact URL of the affected Facebook profile, Page, or other asset.
The login email address or phone number historically associated with the account.
Full screenshots of the error, restriction, identity check, or changed account details.
Relevant emails from Facebook, including the sender, subject, date, and any security links or case references.
A copy of the identity document requested by the official verification process, if one was requested. Keep this out of informal email threads and third-party chats.
A short chronology: when access last worked, what changed first, what unauthorized activity you observed, which recovery route you used, and what response followed.
A single requested outcome, such as restoring profile login, reversing a specific enforcement decision, or returning access to a named Page.

Write the chronology as observable facts rather than conclusions. For example: the login worked on one date, a password-change email arrived later, the registered email then stopped working, and an unfamiliar Page role appeared. That is easier to evaluate than saying only that Facebook deleted everything for no reason.

Separate personal access from business assets

Facebook is an ecosystem of personal profiles, Pages, ad accounts, business-management tools, and linked Meta services. Those components can have different permissions and support routes, so a problem spanning several products may not have one team that owns every part.

Map the case as a chain:

Personal profile: include its URL and whether login works.
Facebook Page: include its name, URL or ID, and whether other administrators retain access.
Ad account: include its ID and whether the problem is login, permissions, restriction, or ownership.
Business account or business-management layer: include its ID and identify the first asset in the chain that became inaccessible.
Linked Instagram account: state whether it remains accessible and whether it is connected through Meta’s account center.

If another authorized administrator still has access, ask that person to preserve the current role and asset information. They should not make unnecessary ownership or permission changes while the facts are still unclear. The useful contribution is evidence and continuity, not another burst of changes that obscures what happened.

Escalate safely, then remove the single points of failure

Use an escalation only when it adds a real route

Repeating the same form with different wording is not escalation. A genuine escalation gives the case a new support channel, a traceable administrative claim, or evidence the first workflow did not have.

Complete the standard hacked-account, security-check, or enforcement route that matches the case.
If Facebook and Instagram are linked through Meta’s account center, check whether the accessible account exposes recovery or support options for the locked one.
If an eligible linked Instagram account remains accessible, a Meta Verified subscription may provide chat support and a route for an administrative claim. This is a paid support option, not a guaranteed recovery service, so use it only if the potential benefit justifies the cost.
If a Page, ad account, or business account is the affected layer, use the support route associated with that business asset and provide the asset map from the previous section.
If the lockout creates serious contractual, ownership, legal, or financial exposure, consult a qualified lawyer about the available options. That is a risk decision, not a routine account-recovery shortcut.

Recognize the recovery scam before it compounds the damage

Limited access to human support has created an underground market around locked accounts. Some supposed recovery services have demanded payment through unusual methods such as game credits. A person asking for this kind of payment is not giving you a legitimate Meta support route.

Walk away if someone:

Promises a guaranteed reinstatement or claims they can bypass Facebook’s decision.
Asks for your Facebook password, email password, two-factor authentication code, or saved recovery code.
Requests payment in game credits or another method that is difficult to trace or reverse.
Directs you to upload identification on a non-Meta website.
Cannot provide a case reference or show how their process connects to an official support channel.

A locked account already exposes you to impersonation and data loss. Giving a stranger your email credentials or authentication codes can turn a recoverable Facebook problem into a broader takeover.

Harden the account as soon as access returns

Do not treat a successful login as the end of recovery. Before returning to normal posting or advertising:

Enable two-factor authentication and confirm that the chosen method works.
Generate and securely store recovery codes somewhere you can reach without the Facebook account or its usual device.
Change to a unique password and make sure the connected email account is protected separately.
Review the account’s email addresses, phone numbers, recent sessions, and linked Meta accounts for changes you did not make.
If linking Facebook and Instagram through Meta’s account center is appropriate for you, verify that the connection and recovery details are correct. Linked accounts can provide a more direct recovery path.
For business assets, maintain an up-to-date record of asset IDs, owners, administrators, and recovery contacts. Where your governance permits it, give a second trusted person the minimum access needed to prevent one personal profile from becoming the only route into the business.
Before travel or a device migration, confirm that you can reach your two-factor method and recovery codes. Avoid combining a new device, unfamiliar location, VPN, and several settings changes in one session.

If you are locked out now, start with the exact notice on the screen and choose the matching recovery lane. Make one complete, consistent submission backed by evidence. If you still have access, remove the single points of failure before Facebook’s automated systems force you to test the recovery process under pressure.

References

Search Engine Land — Understanding Why Facebook Accounts Are Being Locked Out More Often

May 6, 2026

Google Web Bot Auth: A Practical Adoption Plan for Websites

If you manage bot access at a CDN, firewall, reverse proxy, or application layer, Google Web Bot Auth presents an awkward decision: prepare for stronger bot identity without blocking legitimate traffic that does not yet use it.

The safe approach is to add Web Bot Auth as a new verification signal, not replace your existing controls. You can then learn from signed requests, distinguish authentication from permission, and tighten access only when coverage is reliable enough for the agents and routes you care about.

What Web Bot Auth actually changes

A user-agent string tells you what a requester claims to be. IP and reverse-DNS checks can associate a request with known infrastructure. Neither gives you the same kind of identity evidence as a cryptographically signed request.

Web Bot Auth is an experimental cryptographic protocol that lets participating bots sign requests. A compatible verifier can use that proof to determine whether the request came from the claimed agent rather than trusting a label that another client could copy.

Signal	What it tells you	How to use it now
User-agent string	The identity a requester claims	Keep it as classification context, not proof by itself
IP and reverse DNS	Whether the request is associated with expected network infrastructure	Keep using these checks during the limited rollout
Web Bot Auth	Whether a participating agent supplied valid cryptographic identity proof	Add it as a stronger signal where verification is supported

This is an authentication improvement, not a complete bot-management policy. A valid signature can help establish who sent a request. It does not decide whether that agent may crawl a page, use an expensive endpoint, access licensed material, or bypass rate limits. Those are authorization decisions that remain yours.

That distinction prevents the most dangerous implementation mistake: treating “authentic” as a synonym for “allowed.” A verified agent can still request a route your policy excludes. An unsigned agent may still be legitimate while adoption remains partial.

Why Web Bot Auth must remain an additional signal

Web Bot Auth is in a limited test involving some AI agents hosted on Google infrastructure. Not every Google user agent uses it, and Google is not signing every bot request. Requiring a valid Web Bot Auth result across your site would therefore turn incomplete deployment into an access-control failure.

In practice, the absence of a signature has three possible meanings: the requester is not participating, a participating agent did not sign that request, or the requester is not what it claims to be. The rollout does not yet let you collapse those cases into “fraudulent.” Keep IP, reverse-DNS, and user-agent checks operating alongside the new protocol, as Google advises during gradual adoption.

Your internal classification should represent that uncertainty. A binary “Google bot” field is no longer enough. Use separate states such as:

Cryptographically verified: Web Bot Auth verification succeeded and resolved to an identity you recognize.
Legacy verified: the request passed your established network and identity checks but did not carry usable Web Bot Auth proof.
Unverified: the request supplied no acceptable proof and did not pass your legacy verification path.
Contradictory or failed: the claimed identity conflicts with your verification results, or supplied authentication material fails verification.

Do not silently translate “legacy verified” into “untrusted.” That would make a protocol coverage gap look like a security finding. Conversely, do not let a familiar user-agent string upgrade an unverified request into a trusted one.

Failed proof deserves more scrutiny than absent proof. An unsigned request may simply sit outside the test. A request that presents authentication material but cannot be validated has actively failed the verification path. Your system should preserve that distinction for policy decisions and incident review.

A safe adoption plan for your edge and application stack

A layered website stack shows signed and unsigned automated requests moving through observation, verification, and limited enforcement paths with monitoring and rollback routes.

You do not need to redesign every bot rule at once. Start by separating verification from enforcement, then introduce the new result in stages.

Map the current decision path. Identify where user-agent checks, IP rules, reverse-DNS verification, rate limits, robots directives, and application permissions affect a request. Note whether the decisive action happens at the CDN, firewall, reverse proxy, application, or more than one layer.
Define the verdicts before integrating them. Decide how your system will represent valid, absent, failed, unsupported, and indeterminate Web Bot Auth outcomes. Do not force these states into one Boolean field.
Add verification without changing access. In the first phase, calculate and log the Web Bot Auth result while preserving existing allow, limit, challenge, and deny behavior. This gives you evidence about real coverage without risking accidental exclusions.
Compare signals. Review requests that claim the same agent identity but produce different network and cryptographic results. Investigate disagreements before using the new signal to make blocking decisions.
Introduce graded enforcement. Prefer lower-risk actions, such as applying ordinary rate limits to unverified automation, before making a signature mandatory. Reserve strict requirements for routes where you have confirmed support and where the cost of unauthorized access justifies the tighter rule.
Keep a rollback path. Authentication failures should be visible, attributable to a specific policy, and reversible without redeploying unrelated application code.

Place verification where request data can be inspected before an irreversible allow-or-deny decision. That may be at the edge in one architecture and inside a trusted gateway in another. Do not assume your CDN, security plugin, or bot-management service supports the protocol merely because it can read headers. Cryptographic verification requires a compatible implementation and a defined trust process.

Before enabling enforcement, make the implementer answer the operational questions that matter for any signed-request system: What parts of the request are covered? How is the signing identity trusted? How are invalid, stale, or unverifiable proofs handled? How does verification behave during key or service changes? Which failure mode applies if the verifier is unavailable? If your stack cannot answer those questions, keep the integration in observation mode.

Your logs should store conclusions that operators can use, not just a dump of unfamiliar authentication data. Useful fields include the claimed user agent, legacy-verification result, Web Bot Auth result, resolved identity, requested route, policy action, response status, and the component that made the decision. Apply your normal security, privacy, and retention rules to those records.

Build AI-agent access rules around identity and purpose

Verified automated agents follow different permission paths to public and restricted website resources, while policy barriers block access to sensitive areas.

Once you can verify an agent, resist the urge to create a single global allowlist. Public articles, resource-intensive APIs, account pages, and licensed datasets do not have the same risk or purpose. The identity result should feed a route-specific policy.

Verified identity plus permitted route: allow the request under the limits assigned to that agent and content class.
Verified identity plus prohibited route: deny it. Authentication does not override the route policy.
No Web Bot Auth proof plus successful legacy verification: continue the established bot policy while coverage remains incomplete.
Claimed known identity plus failed verification: treat the request as untrusted and preserve the failed result for investigation.
Unknown automation: apply your general unknown-bot controls rather than granting access based on a recognizable name.

Private or account-bound routes still need their ordinary application authentication and authorization. Bot identity proof is not a substitute for a user session, API credential, subscription entitlement, or content license.

The same separation applies to robots instructions and other content-use rules. Web Bot Auth can help determine which agent is asking. Your published directives and internal access policy determine what that identity may receive. Keep those systems aligned, but do not merge them conceptually.

For SEO, AEO, and GEO teams, the immediate benefit is cleaner observability rather than a promised visibility gain. Nothing in the limited rollout establishes Web Bot Auth as a ranking, citation, or inclusion mechanism. Do not change canonical tags, structured data, content architecture, or indexation rules merely because signed bot requests appear in your logs.

Use the stronger identity signal to answer narrower operational questions: Which verified agents request your content? Which sections do they reach? What status codes do they receive? Where do rate limits or access rules interrupt them? How often does a claimed identity match a verified identity?

Do not label a verified crawl as an AI citation, recommendation, or referral. A request proves an interaction with a URL, not what an agent later generated for a user. Keep server-side agent activity separate from user referral traffic and from any evidence that your brand appeared in an AI answer.

Key takeaways and your next move

Web Bot Auth adds cryptographic identity evidence to participating bot requests.
The protocol remains experimental and is being tested with only some AI agents on Google infrastructure.
Not every Google user agent or request is signed, so missing proof is not proof of impersonation.
Keep user-agent, IP, and reverse-DNS verification running alongside Web Bot Auth during the rollout.
Authentication establishes identity; your route, content, and rate-limit policies still decide permission.
Use verified requests to improve bot observability, but do not treat a crawl as evidence of an AI citation or ranking benefit.

Your next move is concrete: map the component that currently decides whether a bot request is allowed, add a multi-state Web Bot Auth verdict to that path, and run it without enforcement first. Preserve your existing controls until signed-request coverage is confirmed for the exact agents and routes you intend to govern.

That design lets you benefit as adoption expands without making today’s legitimate unsigned traffic pay for tomorrow’s authentication model.

References

Search Engine Land – Web Bot Auth: Google’s new experimental method to validate authentic bots

May 5, 2026

Best-of-N AI Jailbreaking: Risks and Defensive Controls

You may have watched your AI assistant reject an unsafe request and concluded that its safeguards worked. If you tested only once, you answered the wrong question. An attacker does not need every prompt to succeed. They need one useful failure after enough retries.

Best-of-N jailbreaking turns that model variability into a search process. To manage the risk, you need to evaluate the whole campaign, enforce permissions outside the model, and control every additional chance created by retries, fallback models, tools, and automated agents.

The dangerous unit is the campaign, not the prompt

A Best-of-N attack creates or collects multiple versions of a prohibited request, submits them to an AI system, and selects the response that comes closest to the intended outcome. The essential move is to send many variations and keep the most successful result. The value of N is not fixed, and the selection can be performed by a person, a script, or another model.

This changes the security question. A per-request review asks, “Did this prompt get blocked?” A campaign-level review asks, “Did any related attempt produce a prohibited result?” The second question reflects the attacker’s objective.

The probability principle is straightforward. If each attempt has a nonzero chance of crossing a boundary, repeated opportunities can raise the chance that at least one attempt succeeds. Under the simplified assumption that attempts are independent and have the same success probability p, the probability of any success after N attempts is 1 – (1 – p)^N. Real prompt variants are often correlated, so you should not use that formula as a production risk estimate. Measure complete campaigns against your actual system instead.

Three distinctions prevent confusion during threat modeling:

A normal retry is usually an attempt to clarify a legitimate request after an incomplete or incorrect answer. Repetition alone does not establish malicious intent.
A jailbreak tries to bypass behavioral restrictions placed on a model.
Prompt injection supplies untrusted instructions that compete with the system’s intended instructions, often through user input or retrieved content. Best-of-N is a search strategy that can amplify jailbreaks, prompt injection, or other policy-evasion techniques.

Treat Best-of-N as a threat multiplier, not as the root vulnerability. It finds inconsistent decisions and weak handoffs. It cannot grant a caller a permission that your application enforces deterministically outside the model. That is why authorization architecture matters more than clever safety wording.

Where repeated attempts find extra chances

An isometric AI network branches into retry loops, fallback nodes, tools, memory, and agent pathways carrying repeated request signals.

Your model is only one part of the attack surface. A typical AI workflow also has an identity layer, input filters, a router, one or more models, output checks, retrieval, tools, and application code. Every component that makes a fresh probabilistic decision can give a campaign another route to success.

Layer	Misleading green light	Campaign signal to inspect	Stronger control
Prompt policy	One prohibited request was refused	Related requests are repeatedly rephrased after denials	Aggregate policy events by actor, session, intent cluster, and protected resource
Input moderation	Each prompt remains below an individual alert threshold	Small wording, format, language, or encoding changes accumulate around the same objective	Analyze normalized forms and sequences while retaining the raw input for investigation
Model routing	The primary model refused	A fallback model, alternate endpoint, or retry path returned a different decision	Apply one canonical policy before routing and a final gate after generation
Tools and agents	The assistant’s visible text looks harmless	A tool call requests a broader scope, sensitive record, or irreversible action	Enforce authorization, parameter validation, and action limits in application code
Traffic controls	Each IP address or API key stays within its local limit	Related attempts move across sessions, keys, endpoints, or models	Correlate only the identifiers justified by your threat model, privacy obligations, and retention policy
Logging	Every prompt was stored somewhere	No record connects attempts, decisions, tool calls, and final outcomes	Assign campaign and event identifiers so an investigation can reconstruct the sequence

For an SEO, AEO, or GEO workflow, the highest-consequence result may not be a bad chat response. It may be an unauthorized CMS publication, a destructive edit, exposure of an unpublished campaign, or a tool call made with the application’s credentials. If a model generates page copy or JSON-LD, syntactic validation is necessary but insufficient. Valid structured data can still contain false, disallowed, or unapproved claims. Check the output against business rules and publishing permissions before it reaches a live page.

Build controls that survive repeated attempts

A request signal passes through layered security gates before reaching an AI core and protected tool mechanisms.

No safety prompt can carry this responsibility alone. Prompts influence model behavior, but they are not security boundaries. Use several controls with different failure modes, and place deterministic checks wherever failure could expose data, spend money, alter content, or trigger an external action.

Put authorization outside the model. Resolve the authenticated principal in application code, grant the least privilege needed for the workflow, and verify permission again when a tool executes. Never let generated text decide whether the caller may read, publish, delete, or export something.
Separate read and write capabilities. An assistant that only needs to draft content should not inherit publishing or deletion rights. When write access is required, constrain the allowed resource, action, fields, and destination.
Normalize for analysis without overwriting evidence. Retain the original request, then create a canonical representation for similarity detection. Normalization can help reveal superficial changes in spacing, character representation, formatting, or casing, but it must not silently change the content executed by downstream systems.
Maintain campaign state. Record the actor or service identity, session, endpoint, model route, normalized intent cluster, policy decision, tool request, and outcome. Look for repeated denials, rapid reformulations, alternate-route probing, and requests that converge on the same protected capability.
Add adaptive friction. As campaign risk rises, reduce retry opportunities, disable expensive fallback routes, introduce a cooldown, require stronger authentication, or move the request to human review. Apply the strongest friction to workflows with data access or irreversible effects rather than imposing the same response on harmless drafting tasks.
Gate outputs and tool calls separately. Check generated content against the output policy, validate structured fields, reject unexpected tool names or parameters, and limit the records or resources returned. A harmless-looking explanation must not conceal a disallowed action request.
Define safe failure behavior. If moderation, identity resolution, authorization, or final validation is unavailable, return a controlled error for protected operations. Do not route around a failed safeguard to preserve a smooth user experience.
Protect the control plane. Restrict who can change system prompts, policy rules, model routes, tool definitions, and safety thresholds. Log those changes and make rollbacks possible, because a campaign can exploit configuration drift as readily as model variability.

There is no universal safe retry count. A blanket limit low enough for a sensitive data-export agent may be needlessly hostile in a public brainstorming tool. Set budgets by consequence, then examine legitimate retry behavior before choosing enforcement thresholds. Track false positives alongside security outcomes so that users who are clarifying ambiguous, multilingual, or accessibility-related requests are not treated automatically as attackers.

Be careful with model-based safety judges as well. A second model can add useful evidence, but it may share blind spots with the model it evaluates. Use deterministic authorization and validation for hard boundaries, with model judgments contributing to risk scoring rather than granting privileged access on their own.

Test the full campaign without publishing an exploit kit

A single-prompt red-team check will miss the defining behavior of Best-of-N. Your evaluation runner should group related attempts, preserve production routing logic, and score whether any attempt reaches a prohibited outcome. Keep testing authorized, isolated, and away from live customer data or publishing systems.

Define the breach before generating tests. Describe prohibited outcomes in observable terms, such as returning a protected field, invoking a disallowed tool, publishing without approval, or producing content that violates a named policy. A vague label such as “unsafe response” produces inconsistent scoring.
Build campaign families. Group sanitized test cases by underlying objective, then vary the permitted dimensions relevant to your system, such as phrasing, format, language, model route, and retry sequence. Keep actionable attack strings in an access-controlled security repository rather than general documentation or analytics dashboards.
Reproduce the production topology. Include the actual order of input checks, retrieval, routing, fallback behavior, output gates, tools, and error handling. Testing the base model alone does not test the application your users can reach.
Run attempts as connected sequences. Carry session and risk state between related requests. Also test whether switching endpoints or invoking an automated agent incorrectly resets that state.
Score outcomes at two levels. Retain per-request decisions for diagnosis, but make campaign-level success the headline measure. A system can have an impressive individual refusal rate while still allowing too many campaigns to obtain one useful failure.
Review the most consequential path first. A policy-breaching paragraph matters, but a tool call that exposes private data or changes a live site demands tighter controls and faster remediation.
Version the evaluation and rerun it after changes. A new model, system prompt, router, retrieval source, guardrail, tool definition, or fallback rule can alter campaign behavior even when the visible feature appears unchanged.

Your evaluation dashboard should include the campaign any-success rate, attempts to the first breach, breach severity, detection and containment outcomes, tool or data-boundary violations, and false-positive friction for legitimate users. Do not collapse these into one average. A small number of severe authorization failures should remain visible rather than being diluted by many harmless refusals.

Stop a test immediately if it begins interacting with real user records, external recipients, paid services, or live publishing. Move the scenario into an isolated environment with synthetic data and inert tools. The purpose of the exercise is to verify containment, not to prove that production damage is possible.

Key takeaways for AI product owners

One successful refusal does not establish safety; measure whether any attempt in a related campaign succeeds.
Best-of-N exploits repeated opportunities and inconsistent decisions, so retries, fallback models, alternate endpoints, and agents all belong in the threat model.
System prompts and model-based judges can support safety, but they cannot replace deterministic authentication, authorization, validation, and tool restrictions.
Aggregate related attempts without assuming every retry is malicious; calibrate friction to the consequence of the requested capability.
Test the production workflow as a sequence, then report campaign-level success and breach severity alongside per-request refusal metrics.
Keep security payloads controlled, use synthetic data and inert tools, and never red-team an external or production system without authorization.

Before your next release, choose the AI workflow with the greatest access to data, tools, or publishing. Trace every place where a rejected request can receive another model call or another route. Then add campaign-level telemetry and a deterministic gate at the highest-consequence handoff.

That review will not eliminate model variability. It will prevent variability from becoming permission.

References

CrushPress.AI – Unveiling AI Vulnerabilities: The Best-of-N Jailbreaking Threat

April 22, 2026

Google Ads AI: Better Call Leads Without Losing Control

Your call campaign can look productive while your sales team hears something very different: spam, robocalls, service questions, and conversations that never had a realistic chance of becoming revenue. If those calls are counted as valuable conversions, automated bidding learns from a distorted signal.

Google Ads is trying to solve that problem with AI-qualified call leads, while Ads Advisor is taking a larger role in policy, certification, and account security. The opportunity is better optimization with less manual work. The risk is allowing a model’s classification or recommended fix to become a business decision without verification. You need a controlled system for both.

Define a qualified lead before Google defines one for you

Call duration is a weak substitute for commercial value. It tells you that two people remained connected, not whether the caller wanted what you sell, met your requirements, or agreed to a meaningful next step. That is why optimizing toward long calls can reward campaigns that generate time-consuming but unproductive conversations.

Google’s AI-qualified call leads use machine learning to assess whether calls represent valuable business opportunities. The system also produces summaries and tags, then incorporates the qualification data into reporting and bidding. This is more useful than duration alone, but the model’s label is still a prediction. It is not the same thing as a sale, accepted opportunity, booked appointment, or collected revenue.

Before you let the new signal influence spend, write a qualification rule that a sales manager and a campaign manager would apply the same way. Keep it short enough to use consistently. A practical definition should answer four questions:

Did the caller express a commercial need that your business actually serves?
Does the caller fit the locations, customer types, or other eligibility conditions you accept?
Did the conversation produce a meaningful next step, such as an estimate, consultation, appointment, or sales follow-up?
Which calls must be excluded, including spam, robocalls, existing-customer support, job inquiries, vendor pitches, and wrong numbers?

Do not define a qualified lead as merely a pleasant or detailed call. A lengthy support conversation may be valuable to the customer service team and still be the wrong signal for acquisition bidding. Your definition must reflect the outcome the ad budget is meant to create.

Validate the signal before automated bidding scales it

A phone-call signal passes through multiple validation checkpoints before entering a branching automated system, while noisy signals are diverted.

A bad manual label affects one report. A bad label fed into automated bidding can affect where the next portion of your budget goes. Validation therefore belongs before optimization, not after performance has already moved.

Confirm that your account and calls are eligible. At rollout, AI-qualified call leads were limited to calls in the United States and Canada. Do not build a measurement plan around a control that is absent from your account or unavailable for the calls you receive.
Document your internal lead taxonomy. Separate qualified opportunities, unqualified prospects, non-sales calls, spam, and genuinely ambiguous calls. Preserve ambiguity instead of forcing every conversation into a positive or negative bucket.
Review a representative set of calls. Include calls the model marked as qualified and unqualified, plus obvious spam and borderline cases. Looking only at the apparent successes will hide the mistakes that matter to bidding.
Compare the AI result with the business outcome. Use the call summary and tag as inspection aids, then compare them with the disposition recorded by sales or in your CRM. Downstream evidence should settle disagreements whenever it is available.
Track false positives and false negatives separately. A false positive is a call the AI qualifies but your business rejects. A false negative is a real opportunity the AI fails to qualify. The first can steer budget toward poor traffic; the second can cause good demand to be undervalued.
Investigate patterns, not isolated disagreements. Repeated errors associated with a campaign, offer, location, call type, or routing path are more actionable than one unusual conversation. Correct the underlying measurement or campaign problem before increasing reliance on the signal.

Google allows advertisers to adjust call-length thresholds, so duration can remain a secondary diagnostic or fallback control. It should not overrule stronger evidence from the conversation and the eventual sales disposition. If AI says a call is valuable but your CRM consistently says otherwise, the disagreement is the finding.

Repeat this validation after material changes to your offer, call routing, sales script, service area, or campaign mix. The label may have looked reliable under the old traffic pattern and become less useful when the kind of calls entering the system changes.

Treat call recording as a governance decision

The qualification system needs access to call content to judge lead quality. That makes recording more than a measurement setting. It becomes part of your privacy, security, and access-control responsibilities.

Call recording is enabled by default for most advertisers, with exceptions including healthcare and financial services. Advertisers can change call-length thresholds or disable recording in account settings. A default setting is not proof that recording is appropriate for every business, caller, or jurisdiction.

Before leaving recording enabled, assign an owner to answer these questions:

What notice or consent does your business need before recording callers in every location you serve?
Which employees, agencies, and vendors can access recordings, summaries, or tags, and which of them genuinely need that access?
Where are call details copied after Google Ads, including your CRM, analytics tools, support systems, or exported reports?
How are access removal and retention handled when an employee, agency, or vendor relationship ends?
What is the escalation path if a recording or AI-generated summary exposes sensitive information?

Have the person responsible for privacy or legal compliance verify the recording rules that apply to your callers. Do this before activation because the downside is not merely an untidy report; inappropriate recording or excessive access can create legal, contractual, and reputational exposure.

Treat summaries and tags with the same care as the underlying audio. A shorter AI-generated record can still reveal why someone called, what they wanted, and how your business responded. Convenience does not make the information harmless.

If you cannot establish a lawful recording process and appropriate access controls, disable recording and accept that you may lose or limit the call-content analysis behind AI qualification. A less sophisticated measurement system is safer than collecting information you cannot govern.

Let Ads Advisor operate, but give it boundaries

A human operator supervises a geometric AI agent working inside a transparent boundary beside locked account, recording, and security assets.

Lead quality is only one part of Google Ads AI safety. Ads Advisor can proactively scan accounts and sites for policy problems, surface or apply fixes, monitor security risks, and confirm resolutions. Its security dashboard looks for issues such as suspicious domains and dormant users, while passkey support reduces dependence on passwords. Google also positioned the system to accelerate some certification workflows.

These capabilities can shorten the distance between detection and correction. They should not erase the approval boundary around changes that affect your ads, site, claims, access, or spend. Use a simple control record for every consequential AI-proposed or AI-applied action:

Trigger: What policy, security, or certification issue caused the action?
Scope: Which campaign, ad, domain, user, landing page, or account setting is affected?
Change: What exactly will be different after the fix?
Owner: Who is responsible for approving and verifying it?
Evidence: What account or site state confirms that the issue is resolved without breaking tracking, accuracy, or the customer journey?
Recovery: Can the change be reversed, and who will act if performance or compliance worsens?

Prioritize security alerts by potential account impact. A suspicious domain may indicate traffic is being sent somewhere you do not control. A dormant user may still retain access after their role has ended. Confirm ownership before taking action, remove access that is no longer required, and use passkeys where your account supports them.

Fast certification is an administrative benefit, not evidence that every claim in an ad or landing page is accurate. Keep the supporting eligibility information current and verify the public-facing campaign after approval. The same principle applies to policy fixes: a resolved warning does not automatically mean the resulting experience is commercially or legally sound.

Area	What the AI contributes	What you must confirm
Call qualification	Call assessment, summary, and tags	The call meets your written business definition and agrees with downstream disposition
Automated bidding	A higher-quality conversion signal	Qualified-lead cost and eventual business value improve, not merely the reported conversion count
Policy management	Proactive detection and proposed or automated resolution	The exact change is accurate, compliant, and safe for the landing experience and tracking
Account security	Continuous monitoring for suspicious domains and dormant users	Domain ownership, user need, and the appropriate containment or access-removal action
Certification	A faster path through eligible certification workflows	Your evidence remains valid and your ads and pages make supportable claims

At rollout, the newer Ads Advisor safety capabilities were directed first to English-speaking accounts, with other languages intended to follow. Availability may therefore differ by account. Verify the controls you can actually see before assigning responsibilities or retiring an existing review process.

Review the system when an event changes its risk: immediately after enabling a feature, after an AI-applied fix, after a change to call routing or campaign strategy, when lead-quality patterns shift, or whenever the security dashboard flags a domain or user. Event-driven review is more reliable than waiting for a generic report to expose the damage later.

Key takeaways

If you do not have a written definition of a qualified lead, do not let an AI label become a bidding objective yet.
Validate both false positives and false negatives against sales or CRM dispositions; call duration alone is not enough.
Confirm geographic and account availability before redesigning your measurement around AI-qualified calls or Ads Advisor safety controls.
Make recording, access, and retention explicit governance decisions. Disable recording if your business cannot handle it appropriately.
Require an owner, change record, verification step, and recovery path for consequential policy or security actions.
Judge the system by downstream lead value and reduced account risk, not by how many tasks it automates.

Start with one call campaign. Write the qualification rule, review where the AI and your sales outcome disagree, and resolve the recording requirements before increasing the signal’s influence on bidding. At the same time, assign a named owner for Ads Advisor alerts and fixes. That small operating boundary gives the automation useful evidence without handing it unchecked control.

References

April 21, 2026

Google Ads Security and Conversion Infrastructure Runbook

Your Google Ads stack can fail in two opposite ways: access becomes too loose to trust, or security controls become so brittle that the people and automations responsible for measurement are locked out. Meanwhile, a conversion tag can deploy cleanly and still measure the wrong action.

The practical goal is not merely to enable multi-factor authentication or create a Google Tag Manager tag. You need a traceable path from an authorized identity to a tested conversion event, with an owner and a recovery route at every handoff. This runbook shows you how to build that path without turning an access change or tagging shortcut into a campaign outage.

Key takeaways

MFA enforcement matters most when someone creates a new OAuth 2.0 refresh token. An integration that works now can still fail during reconnection, onboarding, or credential replacement.
Service accounts remain the better fit for supported automated or offline workflows, but they still need explicit ownership, limited access, and a tested handoff process.
A pre-filled Google Tag Manager configuration can remove transcription work. It cannot decide whether you selected the right container, conversion action, trigger, or counting logic.
Never revoke a working credential or remove a working conversion tag until its replacement has passed a controlled test. Otherwise, your rollback path disappears at the moment you need it.
Security and measurement should share one release record: identity owner, authentication method, Ads account, conversion action, GTM container, test evidence, publisher, and rollback decision.

Map authentication before MFA exposes a hidden dependency

A cutaway security system shows human, automated, and recovery access routes converging on one gateway, with one route blocked and a backup route remaining open.

Google’s announced rollout made MFA mandatory for new user-based Google Ads API authentication from April 21, with enforcement expanding over the following weeks. The important boundary is token creation: OAuth 2.0 refresh tokens that were already in use were not invalidated by the change, but fresh authentication requires the additional identity check.

That boundary explains why an account can look healthy until a routine maintenance task causes a failure. A scheduled process may continue using its existing refresh token, while a new employee, replacement integration, revoked credential, or reconnection attempt reaches the MFA gate. Passing today’s automated run is therefore not proof that your recovery workflow is ready.

Start with an authentication inventory. Do not begin by changing credentials. For every connection that can read from or act on a Google Ads account, record:

Workflow: the API job, reporting transfer, desktop tool, script, dashboard, or application that depends on access.
Authentication pattern: user-based OAuth or a service account.
Named owner: the person responsible for approving access, completing MFA, and handling recovery.
Operational owner: the person who can prove the workflow still runs correctly after an authentication change.
Credential event: what would force a new authorization flow, such as onboarding a user, replacing a connection, or rebuilding an integration.
Recovery route: who can restore access if the primary owner is unavailable, without sharing a personal password or MFA prompt.
Evidence: the last successful controlled authentication and the workflow result it enabled.

For user authentication, make the MFA rehearsal realistic. Use the same consent and token-generation path that the production workflow expects. Confirm that the designated person can complete the second factor, which may be a phone prompt or an authenticator app. Then verify that the resulting credential reaches the intended account and supports the intended workflow. A successful Google sign-in alone is not enough.

Choose user authentication or a service account deliberately

Keep user-based OAuth when the workflow is genuinely tied to a person’s authorization and an interactive sign-in is acceptable. Use a service account for a supported automated or offline workload when the connection should survive staff changes and should not depend on a person responding to an MFA prompt. Google left service-account workflows outside the new MFA requirement and recommends them for automated or offline scenarios.

Do not migrate to a service account merely to avoid MFA. A service account is a machine identity, not an exemption from governance. Confirm that the application supports it, grant only the access the workflow needs, document who owns that identity, and test what happens when its permissions or connection must be replaced.

Expand the inventory beyond custom API code. The same security change reaches authentication used by Google Ads Editor, Scripts, BigQuery Data Transfer, and Data Studio. If those tools are owned by different teams, give one person responsibility for the complete dependency map. Otherwise, each team may believe another team owns the failing sign-in.

Most importantly, do not revoke the working refresh token while you are only testing its replacement. Prove the new path first, record the result, and then retire the old credential through a reviewed change. Revoking first can stop reporting or automation without leaving you a quick way back.

Use direct GTM setup to remove copying, not judgment

Google Ads has tested a Set up in Google Tag Manager option inside the conversion setup flow. Where the option is available, you can select a GTM container and open a suggested, pre-filled tag configuration instead of manually carrying the conversion ID and label between products.

Treat this as a safer handoff, not an automatic implementation. It reduces opportunities for transcription errors, but it does not know whether your chosen website action represents a qualified lead, a completed sale, an internal test, or an accidental page view. It also cannot resolve a poor container naming convention or decide whether an existing tag will overlap with the new one.

The integration is described as a test, so do not make a launch deadline depend on the button appearing in your account. If it is absent, continue with the established manual setup and apply the same review process. Availability and implementation correctness are separate questions.

Confirm the conversion definition. Write down the user action that should count, where it occurs, and what must not count. Do this before opening GTM.
Match the account and container. Verify the Google Ads account, conversion action, website, GTM account, and container as one set. Similar client or environment names are not proof of a match.
Inspect the pre-filled values. Check the conversion ID and label against the intended conversion action even when Google populated them. Automation should reduce copying, not eliminate review.
Review the trigger separately. The tag configuration identifies where data should go; the trigger determines when it goes there. Confirm that the trigger represents the business event you defined in the first step.
Check for an existing implementation. Search the container for tags and triggers that already send the same action. Publishing a second path may produce duplicate events or conflicting behavior.
Test before publishing. Use GTM’s preview process and complete a controlled conversion path. Confirm that the tag fires on the intended action and remains silent on nearby actions that should not count.
Publish a traceable version. Record the conversion action, reason for the change, reviewer, test performed, and rollback instruction in the version description or release record.
Verify both ends. Confirm the expected firing behavior in GTM and then confirm that Google Ads recognizes the intended conversion setup. A passing browser-side test proves the trigger ran; it does not by itself prove that the account mapping is correct.

Avoid deleting the old tag before the new configuration has been verified. At the same time, do not publish two equivalent live paths and hope to compare them later. Modify the existing implementation when that is the cleanest route, or make the old and new triggers mutually controlled during the release. Your rollback should restore a known configuration, not create a second unknown one.

Operate access and tagging as one controlled release

Two specialists approve access and inspect a digital event as it passes through secure testing, monitored release, and rollback stages.

Authentication and conversion tracking are often assigned to different specialists, but they meet at the same operational boundary. The person publishing a tag needs reliable account access. The automation consuming conversion data needs a stable identity. The campaign owner needs confidence that the event still means what its name claims.

Use one release record for both sides. In a larger team, assign an access owner, GTM implementer, independent reviewer, and business owner for the conversion definition. In a smaller team, one person may hold several roles, but the checkpoints should remain separate. Pause between configuring, reviewing, publishing, and validating so that familiarity does not replace evidence.

Freeze unrelated changes. Keep other credential, container, and conversion-action edits out of the same release so a failure has a narrow set of possible causes.
Capture the known-good state. Record which automation currently succeeds, which tag and trigger currently fire, and which conversion action they serve.
Prove recovery access. Confirm that the named owner can complete a fresh user-authentication flow with MFA, or that the supported service-account workflow can be restored by its documented owner.
Stage the measurement change. Build or review the pre-filled GTM configuration without publishing it. Confirm the account, action, ID, label, trigger, and duplication check.
Run the controlled path. Exercise the actual conversion behavior and preserve enough evidence for another person to understand what was tested.
Publish and validate. Confirm the container version, the live firing conditions, the Google Ads destination, and the next successful dependent automation run.
Retire only what has been replaced. Revoke an old credential or remove an old tag only after the new path is proven and the rollback decision is documented.

Use the failure layer to choose your first check

When something breaks, identify whether the failure occurs at identity, authorization, container configuration, trigger logic, publishing, or destination mapping. Rolling back everything at once can hide the actual defect.

Symptom	Likely layer	First check
An existing API job runs, but a new connection cannot generate a refresh token	User authentication and MFA	Repeat the fresh consent flow with the named owner and confirm that the second factor can be completed.
A connection succeeds for one person but cannot be recovered by the team	Ownership and recovery	Check whether the workflow depends on one personal identity and whether a supported service-account pattern is more appropriate.
Editor, Scripts, a transfer, or a dashboard fails during sign-in	Shared authentication policy	Identify the actual Google identity behind the tool instead of treating it as an isolated application error.
The direct GTM option does not appear	Feature availability	Use the manual tag setup rather than delaying the release; the integration is being tested and may not be available in every flow.
The tag does not fire during preview	Container or trigger logic	Confirm the selected container, preview environment, trigger conditions, and exact user action.
The tag fires, but it points to the wrong conversion action	Destination mapping	Compare the conversion ID and label with the intended Google Ads action and account.
More than one tag fires for a single intended action	Duplicate implementation	Search for older tags, overlapping triggers, and parallel containers before changing the conversion definition.
The browser-side test passes, but the dependent automation fails	API authorization or workflow logic	Test the automation separately with its own identity and permissions; the GTM test does not validate API access.

At your next planned change window, exercise one fresh authentication flow and trace one controlled conversion from the user action through GTM to the intended Google Ads action. If either path lacks a named owner, test evidence, or a safe rollback, fix that gap before you scale the campaign or add another integration. Your infrastructure is ready when another authorized person can understand it, test it, and recover it without guessing.

References

April 17, 2026

Gemini Ad Safety: A Practical Google Ads Compliance Plan

Your Google Ads campaign can be commercially legitimate and still fail before its first impression. A stray phrase is no longer the only concern. Gemini-powered enforcement is designed to interpret intent across the creative, destination, account, and activity surrounding an ad.

You do not need to reverse-engineer the model. You need a campaign that remains accurate, consistent, and explainable from every angle. The following workflow will help you review campaigns before launch, distinguish a correct enforcement action from a possible mistake, and respond without creating a larger account problem.

Gemini makes policy review a pre-launch control

Google says it blocked or removed 8.3 billion ads globally and suspended 24.9 million advertiser accounts in 2025. More than 99% of the policy-violating ads it identified were stopped before they ran.

Those are Google-supplied, systemwide enforcement figures. They are not an independent audit, and they do not reveal the probability that a legitimate advertiser will be flagged. They do establish the operational reality: automated review is happening at enormous scale, and most harmful ads identified by the system never receive a live testing period.

By the end of 2025, most Responsive Search Ads were reportedly assessed instantly. You therefore cannot treat policy review as something to clean up after launch. Approval is a launch dependency, alongside tracking, budget, bidding, and landing-page readiness.

Gemini also changes what a useful review looks like. Google describes the system as better able to understand ad intent while evaluating billions of signals, including account age and user patterns. That does not mean every one of those signals determines an outcome, and Google has not disclosed a decision formula. It does mean that replacing one questionable word may not solve a problem rooted in the offer, destination, identity, targeting method, or account behavior.

There is evidence of improving precision, but not perfection. Google attributed an 80% reduction in incorrect advertiser suspensions to Gemini and said it processed four times as many user reports as in the previous year. Advertisers in the UK and US nevertheless reported waves of disapprovals they could not readily explain. The useful position is neither blind trust nor blanket suspicion: investigate the complete campaign before deciding that an enforcement action is wrong.

Policy maintenance matters as much as initial setup. Google made 35 policy updates during 2025. Add a last-reviewed date to your compliance checklist and assign someone to own it. An undated checklist quietly becomes a historical record rather than a control.

Audit the connected ad system, not just the copy

Compliance becomes difficult to diagnose when it lives only in a copywriting checklist. Treat an ad as a connected system: claim, offer, destination, business identity, targeting, and account activity must tell the same defensible story.

The following is an advertiser-side audit model, not a description of Gemini’s unpublished decision rules. Its purpose is to expose contradictions before automated review or a user report does.

Review layer	Question to answer	Evidence to retain
Ad claims	Can you prove each objective promise, price, result, qualification, or comparison as written?	Current substantiation, approval notes, and the exact qualifying language
Offer and destination	Does the landing page present the same product, entity, conditions, and user outcome as the ad?	Final URL, redirect path, and dated page captures
Business identity	Do the advertiser name, domain, billing entity, and customer-facing identity align accurately?	Current business records and a log explaining legitimate changes
Targeting and personalization	Is the audience or data practice acceptable independently of the creative?	Campaign settings, audience rationale, and applicable consent records
Account and site changes	Can an internal reviewer explain recent changes in ownership, payment, domains, tracking, or campaign behavior?	Owner, date, reason, and approval for each material change

This broader review is necessary because enforcement is not confined to offensive language. In the United States, the leading reasons associated with enforcement included abuse of the ad network, misrepresentation, sexual content, personalization violations, and dating or companionship ads. Google removed 1.7 billion ads and suspended 3.3 million advertiser accounts in the US during 2025.

Start with misrepresentation even if your business does not operate in an obviously sensitive sector. A campaign can become misleading through inconsistency rather than an outright false sentence. A headline may omit an important condition. A landing page may use a different company name. A promotion may have ended while an older asset remains eligible. A redirect may send some users to a page the campaign owner never reviewed.

Personalization deserves its own check. Compliant wording does not repair an unacceptable audience or data-use practice. Have the person responsible for targeting confirm the settings and rationale rather than asking the copywriter to approve the campaign as a whole.

If a campaign touches consumer-protection, privacy, discrimination, or another legal requirement, obtain the appropriate legal review. Google Ads approval is not legal clearance, and this operational checklist is not a substitute for advice on the law that applies to your business.

Use this pre-launch safety workflow

A useful pre-launch review produces evidence, not a vague assurance that someone looked at the ads. Run these steps after the creative and landing page are stable but before the launch depends on immediate approval.

Assign one accountable owner. Record who approved the campaign, which policy version or internal checklist was used, and the review date. Contributors can review separate areas, but one person must confirm that the pieces agree.
Inventory every eligible component. Include headlines, descriptions, images, videos, business names, extensions or assets, audience settings, final URLs, tracking redirects, and the destination users actually reach. Do not review only the combination shown in an editor preview.
Map every material claim to proof. Copy the exact claim into a review sheet, identify the evidence, and note any qualifier needed in the ad or on the destination. If no one can produce the proof, revise or remove the claim before submission.
Run a consistency check from ad to conversion. Confirm that the same advertiser, offer, conditions, geography, and expected next step appear throughout the journey. Test the final destination while logged out and on the device types the campaign targets.
Review Responsive Search Ad assets as possible combinations. Each headline and description must remain accurate when paired with other eligible assets. Do not rely on one preferred preview to supply context that another combination could omit.
Review targeting and personalization separately. Confirm who is included, what data supports that decision, and whether the practice complies with the relevant Google policy and your own obligations. Record the decision rather than relying on an undocumented verbal approval.
Freeze a launch record. Save the approved copy, campaign settings, final URLs, landing-page captures, claim evidence, and material account changes. Keep personal or confidential customer data out of this packet unless it is genuinely required and appropriately protected.

When practical, avoid combining an important launch with unrelated account, payment, domain, and tracking changes. This does not guarantee approval, but it reduces the number of variables you must investigate if something is flagged.

Use a strict pass rule: every campaign component must have an owner, the material claims must be supported, and the ad-to-destination journey must be consistent. A reviewer who is merely unsure should not mark the campaign compliant. The uncertainty needs to be resolved, documented, or removed from the campaign.

Respond to disapprovals without making the case harder

An ad disapproval and an account suspension require different responses. A disapproval gives you a bounded place to begin: identify the affected ad, asset, destination, or policy area. A suspension is an account-level incident with a greater business consequence, so preserve the evidence and control changes before anyone starts experimenting.

Stop repeated resubmission. Sending the same material again does not establish compliance and can obscure the sequence of events you need to explain.
Classify the scope. Determine whether the action affects one asset, one ad, several campaigns, a destination, or the advertiser account. Check for a shared claim, URL, audience, business identity, or recent change.
Preserve the reviewed state. Capture the exact policy label, enforcement message, affected items, URLs, page contents, account notices, and time observed. Dynamic landing pages can change while you investigate.
Read the stated policy against the whole campaign chain. Check the copy, offer, destination, identity, targeting, and account history. Do not assume the highlighted asset is the only relevant input.
Make the smallest complete correction. Change the root inconsistency and all affected instances, but avoid unrelated edits that make the before-and-after state difficult to explain.
Appeal with traceable evidence when you believe the campaign complies. State what was affected, how you evaluated the policy, what you corrected if anything, and which evidence supports your position. Keep the explanation factual and specific.
Record the outcome. Add the cause, resolution, evidence, and any checklist change to an incident log so the same pattern is caught before the next launch.

Do not route around a suspension by opening a replacement account. Apart from any policy consequences, that move fragments your records and makes a legitimate explanation harder to establish. Abuse of the ad network was already among the main US enforcement reasons in 2025. Use the authorized review or appeal path and involve the account owner responsible for business identity and billing.

Do not label an action a false positive until you have completed the connected-system audit. At the same time, do not assume automation is infallible. Google’s claimed 80% reduction in incorrect suspensions is encouraging, but an 80% reduction is not elimination, and documented advertiser complaints persisted. Your evidence packet is what lets you challenge a mistake without relying on indignation or guesswork.

A concise appeal should answer four questions: What was flagged? Which policy did you review? What evidence shows compliance or what root issue was corrected? What specific review are you requesting? Long narratives, repeated submissions, and unrelated account changes make those answers harder to see.

Key takeaways

Gemini-powered enforcement operates before delivery at enormous scale, so policy review belongs in the launch plan rather than the post-launch cleanup.
Intent-aware review makes copy-only compliance checks inadequate. Audit the offer, destination, identity, targeting, and account changes as one connected system.
Responsive Search Ads need asset-level and combination-level review because one favorable preview cannot represent every eligible message.
Google reports fewer incorrect suspensions, but unexplained disapprovals have not disappeared. Preserve evidence before editing or appealing.
The safest incident response is controlled and traceable: classify the scope, preserve the state, correct the root issue, and use the authorized appeal process.

Before your next launch, choose one scheduled campaign and run the full audit table against it. Save the evidence, name the accountable owner, and date the checklist. That single dry run will expose whether your current process can explain a Gemini-era enforcement decision or only react to one.

References

CrushPress.AI – Gemini’s AI Takes Ad Safety to New Heights: Over 99% Bad Ads Blocked

April 16, 2026

Category: Security

Your citation dashboard may be overstating visibility

Measure the four outcomes an AI answer can produce

The content earning visibility can also carry instructions

Build guardrails around inputs, tools, and side effects

Control what enters the workflow

Keep content separate from authority

Make failures observable and reversible

Key takeaways for your next reporting cycle

References

A shared Claude link is a web page, not a private message

Key takeaways

What to do if you created a Claude share link

For site owners, robots.txt is not a privacy control

Test the privacy boundary as a stranger would

References

Key takeaways

Treat authentication and certification as separate controls

Prepare new OAuth authorizations before they become urgent

Build the runbook around the credential type

Turn in-account certifications into a controlled workflow

References

Key takeaways

One manipulation pipeline, two ways to enter it

Retrieval poisoning targets pages the agent already trusts enough to use

Manufactured mentions try to reshape the same evidence environment

What the evidence establishes, and what remains uncertain

Why a cited recommendation can still be misleading

A defensible standard for platforms, marketers, and readers

Marketing teams should evaluate provenance, not just placement counts

AI systems need controls at more than one layer

Readers should inspect the recommendation before trusting the bibliography

References

Key takeaways

Identify which system locked you out

Recover access in the right order

Build a case that automated support can route

Separate personal access from business assets

Escalate safely, then remove the single points of failure

Use an escalation only when it adds a real route

Recognize the recovery scam before it compounds the damage

Harden the account as soon as access returns

References

What Web Bot Auth actually changes

Why Web Bot Auth must remain an additional signal

A safe adoption plan for your edge and application stack

Build AI-agent access rules around identity and purpose

Key takeaways and your next move

References

The dangerous unit is the campaign, not the prompt

Where repeated attempts find extra chances

Build controls that survive repeated attempts

Test the full campaign without publishing an exploit kit

Key takeaways for AI product owners

References

Define a qualified lead before Google defines one for you

Validate the signal before automated bidding scales it

Treat call recording as a governance decision

Let Ads Advisor operate, but give it boundaries

Key takeaways

References

Key takeaways

Map authentication before MFA exposes a hidden dependency

Choose user authentication or a service account deliberately

Use direct GTM setup to remove copying, not judgment

Operate access and tagging as one controlled release

Use the failure layer to choose your first check

References

Gemini makes policy review a pre-launch control

Audit the connected ad system, not just the copy

Use this pre-launch safety workflow

Respond to disapprovals without making the case harder

Key takeaways

References