8/31/2026

How B2B buyers use AI to pick vendors before sales

 

B2B buyer using an AI chat tool to compare vendors before contacting sales.

By the time a buyer books a call with your sales team, the important decision is usually already made. They have framed the problem, compared you against two or three competitors, drafted a business case, and ranked a shortlist. Much of that happened inside an AI tool you never saw, in a room you were never invited to.

If your go-to-market still treats the first sales conversation as the start of the deal, you are optimizing for a moment that no longer decides much. The evaluation that used to happen on your website and across a series of sales calls now happens earlier, faster, and mostly out of view, because buyers research vendors with AI before they raise their hand. This is the same dynamic behind B2B displacement campaigns that win before the obvious buying moment, pushed one step further back into the journey.

Is the vendor shortlist really decided before sales contact?

Yes, and the data is blunt about it. 6sense's 2025 Buyer Experience Report, a global study of nearly 4,000 B2B buyers, found that 95 percent of the time the winning vendor was already on the buyer's Day One shortlist, formed before any seller contact. The vendor a buyer prefers before engaging sales goes on to win roughly 80 percent of deals. Buyers now reach the point of first contact around 61 percent of the way through their journey, and when they do reach out, they contact their preferred vendor first.

The implication is uncomfortable but clarifying: your sales team is mostly confirming a decision, not creating one. Kerry Cunningham, who leads research at 6sense, said the urgency for revenue teams is to "influence those early journeys before buyers reach out." By the time the demo is booked, the ranking already exists. You are either at the top of it or explaining why you should be.

 

B2B buying journey showing vendor research and shortlist formation before first sales contact.

 

How do B2B buyers use AI to research vendors?

They use it to do the work a salesperson used to do. Forrester's 2026 Buyers' Journey Survey, covering nearly 18,000 global business buyers, found that 94 percent used generative AI during their purchase, up from 89 percent a year earlier. More striking, twice as many buyers named generative AI and conversational search as their most meaningful research source than named any other, ahead of vendor websites, product experts, and sales reps.

Look at what they do inside those tools. Forrester reported that a majority now compare vendors and research products in AI before contacting anyone, and nearly half build their internal business case there too. G2's 2025 buyer research put generative AI chatbots as the single most influential source for building a shortlist, ahead of review sites, vendor websites, and peer recommendations. The comparison table you hoped a prospect would study on your site is now generated on demand by a model, using whatever it can find and trust about you.

This is the practical cost of sitting out, and it is why treating "we don't use AI" as a neutral position is already a losing one. Your absence from those answers is not neutral. It is a vote for your competitor.

Why this breaks the MQL scoreboard

Most B2B teams still measure marketing by form fills and lead volume. That scoreboard now tracks the wrong game. Gartner's research on the buying journey found that buyers spend only 17 percent of their total purchase time meeting with potential suppliers, and when they are comparing several vendors, as little as 5 to 6 percent with any one of them.

So the leads in your funnel represent a sliver of the journey, and often the least decisive part. If 95 percent of winners were already shortlisted on Day One, your MQL report is largely counting deals whose outcome was set before the form was filled. Lead volume has become a lagging, partial signal, while the decisive activity happens in the anonymous research phase your CRM will never log.

Does AI decide the deal, or just start it?

Here is where the hype overshoots, and where the real opportunity sits. AI builds the shortlist and picks the early frontrunner, but it does not close the sale on its own. Gartner found that even as buyers lean on AI, 69 percent still turn to a sales rep to validate the AI-generated insights they gathered, and they consult around seven sources before deciding. Forrester found that a fifth of buyers felt less confident in a decision after using generative AI, because they hit unreliable or conflicting information.

That gap is your opening. Preferences formed early are not always locked. A regional 6sense and MarketOne study of buyers in the UK and Ireland found that about a third shifted their top choice during the validation phase, the highest movement of any region measured. The frontrunner has the advantage, not a guarantee. Two moves follow. Get into the shortlist during the research phase, and equip your sales team to validate and de-risk rather than repeat what the model already said. A rep who adds nothing beyond the AI summary gives the buyer no reason to move you up.

How do you get on the AI shortlist?

You earn a place the same way you earn an AI citation: by being the source models can find, trust, and quote. That work is concrete.

  • Publish content that answers the comparison and fit questions buyers actually ask, in clear, extractable language a model can lift into an answer.
  • Back claims with evidence and specifics, since models and buyers both discount vague marketing copy.
  • Show up on the third-party sources buyers and models trust, including review platforms and credible communities, not only your own domain.
  • Close the information gaps that push a buyer elsewhere, especially the technical and capability detail competitors may be hiding behind a form.

This is where answer engine and generative engine optimization stop being a traffic tactic and become a sales strategy. If you have mapped how SEO, AEO, and GEO work as one system, this is the commercial payoff: visibility in the answers where shortlists are now built. Being the vendor the model recommends is the new version of being the vendor the analyst recommended.

Frequently asked questions

Do B2B buyers really choose a vendor before talking to sales?

Mostly, yes. 6sense's 2025 study of nearly 4,000 buyers found the winning vendor was already on the Day One shortlist 95 percent of the time, and the pre-contact favorite won about 80 percent of deals. Sales tends to confirm the decision rather than originate it.

How many B2B buyers use AI to research vendors?

Forrester's 2026 survey of nearly 18,000 buyers found 94 percent used generative AI during their most recent purchase, up from 89 percent the year before, with generative AI and conversational search named the most meaningful research source by twice as many buyers as any other option.

Has AI made B2B sales cycles shorter?

On average, yes. 6sense found the typical cycle compressed from 11.3 months in 2024 to 10.1 months in 2025, driven by faster AI-assisted research rather than less of it. Buyers move quicker but do not take on more risk.

Can you still win if you are not the Day One favorite?

Sometimes. Preferences can shift during validation, and one regional study saw about a third of buyers change their top choice late in the process. The odds favor the frontrunner, so the goal is to enter the shortlist early and give buyers a reason to reorder it.

What should you measure instead of lead volume?

Track your presence and framing in AI answers for your category, whether you make buyer shortlists, and pipeline sourced from the research phase your analytics cannot see directly. Pair those with buyer self-reporting to catch influence that never shows up as a clean referral.

Win the room you cannot see

The most important sales meeting in a modern B2B deal is one you will never attend. It happens between a buyer and a model, weeks before anyone books a call, and it decides who makes the shortlist and who leads it. You cannot sit in that room. You can shape what is said about you in it.

That means building content the AI can find, cite, and trust, closing the gaps that send buyers to competitors, and repositioning sales as the team that validates and de-risks a decision rather than the one that starts it. The vendors winning now are not the ones with the sharpest closers. They are the ones already recommended before the conversation begins.

Getting picked early is the whole game. Build for the shortlist, because that is where the deal is decided.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

8/25/2026

AI Is Writing Your Code and Leaking Your Secrets

 

Developer reviewing AI-generated code containing a hardcoded API key and potential secret exposure.

I use AI to write code, and I am not giving it up. Neither should your engineering teams. Teams are adopting AI assistance to ship faster, and that shift is not reversing. That is exactly why the security problem underneath it deserves a clear look. AI-assisted development can introduce hardcoded secrets and expand the number, privilege, and reach of the non-human identities working across your delivery pipeline. Most organizations are not governing either one, and that gap is where the next wave of breaches is forming.

None of this argues for slowing down. It argues for governing what AI-assisted development creates, so the speed you gained does not turn into exposure you never priced in.

The risk is not one thing. AI-assisted development expands risk in three connected but distinct places. The generated code can carry security defects. Prompts, repositories, logs, and output can expose credentials, in both directions. And the agents reaching your source control, cloud services, and data need identities with carefully bounded permissions. A secret scanner does not fix an over-permissioned agent, and least privilege does not catch insecure application logic. You have to govern all three.

Diagram showing AI-generated code risk, secret exposure, and non-human identity risk in AI-assisted development.

 

How does AI-assisted development expose secrets?

AI-assisted development exposes secrets because the models reproduce the patterns they learned from, and public code is full of hardcoded credentials. When an assistant generates a working example, it can embed an API key, a connection string, or a token directly in the code, especially when the prompt, the repository context, or the surrounding code already normalizes that pattern. The code runs. The secret can ship.

The data released in 2026 shows how fast this grew in 2025. GitGuardian's State of Secrets Sprawl 2026 counted more than 28 million new hardcoded secrets in public GitHub commits during 2025, a 34 percent jump and the largest single-year rise on record. Leaks tied to AI services rose 81 percent in a single year. In the same analysis, commits co-authored by one popular assistant, Claude Code, exposed secrets at 3.2 percent against a 1.5 percent baseline across all public commits. GitGuardian is careful about that number, and so am I. The leak still runs through a human workflow. Developers decide what to accept, edit, or push. The tool did not fail. The process around it did.

Two forces compound the problem. AI increases code volume and change velocity, which makes manual-only review less reliable as the primary control. And the exposure runs in both directions. An assistant can write a secret into code, and a developer can hand one to the assistant, pasting a production log, a config file, or an error trace full of tokens into a prompt. GitGuardian found that roughly 28 percent of secret incidents now originate outside code repositories entirely, in places like Slack, Jira, and Confluence, where credentials get shared during urgent troubleshooting. Any policy that governs only the code misses half the problem.

None of that is a reason to stop. It is a reason to assume AI-assisted work may contain secrets until a scan proves otherwise, and to govern both what the tools can reach and what people can submit.

Every AI coding agent needs a governed identity

Here is the part that sits squarely in my field. AI-assisted development is not only a code problem. It is an identity problem.

Every AI agent that reaches your environment does so through one or more non-human identities: a service account, an OAuth client, an API key, a certificate, or a short-lived token. A coding assistant, a build agent, a deployment bot, each authenticates as something, and the more work you hand it, the more entitlements it accumulates. In agentic and multi-agent workflows, one orchestrator can create or delegate to additional agents, multiplying credentials and audit paths as it goes.

AI agents and enterprise systems connected through governed non-human identities and controlled access.

 

This is not a fringe concern. Reports through 2026 put non-human identities at anywhere from around fifty to one hundred times the number of human identities in cloud-heavy environments, with the exact ratio depending on what gets counted. The World Economic Forum has called non-human identities the new frontier of agentic AI risk, and analysts increasingly treat AI agents as a distinct identity type that is neither fully human nor fully machine. I covered the governance side in Non-Human Identities and AI Agents: The New Blind Spot in Your IAM Program, and AI-assisted development is where that blind spot turns operational.

The risk is not limited to the code an assistant suggests. Once an agent can read a repository, call tools, open tickets, invoke CI/CD, or connect through a Model Context Protocol server, it becomes an execution path into the enterprise. GitGuardian found more than 24,000 secrets sitting in Model Context Protocol configuration files on public GitHub, a pattern the setup instructions themselves often encourage. Add prompt injection delivered through a README, an issue, or a dependency's documentation, and the agent's permissions, allowed tools, and data boundaries need the same design discipline you give any privileged workload.

The uncomfortable pairing is this. AI writes code that leaks the very secrets these identities depend on, inside a system where the identities themselves are barely governed. Leaked credential, meet ungoverned identity. That is the attack path.

The productivity is real, so protect it

I want to be direct about where I stand, because the headline can read the wrong way. I am not arguing against AI-assisted development. I am arguing for keeping it.

The teams shipping with AI assistance are faster, and that advantage is not going back in the box. Telling engineers to slow down is both futile and wrong. The organizations that win will adopt aggressively and govern deliberately, and those two things are not in tension. Security is not the brake on AI development. It is what lets you keep your foot on the accelerator without wrapping the car around a tree.

Consider how a mature enterprise already treats any third-party dependency. You do not refuse open-source libraries because some carry vulnerabilities. You scan them, track them, patch them, and keep shipping. AI-generated code deserves the same posture. Treat it as untrusted input from a very fast contributor, verify it, and move on. That is not skepticism about AI. It is how you make AI safe to rely on at scale.

How do you secure AI-assisted development without slowing it down?

You secure it by governing the two things AI development produces, code and identities, with controls that run at machine speed instead of human speed. The goal is not more meetings. It is automation that keeps pace with the tools creating the risk.

A practical program rests on a few moves:

  • Scan for secrets continuously, in the pipeline and beyond it. Run detection on every commit and every AI-assisted change, and extend it to the tickets, chat, and logs where secrets also land. Removing a key from code is not enough, since it can be recovered from history, so rotate or revoke it too.
  • Give every agent its own scoped identity. No shared keys, no borrowed service accounts, outside narrow legacy exceptions you document and monitor. Each agent gets a named identity with least-privilege access to only what its task requires.
  • Prefer short-lived, dynamically issued credentials. Replace long-lived static keys with tokens that expire in minutes where the platform supports it. A leaked credential that has already expired is close to a non-event.
  • Keep an owned inventory of non-human identities. Every agent and service account needs a human owner, a documented purpose, and a decommission date. Unowned identities are where risk hides.
  • Treat AI output as an untrusted contribution, and do not stop at review. Apply the same supply-chain controls you use elsewhere: dependency and infrastructure-as-code scanning, branch protections, code-owner review for anything touching authentication, authorization, cryptography, payments, data access, or deployment, and an audit trail that ties each material change to a user, an agent, and an identity.

These controls shift the security work from a late, manual gate to an early, automated one, which is the only model that survives contact with AI-speed development. Integrated into developer workflows, they cut late-stage rework instead of adding a release bottleneck, and they keep most of AI's delivery advantage while slashing the cost of remediation.

Detection without revocation is not remediation, and the data proves it. GitGuardian retested credentials it first confirmed valid in 2022 and still found more than 64 percent of them live in 2026. When a secret surfaces, rotate or revoke it, trace where it was used, assess what it could reach, and fix the control at the point it entered the workflow.

Where you sit on this path matters more than doing everything at once:

Stage Minimum standard
Pilot Approved tool list, no production secrets in prompts, user-level attribution, basic secret scanning
Team rollout SSO and SCIM, repository and data-access boundaries, CI secret scanning, branch protections, named owners for service accounts
Enterprise scale Short-lived federated workload identity, centralized secrets management, agent and tool allowlists, full audit logging, revocation workflows, continuous entitlement review

This is also where the commercial conversation lives, and it is rarely a technical failure that stalls these programs. It is that the person who sees the risk cannot translate it into a consequence the budget holder acts on. I worked through that exact dynamic in Why Identity Risk Loses the Budget Conversation, and it applies directly here. Frame AI governance as protecting the productivity leadership already values, and you get funded. Frame it as a brake, and you do not.

I write about where identity security and commercial strategy meet, because in AI-assisted development they are the same conversation. If your organization is working through this, connect with me on LinkedIn.

Frequently asked questions

Is AI-generated code less secure than human-written code?

Not inherently, but it should not be presumed secure. Results vary by model, prompt, language, task, and review process. A 2026 study across six leading models reported confirmed vulnerabilities in about a quarter of generated samples, while earlier research on one popular assistant found security weaknesses in roughly 40 percent of the scenarios tested. Those figures need their methodology to mean anything, and they do not add up to a universal defect rate. The operational answer is to test and review AI output under the same controls, or stronger ones, that you apply to any untrusted contribution.

What is a non-human identity in AI development?

It is the identity assigned to software, a workload, a service, a bot, a pipeline, or an AI agent, so it can authenticate and act without an interactive human login. Its authenticator might be a service account, a workload identity, an OAuth client, a certificate, an API key, or a short-lived token. The governance questions that matter are who owns it, what it can access, how long it lasts, how its activity is logged, and how it gets revoked.

Can developers paste production code or error logs into a coding assistant?

Only if your organization has approved the tool, understands its data-handling terms, and has defined what may be submitted. Production secrets, customer data, private keys, and regulated information should be blocked or redacted before they reach a prompt. The same policy should cover repository-context features and tool integrations, not just the chat box.

What should happen when a secret shows up in AI-assisted code?

Treat it as an incident, not a text edit. Revoke or rotate the credential, determine whether it was used, assess the access it carried, remove it from active code and configuration, and add or tune the control that should have caught it before production.

How do we let developers use AI without creating security debt?

Automate the controls so they run at the speed of the tools. Scan every change and channel for secrets, scope each agent to least privilege, expire credentials quickly, and review AI output like any third-party dependency. That keeps the productivity while closing the exposure.

The speed is worth keeping

AI-assisted development is one of the most significant productivity shifts enterprise engineering has seen, and the organizations leaning into it are right to. The mistake is treating the speed as free. It arrives with generated code that needs verifying, secrets that need detecting and rotating, and machine identities that need scoping, ownership, and observation, and the companies that build those habits early will keep their advantage while others clean up breaches they could have prevented.

AI is writing your code, and yes, it can leak your secrets. That is a solvable problem, and solving it does not mean making developers wait. Make secure behavior the default: credentials injected at runtime instead of written into code, short-lived access instead of permanent keys, and automated checks that catch problems before production. Govern the identities, protect the context, scan the code and the secrets, and let your teams keep building at the speed the tools finally made possible.


Navneet Lounsberry writes on cybersecurity compliance and commercial strategy, most recently with Idenhaus Consulting. She spent more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.


 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

8/21/2026

How to Measure AI Search Traffic in 2026

 

AI search traffic splitting across Direct, organic, referral, and other analytics channels.

You put in the work to get cited by AI. You structured your content for extraction, answered the questions buyers actually ask, and started showing up in ChatGPT and Google's AI Overviews. Then you open Google Analytics, filter for those sources, and find a dozen sessions. The natural conclusion is that the channel is too small to matter.

That conclusion is probably wrong, but not for the reason you might guess. AI search traffic is not one clean channel you can read off a single report. AI-driven demand is usually larger than the AI referrals visible in analytics, yet no report can say how much larger. Some clicks keep an AI referrer and can be measured. Others lose their source, or influence a visit that returns days later through Direct or branded search. The problem is not that all AI traffic is hidden. It is that AI influence is scattered across several reporting buckets, and most teams try to read it as one number.

This is the measurement gap left open by the shift to answer engines. If you have already worked through how SEO, AEO, and GEO function as one connected strategy, this is the reporting problem sitting underneath all three. Getting cited is half the job. Measuring it honestly is the other half, and most teams miss in one of two directions: ignoring the channel, or crediting it for everything they cannot otherwise explain.

 

Analytics dashboard showing unidentified AI-influenced sessions appearing within Direct traffic.

Three things people lump together as AI search traffic

Before you measure anything, separate three ideas that are not the same:

  • AI-referred traffic is a session that arrives with an identifiable AI source, such as a referral from chatgpt.com.
  • AI-influenced traffic is a buyer who met your brand inside an AI answer, then returned later through Direct, branded search, email, or a bookmark.
  • AI visibility is an appearance or citation in an AI answer that may create awareness without ever producing a click.

These do not add into one precise figure, and pretending otherwise is where most AI reporting goes wrong. Report them as separate signals, not a single invented total.

Why can AI-influenced visits appear as Direct traffic?

Some AI-driven visits arrive without a usable referrer and land in Direct, most often in app and in-app-browser flows where the referrer is stripped or never passed. But Direct is not an AI bucket. In GA4, Direct means the session had no clear referral source, which also covers typed URLs, bookmarks, untagged campaign links, redirects, and privacy or consent signal loss.

That distinction cuts both ways. Assume none of your Direct traffic is AI and you undercount the channel. Assume all of it is AI and you fool yourself with a number you cannot defend. Direct is an attribution gap to investigate, not a proxy for ChatGPT.

Google's own AI surfaces sit in a different blind spot. GA4 still cannot reliably isolate AI Overview and AI Mode sessions as their own acquisition source, because the click passes through a google.com URL and reads as ordinary organic. As of 2026, though, that is no longer the whole story, and the fix lives in a different tool.

Diagram showing AI referrals, Google AI clicks, and delayed visits entering different analytics channels.


Is AI search traffic worth measuring if it is only 1% of visits?

Yes, because the value per visit can be far higher than its share of volume. Visible AI referrals are small today. Conductor's benchmark of 13,770 domains put them at 1.08 percent of total traffic on average, and that is visible referrals, not all AI influence.

Several case studies suggest that small slice punches above its weight. Semrush's study, We Studied the Impact of AI Search on SEO Traffic, found the average AI search visitor from a non-Google source such as ChatGPT was 4.4 times as valuable as a traditional organic visit, measured by conversion rate. Ahrefs, analyzing its own site, reported AI search at 0.5 percent of traffic but 12.1 percent of signups. Seer Interactive, looking at a single client, measured ChatGPT referrals converting at 15.9 percent against 1.76 percent for Google organic.

Read those as signals, not laws. They come from different businesses, funnel stages, and definitions of a conversion, and at least one analysis found no significant difference at all. The thread that holds is intent: a buyer who clicks through from an AI answer has often had the category summarized and the options shortlisted already, so the click lands closer to a decision. That makes AI referrals disproportionately valuable in some high-consideration and B2B journeys. Whether they beat your paid, email, or branded-search cohorts is something only your own numbers can settle, on one conversion definition.

How do you measure AI search traffic?

You measure it as a system of partial views, because no single report captures the whole thing. Four layers cover most of what you need.

Isolate the AI referrals you can see

In GA4, build a custom channel group rather than editing the default, and classify by session source or session source and medium. A few specifics decide whether it works:

  • Group known AI domains such as chatgpt.com, perplexity.ai, claude.ai, gemini.google.com, and the Copilot domains, and confirm them against your own raw source data rather than copying a generic list.
  • Place the AI rule above generic Referral in the channel-group priority, or Referral will swallow it first.
  • Report outcomes, not just sessions: engaged sessions, key events, qualified leads, and pipeline, plus the landing pages those referrals hit.

Before you declare a large hidden-AI problem, rule out the ordinary causes of inflated Direct first: confirm GA4 fires once, audit cross-domain and consent setup, and tag your own campaign links. A clean attribution baseline is what makes the AI signal trustworthy.

Use Search Console for Google's AI surfaces

Google Search needs its own lane. On June 3, 2026, Google launched a dedicated Generative AI performance report in Search Console that separates impressions in AI Overviews and AI Mode from standard organic results, broken out by page, country, and device. It answers a question GA4 cannot: whether your URLs actually appear in Google's AI answers.

Read it for what it is. The report shows impressions only, no clicks or conversions, and is rolling out to a subset of properties. It also covers Google Search alone, so it says nothing about ChatGPT, Perplexity, or Claude. Use it as a visibility gauge, then turn to GA4 and CRM data for impact. An impression report is not a revenue report.

Ask buyers what analytics cannot see

Self-reported attribution reaches the influence your tools miss by design, including zero-click and cross-device paths. Split discovery from evaluation: ask where someone first heard of you, then, separately, what they used to evaluate you. A buyer may first meet you in Google, compare vendors in ChatGPT, and convert through branded search, and one forced-choice field erases that path. Self-report depends on memory, so treat it as one of the few ways to catch delayed AI influence, not as proof.

Track citation share as a leading indicator

Citation is the earliest signal, moving before traffic and revenue do. Define it plainly: citation share is the portion of your tracked prompts in which your brand or domain appears. Send the questions your buyers ask to the major models on a schedule and watch the trend against competitors. The caveat is real: results depend on the prompt set, the model version, location, and the tool sampling them, so read citation share as a directional indicator, not a promise of pipeline.

Run the four together and you get triangulation instead of a false total. Referral data shows a conservative floor, Search Console shows Google AI visibility, self-report fills the invisible middle, and citation share tells you where things are heading.

Four-layer framework measuring AI referrals, Google AI visibility, buyer self-report, and citation share.

When should you evaluate AI-search ROI?

Set expectations as a cadence, not a countdown. There is no universal timeline, because indexing, sales-cycle length, content maturity, and model updates all move it. What holds up is a review rhythm.

Document a baseline now: citation visibility, identifiable AI referrals, the landing pages involved, conversions, and branded-search demand. Check source and landing-page trends monthly, and assess qualified pipeline and revenue quarterly, which matters most for longer sales cycles. For planning, many teams read early citation and traffic movement at 60 to 90 days and judge pipeline at 3 to 6 months, but treat those as observation points, not guarantees.

This is the same patience the systems demand elsewhere, and it connects to why AI content rankings settle only after an early climb. The models take time to trust a source. Your reporting has to give them that time before you call the outcome.

Frequently asked questions

Why is my ChatGPT traffic showing as Direct in Google Analytics?

A ChatGPT visit can land in Direct when the click reaches your site without a usable referrer, which is common in app flows. But Direct is not an AI-only bucket. GA4 defines it as traffic with no clear referral source, so it also holds bookmarks, typed URLs, untagged links, and sessions where privacy or redirect issues stripped the source. Treat Direct as an attribution gap to investigate, not a stand-in for AI traffic.

Can you track traffic from Google AI Overviews and AI Mode?

Not cleanly in GA4, where those clicks read as ordinary Google organic. Since June 3, 2026, Search Console has a dedicated Generative AI report that shows how often your URLs appear in AI Overviews and AI Mode. It measures impressions only, with no clicks or conversions, and covers Google Search alone. Use it for visibility, then use GA4 and CRM data for business impact.

Does AI search traffic convert better than organic search?

Often, especially in high-consideration journeys, but it is not a universal rule. Ahrefs reported AI search at 0.5 percent of its traffic and 12.1 percent of signups, and Seer Interactive reported far higher ChatGPT conversion than Google organic for one client. Compare AI referrals against your own organic, paid, email, and branded-search cohorts using one conversion definition before you conclude anything.

What tools measure AI search visibility?

Search Console covers Google's AI surfaces. For ChatGPT, Perplexity, and others, citation trackers such as Profound, Peec AI, and Semrush's AI visibility features record how often you appear across prompts. Pair any of them with GA4 and a self-reported lead-source field, since no single tool captures the whole channel.

How much of my traffic should come from AI search?

There is no universal target. Conductor put visible AI referrals at 1.08 percent of traffic across 13,770 domains, and that is visible referrals, not total AI influence. Set goals around outcomes instead: citation coverage for your priority questions, the conversion rate of identifiable AI referrals, and AI-influenced leads and revenue.

Measure the channel as a system, not a line item

The teams losing ground in AI search are rarely the ones getting cited least. Often they are getting cited and never know it, because their analytics filed the evidence under Direct. The opposite error costs just as much: crediting the channel for every unexplained visit and building a story you cannot defend. Both come from treating AI search as a single number.

It is not one. AI-driven demand is fragmented across visible referrals, Google AI visibility, delayed brand searches, self-reported discovery, and CRM outcomes. Measure each on its own terms, clear the ordinary attribution problems first, and give revenue the months it needs to surface. Do that, and a channel that looked like noise becomes one you can defend in a budget meeting and grow on purpose.

Getting found by AI is the work of the last two years. Measuring it honestly, and improving it, is the work of the next one.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

8/13/2026

CMMC Phase 2 Paused: Why the Work Should Not Stop

Defense contractor reviewing CMMC readiness, NIST 800-171 controls, and SPRS status on a manufacturing shop floor.



On July 13, 2026, the Department of Defense suspended Phase 2 of the Cybersecurity Maturity Model Certification (CMMC) program and opened a 60-day review. Within hours I heard the same reaction across the defense industrial base: good, now we can slow down.

That reading is wrong, and it will cost the contractors who believe it. The Department paused one mechanism. It did not lift a single security obligation. If your contracts require you to protect controlled unclassified information, your legal duties today look exactly as they did on July 12.

Here is what actually changed, what did not, and why the contractors who keep moving will hold the advantage when the assessors return.

What did DoD actually suspend?

DoD suspended Phase 2 of the CMMC rollout, the stage that would have required many contractors handling CUI to pass a third-party assessment as a condition of award. That requirement was scheduled to take effect on November 10, 2026. A new CMMC Reform Task Force, reporting to the DoD Chief Information Officer, now runs a review of the program, with contractor input collected through a request for information due August 14, 2026.

Two distinctions matter here. First, the suspension targets Phase 2 of the rollout, not CMMC Level 2 itself. Level 2 remains the security tier that applies to most contractors who handle CUI. Second, Phase 1 self-assessment requirements stay fully in place. The Department kept the self-attestation layer running and removed only the outside audit.

Is CMMC cancelled?

No. The Department paused a verification step. It did not repeal a rule. The CMMC Program rule at 32 CFR Part 170 and the DFARS acquisition clauses remain on the books, and unwinding either one would take formal rulemaking measured in months. Officials have not ruled out larger changes, but nothing in the July memo removes an existing requirement.

Treat CMMC as the checking mechanism, not the standard. The standard came first, and it still governs your program.

What has not changed for defense contractors

This is the part the headlines miss. Several obligations survived the suspension untouched.

  • DFARS 252.204-7012 still applies. This clause has required contractors and subcontractors that handle covered defense information to implement the 110 controls of NIST SP 800-171 since 2017, and to report cyber incidents within 72 hours.
  • Your NIST SP 800-171 self-assessment still counts. You calculate a score against the 110 requirements and keep it current.
  • Your SPRS score is still live. Every prime and contracting officer you work with can see it, and it factors into your eligibility for award.

Enforcement did not pause either. The Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) continues to run reviews, and the Department of Justice continues to pursue False Claims Act cases tied to inaccurate cybersecurity attestations. With no third-party assessor checking your work first, an overstated SPRS score now carries more personal exposure, not less.

Contractors that serve both defense and civilian agencies get no reprieve at all. The duty to protect sensitive federal information reaches beyond CMMC, so a pause on one program does not clear the wider requirement.

Timeline showing DFARS 7012, CMMC Phase 1, the July 2026 Phase 2 pause, and continuing NIST 800-171 obligations.

Why pausing your compliance program is a commercial mistake

I spent two decades selling enterprise technology, and I learned early that timing beats intensity. The contractors who treat this pause as schedule relief rather than permission to stop will convert it into a market position.

Look at the math behind the assessment bottleneck. More than 100,000 companies in the defense industrial base need an assessment, and roughly 100 authorized third-party assessor organizations exist to perform them. A 60-day review does not close a gap that wide. When the requirement returns, and the underlying rule suggests it will in some form, the queue will favor the companies that stayed ready.

There is a business development angle that compliance teams sometimes overlook. Primes vet their subcontractors on cyber posture before they award work. A current, defensible SPRS score is a sales asset. It signals that you can hold CUI without becoming the weak link in a bid. Let that score go stale during the pause, and you hand a competitor a reason to take the flow-down.

I write about this intersection of cybersecurity compliance and commercial strategy because the two decisions are rarely separate. If this is the conversation you are having inside your own organization, connect with me on LinkedIn.

What defense contractors should do now

The right response to a pause is steady progress, not a full stop. A practical posture for the review period looks like this.

  • Keep your evidence current. Configuration records, scan results, and POA&M updates you collect now will count under any assessment model the task force designs.
  • Refresh your SPRS score. A stale score is a contract risk today, suspension or not.
  • Close your open POA&M items on the original timeline. Remediation you schedule now lands well before assessors return.
  • Confirm your CUI boundary. Know which systems touch covered defense information, and keep that scope documented.
  • Watch for a class deviation or a DFARS amendment. A memo changes discretion. Only a rule change moves the law, so track the formal record rather than the headlines.

This is the operational discipline I described in CMMC in the Plant, Not the PowerPoint, where compliance lives on the shop floor instead of in a slide deck. The pause does not change that. It rewards the companies that already built the habit.

Frequently asked questions

Is CMMC going away?

No. The Department suspended Phase 2 of the rollout and launched a review. The CMMC Program rule and the DFARS clauses remain in effect, and removing them would require formal rulemaking.

Do I still need to meet NIST SP 800-171 during the pause?

Yes. If your contract includes DFARS 252.204-7012 and you handle covered defense information, you still implement all 110 controls of NIST SP 800-171 and maintain your System Security Plan.

Do I still have to post an SPRS score?

Yes. Self-assessment and SPRS score posting remain mandatory. Your score stays visible to primes and contracting officers throughout the review.

When will CMMC Phase 2 resume?

No firm date exists. The task force review runs on a 60-day clock, and the Department has not committed to a restart date. Plan for the requirement to return rather than disappear.

Can enforcement still happen while Phase 2 is paused?

Yes. DIBCAC reviews and False Claims Act enforcement continue. An inaccurate self-attested score carries real legal exposure with no third-party assessor in the loop.

The bottom line

The CMMC Phase 2 pause is a shift in schedule, not a change in what the government expects you to protect. The rule stands, the DFARS clauses stand, and your self-assessment still speaks for you every time a prime checks your posture. Contractors who read the memo as a stop sign will lose ground to the ones who read it correctly, as time to get further ahead.

Use the window. Keep your controls live, keep your score honest, and keep your program moving. When the assessors come back, and the structure of the program suggests they will, readiness will separate the companies that win defense work from the ones still explaining why they waited.


Navneet Lounsberry writes on cybersecurity compliance and commercial strategy, most recently with Idenhaus Consulting. She spent more than twenty years in enterprise technology sales and business development with IBM, SAP, and others.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

7/23/2026

Why Identity Risk Loses the Budget Conversation

 

Identity architecture diagram beside an executive budget spreadsheet, connected by a broken line representing the funding gap.

By Navneet Lounsberry


 

In May 2026, Verizon published the nineteenth edition of its Data Breach Investigations Report. For the first time in the report's history, stolen credentials lost the top spot as the leading initial access vector. Vulnerability exploitation climbed to 31 percent. Credential abuse dropped to 13 percent, down from 22 percent the year before.

I watched that finding travel through the market in about a week. Vendors repositioned. Analysts wrote it up. And somewhere in a budget review, a finance leader pulled up the headline and asked a reasonable question: if identity attacks are falling, why does the identity program need more money this year?

The security team in that room knows the answer. Verizon tracked credential abuse across the full breach chain, not just the front door, and found it present in 39 percent of breaches. The report also introduced a new pretexting category that absorbed some of what previously counted as credential abuse. The headline describes first contact. The 39 percent describes what attackers actually do once they arrive.

Knowing that answer and delivering it are two different skills. Most security teams have the first one. Fewer have the second. That gap explains more stalled identity programs than any technical shortcoming I have seen across twenty years of enterprise selling.

Why does identity security lose the budget conversation?

Identity security loses budget conversations because practitioners describe risk in architectural terms while executives allocate money in consequence terms. The technical description is correct. It simply does not answer the question the person holding the budget is actually asking.

A security architect says the organization runs password hash synchronization with a single Entra Connect server that sits outside the Tier 0 management boundary. Every word of that carries meaning. None of it tells a CFO what breaks, what it costs, or what happens if the company does nothing for another year.

This is not a communication failure in the soft sense. It is a translation failure with a measurable price. Programs that never get funded never reduce risk, and the exposure compounds quietly while the architecture documentation gets more accurate every quarter.

The identity bridge shows the problem clearly

The clearest example I know sits in almost every large hybrid environment: the connection between on-premises Active Directory and Microsoft Entra ID.

What is the identity bridge?

The identity bridge refers to the components that link on-premises identity to cloud identity. In most Microsoft environments that means Entra Connect synchronization servers, pass-through authentication agents, and Active Directory Federation Services where organizations still run federation.

Microsoft does not treat these components casually. Its own documentation classifies Entra Connect servers, AD FS, Entra application proxy, and Active Directory Certificate Services as Control Plane assets, the tier formerly called Tier 0, alongside domain controllers themselves. Microsoft recommends restricting administrative access to these servers to tightly controlled groups, denying NTLM authentication to the Entra Connect server, and hardening the platform to the same standard applied to the directory it serves.

The reasoning is direct. Entra Connect holds privileged access to both sides. It reads objects from Active Directory using a connector account and writes synchronized objects into Entra ID using a dedicated service account. In password hash synchronization deployments it reads Kerberos hash material from the directory. Anyone who controls that server controls the credentials of every synchronized account.

Diagram showing the hybrid identity bridge between on-premises Active Directory and Microsoft Entra ID through a Control Plane.

Why do attackers target the identity bridge?

Attackers target the bridge because compromising it converts a local foothold into complete access across both environments, and because the resulting access looks legitimate.

Golden SAML illustrates this better than any other technique. CyberArk Labs first described the attack in 2017. An attacker who obtains the private key of an AD FS token-signing certificate can forge authentication assertions for any user, in any role, against any application that trusts that federation service. The forged token validates correctly against the public key. Multifactor authentication does not apply, because no authentication actually occurs. Conditional Access policies do not apply for the same reason. The relying party cannot readily distinguish the forged assertion from a genuine one.

This is not theoretical. The threat actor behind the SolarWinds intrusion used exactly this technique in the wild, compromising SAML signing certificates and minting valid tokens to reach hosted resources including email. Mandiant documented the technique in further detail in 2021, and its researchers recently found that manual certificate rotation can silently leave active signing keys recoverable from Machine DPAPI, meaning organizations that believed they had rotated remained exposed.

Read that sequence carefully. An attacker who reaches one server bypasses every identity control the organization purchased, and does it in a way that generates authentic-looking activity.

Why does the bridge stay underfunded?

Here is where the commercial problem shows up. The technical case for protecting the identity bridge is overwhelming and publicly documented by the vendor itself. The work still does not get funded, for four reasons that have nothing to do with architecture.

  • Nobody senior owns it. The sync server usually belongs to a Windows infrastructure team that reports through IT operations, not security. It sits between two org charts and appears fully in neither.
  • No compliance framework names it. Auditors ask about MFA, access reviews, and privileged accounts. Few ask whether the synchronization server carries a Control Plane hardening standard, so the finding never appears on the remediation list that drives spending.
  • It never fails loudly. A misconfigured firewall causes an outage. An underprotected sync server runs perfectly for years, right up until it does not.
  • It has no business name. Executives fund things they can name. "Entra Connect hardening" is not something a board member can repeat to a peer.

That last point matters most. Budget follows narrative, and the identity bridge arrives without one.

How do you translate identity risk into business language?

Translation is a discipline, not a personality trait. Three moves do most of the work.

Name the consequence, not the mechanism

Executives do not need to understand token forgery. They need to understand what an attacker gains and what the organization loses.

Compare two descriptions of the same risk. The first: an attacker with administrative access to the AD FS server can extract the token-signing certificate and forge SAML assertions that bypass Conditional Access. The second: one compromised server lets an attacker log in as our CFO, from anywhere, without a password, and our multifactor investment does not stop it.

Both statements are true. Only one of them ends with someone asking what it would take to fix.

I want to be precise about what this is not. Translation does not mean simplifying until the claim stops being accurate, and it does not mean reaching for fear. Buyers eventually catch overstated risk, and the credibility loss outlasts the deal by years. The goal is to state the real consequence in the vocabulary of the person deciding.

Attach the risk to something leadership already funds

Unnamed risk competes badly. Risk attached to a funded priority competes well.

Nearly every enterprise currently runs a cloud migration, an ERP program, a merger integration, or a compliance deadline with executive attention behind it. The identity bridge sits underneath all of them. A migration that synchronizes identities into a cloud tenant depends entirely on the integrity of that synchronization. A defense contractor working toward CMMC assessment cannot demonstrate access control over systems where a single server undermines every access decision.

Framing the work as protecting an initiative the organization already committed to does something a standalone security request cannot. It moves the conversation from new spending to protecting existing spending, and those two conversations have very different success rates. I wrote about a related version of this dynamic in CMMC in the Plant, Not the PowerPoint, where compliance programs succeed or fail based on whether they touch operational reality.

Offer the smallest credible first step

Large identity programs stall because they ask for a decision proportional to their scope. Executives approve things they can reverse.

A hardening assessment of three servers is a decision someone can make in a single meeting. A three-year identity governance transformation requires a steering committee, a business case, and a budget cycle. The first one creates evidence that makes the second one easier to approve later.

This sequencing is not a sales technique. It reflects how organizations genuinely absorb change, and practitioners who understand it get more of their work funded than practitioners who insist on the complete program up front.

What buyers actually say when identity risk stalls

Certain objections repeat across industries. Each one signals a specific gap.

When a buyer says they already deployed MFA, they believe they solved the identity problem. They have not heard that token forgery and session theft operate downstream of authentication entirely.

When a buyer says they cannot explain this to their board, they are asking for language, not information. That request deserves a direct answer rather than more technical detail.

When a buyer says the sync server belongs to another team, they have identified an ownership gap that will block the work regardless of how strong the technical case becomes. Somebody has to resolve that before anything else moves.

When a buyer says nothing has happened yet, they are applying the reasonable heuristic that quiet systems are healthy systems. The identity bridge is specifically the place where that heuristic fails, and saying so plainly tends to land.

What this means for commercial teams in cybersecurity

I have spent my career on the commercial side of enterprise technology, at IBM, SAP, Manhattan Associates, UKG, and most recently in identity and access management consulting. The pattern I keep returning to is this: technical depth and commercial effectiveness are not competing skills, and the strongest people in identity security refuse to choose between them.

The sellers who consistently win complex identity deals do not win because they know more about Kerberos than their competitors. They win because they can hold an architecture conversation with a security engineer at nine in the morning and a consequence conversation with a CFO at two in the afternoon, without changing the underlying facts between those two meetings.

That second conversation is where most identity programs live or die, and it receives a fraction of the preparation the first one gets. For anyone building a career in this market, the translation skill compounds faster than any product certification.

That translation skill sits alongside the rest of the commercial toolkit. Full Throttle Media covers the adjacent territory in B2B Displacement Campaigns: Win Competitor Customers, which works the same problem from the account strategy side.

Frequently asked questions

Is the identity bridge only a Microsoft problem?

No. Microsoft environments make it most visible because Entra Connect and AD FS are widely deployed and well documented. Any organization that synchronizes or federates identity between an on-premises directory and a cloud provider carries the same structural exposure, including those running third-party identity providers alongside a legacy directory.

Does multifactor authentication protect against Golden SAML?

No. Golden SAML forges the authentication assertion itself, so the authentication event never occurs in a form that MFA or Conditional Access can evaluate. Protecting against it requires securing the federation infrastructure, controlling and monitoring token-signing certificates, and auditing certificate export and configuration changes.

How should an organization prioritize the identity bridge against other security work?

Prioritize it by blast radius rather than by likelihood. Most security findings expose one system. A compromised synchronization or federation server exposes every synchronized identity across both environments simultaneously, which places it in the same category as a domain controller.

What is the first question a security leader should ask about hybrid identity?

Ask who administers the synchronization and federation servers, and whether those administrators use the same accounts and workstations they use for ordinary IT work. The answer reveals whether the organization treats the bridge as a Control Plane asset in practice or only in documentation.

Did identity risk actually decline in 2026?

The 2026 Verizon DBIR showed credential abuse falling as an initial access vector, partly because a new pretexting category absorbed some incidents previously counted as credential abuse. Across the full breach chain, credential abuse still appeared in 39 percent of breaches. Attackers changed how they get in more than they changed what they do afterward.

The work is a translation problem

The identity bridge deserves attention on its technical merits, and the vendor documentation, the threat research, and the incident history all say so clearly. None of that has been enough on its own, which tells us something worth taking seriously.

Security programs do not fail only because teams miss the risk. They fail because the people who see the risk most clearly describe it in a language the people holding the budget do not speak. That is a solvable problem, and solving it does not require anyone to dilute the technical truth. It requires naming consequences, attaching risk to priorities the organization already values, and asking for a first step small enough to approve.

 


About the Author

Navneet Lounsberry brings over two decades of enterprise sales and business development experience across IBM, SAP, Manhattan Associates, UKG, and Idenhaus Consulting, where her work spanned identity and access management and cybersecurity compliance, including CMMC. A Georgia Tech graduate, she writes about how enterprise buyers in regulated industries actually evaluate, procure, and operate compliance programs.

 

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

How B2B buyers use AI to pick vendors before sales

  By the time a buyer books a call with your sales team, the important decision is usually already made. They have framed the problem, compa...