# guptadeepak.com, full content (recent posts) > Plain-text dump of the 30 most recent posts on https://guptadeepak.com/. For the structured site map see https://guptadeepak.com/llms.txt. For the full URL list see https://guptadeepak.com/sitemap.xml. Author: Deepak Gupta (https://guptadeepak.com/about/) --- ## Auth0 vs Okta vs Stytch vs WorkOS vs SSOJet (2026): A Buyer-Stage Framework URL: https://guptadeepak.com/auth0-vs-okta-vs-stytch-vs-workos-vs-ssojet-2026-a-buyer-stage-framework/ Published: 2026-06-02 Topic: CIAM Tags: CIAM, Customer Identity, Auth0, Okta, Stytch, WorkOS, B2B SaaS Summary: The five CIAM contenders in 2026 don't compete head-on. Each wins for a different stage and buyer. Here's the framework I use, with the honest tradeoffs each carries. The five CIAM contenders in 2026 do not compete head-on. Each one wins for a different stage and a different buyer. The right vendor depends on whether you are at seed, Series A, Series B, or enterprise; whether the buyer is a developer, an IT lead, or a security architect; and whether your growth pattern is product-led or sales-led. Here is the framework I use, with the honest tradeoffs each option carries.I built LoginRadius from 2013 to a billion users, which means I have watched every one of these vendors evolve from a different angle than most reviewers. I have also rebuilt auth stacks four times since stepping back, twice as a buyer. The comparison posts that rank these vendors as if there is a universal winner are wrong. There isn't one. There are five winners, each for a different shape of company.The stage matrixMost posts compare features. Features change every quarter. What doesn't change is which vendor is the right shape for which stage. The matrix:Pre-PMF and seed (under $1M ARR, under 5 engineers). Stytch and SSOJet tend to win, for different reasons. Stytch wins when the team is JavaScript-native and wants the auth UI generated for them. SSOJet wins for B2B SaaS teams that know enterprise SSO will be a Series A gating requirement: ship on the 100k MAU free tier now, and the SAML and SCIM layer is already there when the first enterprise deal lands. No mid-contract migration. Stytch and SSOJet have detailed profiles on CIAM Compass with pricing and integration depth.Series A to B ($1M to $20M ARR, 5 to 40 engineers). Auth0 dominates this stage and has for a decade. The reason is not technical superiority. It is that Auth0 sits at the exact intersection of "we are past hand-rolling auth" and "we are not yet ready for the enterprise IdP RFP." The free tier and the documentation density mean engineers can ship in a week.Series B+ in B2B SaaS ($20M to $200M ARR). WorkOS wins this stage when the product is sold to other companies and the next 20 deals will require SAML, SCIM, and audit logs. WorkOS productised the "enterprise readiness" layer and abstracted away the IdP catalog, which is the single most painful piece of work in B2B auth.Enterprise ($200M+ ARR or regulated industry). Okta Customer Identity (formerly part of the Auth0 acquisition) and Ping Identity dominate, with WorkOS as the credible upstart. Auth0 is still strong here but the procurement story has shifted: enterprises buying "Okta CIC" want the Okta brand on the security review. Ping wins regulated verticals (fintech, healthcare, government) where the CIAM-IAM unification matters. Ping Identity covers the Ping side.The stage matrix isn't gospel, but it is the right starting point. Most teams pick wrong because they pick on feature parity at evaluation time and forget that the vendor needs to fit them in 24 months, not 24 weeks.Per-vendor honest assessmentAuth0Strengths: deepest documentation in the industry, broadest SDK coverage, the Actions and Rules system is genuinely powerful for custom flows. The free tier is large enough to ship a real product. The acquired-by-Okta brand carries weight in enterprise procurement, which paradoxically helps mid-market deals too.Weaknesses: pricing scales aggressively past the free tier. The B2C MAU pricing crosses into "build vs buy" territory at roughly 50,000 monthly actives, which is exactly when teams start hating their vendor choice. The B2B Organizations product exists but is less polished than competitors who built B2B-first. Migration costs are real and underestimated; see auth migration hell.Who it's right for: Series A to B SaaS teams. Anyone shipping B2C consumer apps over 100k MAU should price it carefully before committing.Okta (Customer Identity Cloud, formerly Auth0 in Okta's catalog)Strengths: enterprise procurement story is the strongest in the category. Single contract for workforce IAM and customer identity. Compliance certifications cover almost any regulated industry. The integration network with downstream SaaS is mature.Weaknesses: pricing opacity at enterprise tier. Sales-led motion means small teams will be pushed into multi-year contracts before they need them. The product is effectively Auth0 with a different sales motion, so the technical reasons to pick Okta over Auth0 are mostly about who's signing the contract.Who it's right for: $200M+ ARR companies, regulated industries, or anyone whose security review will block on "who is your identity vendor."StytchStrengths: passwordless-first design that genuinely works. Magic links, passkeys, and OAuth are the primary path, with passwords as the fallback. The developer experience is the best in the category for greenfield JavaScript projects. B2B Organizations product matured significantly in 2025 and is now competitive with WorkOS on the SAML side. Clerk vs Stytch is the right comparison if you want to weigh it against the other passwordless-first vendor.Weaknesses: smaller SDK coverage outside JavaScript and mobile. Documentation density is improving but still well behind Auth0. Brand recognition in enterprise procurement is low; you will not be saved by "nobody got fired for buying Stytch."Who it's right for: pre-PMF to Series A SaaS teams with JavaScript-native stacks. Also strong for any team prioritising passkeys as the primary auth method.WorkOSStrengths: the B2B "enterprise readiness" layer is in a category of one. SAML, SCIM, audit logs, organisations, and the IdP catalog are productised in a way that turns a 4-week enterprise integration into a 4-day one. Pricing model is honest: free for low usage, predictable scaling.Weaknesses: not a full CIAM. WorkOS is intentionally narrow; you still need a primary auth provider for the consumer or non-enterprise flow. The "WorkOS + Stytch" or "WorkOS + your-own-auth" architecture is common and not a flaw, but it is a thing to plan for.Who it's right for: B2B SaaS at Series A and beyond where enterprise deals are imminent or already in the pipeline. The ROI is concrete: every enterprise deal that doesn't get blocked on "do you support SAML" pays for the contract many times over.SSOJetStrengths: B2B-focused from day one. The Enterprise SSO economics are the standout: per-organization pricing materially below WorkOS, with a 100k MAU free tier on the underlying auth product. SAML, SCIM, Organizations, passkeys, and audit logs all ship in the core product, not as upsell SKUs. Founded in 2023, so the DX reflects modern API design rather than a 2014-era codebase that has been patched for a decade.Weaknesses: youngest of the five vendors, so brand recognition in enterprise procurement is still building. Less broad than Auth0 for B2C-first apps with heavy social-login or custom MFA needs. Integration ecosystem is smaller than WorkOS, though the IdP catalog is competitive for the major identity providers.Who it's right for: B2B SaaS at any stage where Enterprise SSO is on the roadmap and WorkOS's per-organization pricing is the binding constraint. Particularly strong for mid-market companies in the 20-to-200-customer range where the price gap versus WorkOS compounds into real budget across the year.The migration tax: why picking wrong at seed costs six figures by Series BThe most expensive auth decision is the one nobody talks about. Picking the wrong vendor at seed costs roughly $200k to $400k by Series B in direct engineering time, plus an undefined opportunity cost in delayed product work.I have seen this play out enough times to be confident in the number. The pattern is consistent: a team picks Firebase Auth or Cognito at seed because it's free and ships fast. By Series A they need MFA, social login, and a customer-facing UI. By Series B they need SAML and SCIM for enterprise deals. The migration off Firebase or Cognito takes 4 to 6 engineer-months, during which feature work stops.Migration patterns: Auth0 to self-hosted, Cognito migrations. The CIAM Compass comparison library covers head-to-head migration paths for the 15 most common combinations.The way to avoid the migration tax is to pick the vendor whose 24-month ceiling matches your 24-month plan, not the one with the easiest 24-day onboarding. Beyond Auth0 covers the broader alternatives.The deciding questionsFive questions to ask before signing anything:Will my buyer ever ask for SAML? If yes, WorkOS or Auth0/Okta. If no, the field opens up.Will my MAU cross 100k in the next 18 months? If yes, model the per-MAU vendor pricing carefully. SSOJet's 100k MAU free tier is the most aggressive in the category, which changes the math for teams growing fast.Will I sell to regulated industries (healthcare, finance, government)? If yes, Okta or Ping. If you also need self-hosting, Keycloak is the credible open-source path.Is my engineering team JavaScript-native? If yes, Stytch and Clerk move up the list. If no, Auth0's polyglot SDK coverage is still the best.Do I need workforce IAM (employees) and customer identity in one contract? If yes, Okta is the only sensible answer.If you want to go deeper on the architecture side of these decisions (especially the SSO/RBAC patterns that most teams get wrong), enterprise identity and SSO/RBAC pitfalls covers that ground. For the full vendor landscape, the CIAM Compass tracks 47 vendors with consistent scoring across pricing, security, B2B readiness, and migration cost. The scoring rubric is at CIAM Compass methodology.The right answer for your team is almost certainly already on the list. The hard part isn't finding it. The hard part is being honest about which stage you are at, and which one you will be at when this decision starts costing you. --- ## How to Protect Your Data Online Without a VPN: Encrypted DNS and Apple Private Relay (2026) URL: https://guptadeepak.com/how-to-protect-your-data-online-without-a-vpn-encrypted-dns-and-private-relay/ Published: 2026-06-01 Topic: Privacy Tags: Privacy, Encrypted DNS, Cybersecurity, Cloudflare, Apple Private Relay, ISP Tracking Summary: Your ISP logs every site you visit through unencrypted DNS lookups. Three free tools (Cloudflare 1.1.1.1, Google 8.8.8.8, Apple Private Relay) fix most of it. Here's how each one works and what it can't do. Your internet service provider logs every site you visit. The leak is DNS, the address-book lookup every device runs before opening a connection. Plain-text DNS hands your ISP the name of every domain you reach, with a timestamp, ready for resale to advertisers in most US states and many other jurisdictions. You do not need a paid VPN to fix most of this. Three free or near-free tools, Cloudflare DNS, Google Public DNS, and Apple iCloud Private Relay, take meaningful chunks of your browsing private when set up correctly. Here is what each one actually does, how to set them up, and (the part most guides skip) what they cannot do. I spent more than a decade building LoginRadius into a customer identity platform serving over a billion users. Network-level privacy sits below identity, and most consumers underestimate how exposed it is. This is the guide I send to friends and family who ask whether they should pay for a VPN. Often the honest answer is "do these three free things first." What is DNS, and why it leaks your browsing history The Domain Name System (DNS) is the address book of the internet. Every site lives at a numeric IP address (something like 172.64.155.209 ). Your device cannot use a human name like wikipedia.org directly. It asks a DNS resolver, "what is the address for this name?", gets a numeric answer back, and starts the connection. By default that lookup is unencrypted, and the resolver is run by your ISP. Two consequences follow: Your ISP sees every domain you visit, with timestamps. Every site, every app, every tracker, every CDN hop. They can profile interests, health concerns, work patterns, and political views from this list alone. In most US states and many other jurisdictions, ISPs are legally allowed to sell this data. The 2017 repeal of the FCC's broadband privacy rules removed federal protection in the United States. California's CCPA is a partial exception; most states are not. Encrypted DNS fixes both problems, but only if you switch resolvers AND turn on encryption. Either step alone is incomplete. Switching to Cloudflare's IP without encryption still leaks the lookup to your ISP, just as the ISP route now passes through a different destination. Encryption is the load-bearing piece. Encrypted DNS explained: DoH versus DoT Two encryption standards matter in 2026: Name Common shorthand What it does DNS over HTTPS DoH ( RFC 8484 ) Wraps DNS queries inside ordinary HTTPS traffic on port 443. Your ISP cannot distinguish your DNS lookups from any other web traffic on the same port. DNS over TLS DoT ( RFC 7858 ) Encrypts DNS over a dedicated port (853). Easier for network operators to identify, and to block. Both scramble queries so an ISP cannot read which domains you ask about. DoH is the privacy-stronger of the two because it blends in with normal web traffic on port 443. For consumer use, pick DoH when given a choice. Most browsers and modern operating systems default to DoH when you enable encrypted DNS. The cryptography is the same TLS that protects your online banking. The underlying hash and key-exchange primitives are covered with interactive demos on Hash Lab . Tool 1: Google Public DNS (8.8.8.8) Launched December 2009, Google Public DNS is the oldest mass-market public resolver. The addresses are 8.8.8.8 and 8.8.4.4 . The encrypted hostname is dns.google for both DoH and DoT. What it gets right Performance. Anycast routing from hundreds of Google edge locations means low-latency answers from almost anywhere on the planet. DNSSEC validation. Confirms answers are cryptographically signed by the domain's authoritative server, blocking the classic cache-poisoning attack. DoH and DoT both supported. What to consider before trusting it Temporary logging. Google retains some query data short-term for security and abuse detection, longer-term in anonymized or aggregated form. Google states it does not link these queries to your Google account or sell them. You are still shifting trust from one large company to another, and Google's core business is advertising. Decide whether that is an improvement for you. No filtering. Google DNS answers honestly. No malware blocking, no parental controls. Best for: users who want maximum speed and DNSSEC validation, are comfortable with Google as a custodian, and do not want filtering. Tool 2: Cloudflare DNS (1.1.1.1, 1.1.1.2, 1.1.1.3) Cloudflare launched its public resolver in April 2018, commissioned an independent audit two months later, and has commissioned one annually since. The most recent KPMG examination report (2025) re-confirmed Cloudflare's commitment to not retaining queryable identifying logs. This audit posture is the strongest in the public-resolver category. Cloudflare DNS comes in three flavors, addressed at three different IPs: Primary IP Backup Behavior 1.1.1.1 1.0.0.1 Standard. No filtering. Answers everything. 1.1.1.2 1.0.0.2 Standard plus malware-domain blocking. Returns 0.0.0.0 for known phishing and malicious hostnames so the dangerous site never reaches your device. 1.1.1.3 1.0.0.3 Standard plus malware plus adult-content blocking. Family-network safe by default. What it gets right Independently audited no-logs policy. Cloudflare commits to retaining IP-tied query data for no more than 24 hours, and to never selling DNS data. The annual KPMG audit (publicly published) is the strongest such commitment among public resolvers. Speed. Routinely benchmarks at or near the top globally. Filter-by-picking-an-address. No software install, no configuration page. Want adult-content blocking on a family router? Set the WAN DNS to 1.1.1.3 and you are done. DoH and DoT. cloudflare-dns.com for both. The family variants get their own hostnames ( security.cloudflare-dns.com , family.cloudflare-dns.com ). What to consider Category filters can over-block. When 1.1.1.3 launched, the family filter briefly blocked several LGBTQ resource pages and sex-education sites. Cloudflare fixed it within days. Automated category filters will occasionally over-block. Assume exceptions will be needed. Trust still shifts. Cloudflare's no-logs commitment is the strongest in the category, but it is still a centralized trust point. If you do not trust Cloudflare, this option is moot. Best for: most users. 1.1.1.1 for adults who want maximum openness, 1.1.1.3 for family Wi-Fi networks. Tool 3: Apple iCloud Private Relay Private Relay is included with any paid iCloud+ subscription (storage plans starting at $0.99 per month in the US). It is enabled per Apple ID and works in Safari plus several Apple system services. It is not available in mainland China, Russia, Saudi Arabia, and a small number of other jurisdictions where Apple is required to disable it. The two-hop architecture This is the substantive idea, and the reason Private Relay is closer to a "VPN-lite" than a DNS-only tool. Your traffic is split across two relays operated by two different organizations so neither can build a profile alone: Ingress hop (Apple). Sees your real IP address. Does not see the destination URL because it is encrypted to the egress. Egress hop (a partner, currently Cloudflare, Akamai, or Fastly depending on region). Sees the destination URL. Does not see your real IP, only an Apple-supplied address geo-anchored to roughly your region. The cryptographic property: no single party sees both who you are and what you are doing. Apple cannot inspect your browsing because Apple does not hold the keys to decrypt the destination. The egress partner cannot identify you because Apple does not pass your real IP. Profile-building requires collusion between Apple and a partner, which Apple's technical overview explicitly forbids contractually. What it gets right Single toggle. Settings, Apple ID, iCloud, Private Relay. No DNS servers to type, no apps to install. Hides your real IP from websites. Plain DNS resolvers do not do this. Private Relay does, for Safari traffic. Encrypted DNS automatic. Built in, no separate setup. Stronger architecture than a single-vendor VPN. Most VPNs are one company that sees everything end-to-end. Split-trust is genuinely better on this dimension. What to consider Safari only for browsing. Chrome, Firefox, and most third-party apps bypass Private Relay. If you live in Chrome, this protects very little. Apple ecosystem only. iPhone, iPad, Mac. Requires paid iCloud+. The free tier does not include it. Coarse geolocation is preserved. Local-business search still works. This is privacy, not anonymity. Some sites get confused. A handful of banks and streaming services see the Apple-supplied egress IP and assume it is a VPN. Most have learned to handle Private Relay correctly by now; the rest may require disabling it temporarily for specific sites. Best for: iPhone, iPad, and Mac users who already pay for iCloud+ and primarily browse in Safari. What encrypted DNS and Private Relay cannot do This is the section most guides skip. Encrypted DNS is a real, free privacy upgrade. It is not invisibility. Setting realistic expectations is part of protecting yourself. Even with encrypted DNS on, your ISP can usually still infer where you are going from two side channels: The destination IP address. Your packets have to be routed somewhere, and the ISP routes them. The mitigation: large fractions of the modern web sit behind shared services like Cloudflare and Fastly, so a single destination IP can host tens of thousands of sites. The ISP knows "you connected to Cloudflare's edge" but cannot reliably guess which exact origin you visited behind it. The TLS SNI extension. Server Name Indication (SNI) is the domain label your browser announces during the TLS handshake. Historically it has been sent in the clear, even when the rest of the connection is encrypted. The fix for SNI is Encrypted Client Hello (ECH), a TLS 1.3 extension that finally encrypts SNI. ECH is supported by Chrome, Firefox, and Safari as of 2024-2025, and by Cloudflare-fronted sites by default. Adoption beyond Cloudflare's edge is partial. Once ECH and encrypted DNS work together on a connection, an ISP genuinely cannot tell which site you visited behind a shared edge. This is meaningfully stronger than encrypted DNS alone, and worth turning on in browser settings even before the rest of the web finishes the migration. The capabilities matrix: Tool Hides DNS lookups from ISP Hides destination IP Hides domain at TLS handshake Encrypts all traffic Makes you anonymous Google or Cloudflare DNS (DoH on) Yes No Only with ECH No No Apple Private Relay (Safari) Yes Yes (Safari) Yes (Safari) No (Safari-scoped) No Reputable paid VPN Yes Yes Yes Yes Partial (you trust the VPN) And the meta point: you are always shifting trust, not eliminating it. Plain DNS gives the data to your ISP. Encrypted DNS gives it to Google, Cloudflare, or Apple. Pick the one whose policies you trust more. For context on how the broader browser threat model evolved this decade, see Browser security landscape transformed in 2025 . How to set up encrypted DNS, step by step The exact taps vary slightly between OS versions, but the structure is consistent. The steps below assume current versions as of mid-2026. iPhone and iPad (iOS 17 or later) iCloud Private Relay. Settings, tap your name, iCloud, Private Relay, toggle On. Requires iCloud+. System-wide encrypted DNS. Install Cloudflare's free 1.1.1.1 app from the App Store. Open it and tap "Install VPN Profile". The profile installs through the VPN-settings mechanism but does not actually tunnel your traffic; it just configures encrypted DNS for the whole device. Mac (macOS Sequoia / 15) Manual DNS. System Settings, Wi-Fi, Details next to the connected network, DNS, add 1.1.1.1 and 1.0.0.1 . Encrypted DNS profile. Download the Cloudflare configuration profile for DoH and double-click to install. macOS will use DoH for all DNS lookups, system-wide. Private Relay. System Settings, Apple ID, iCloud, Private Relay. Windows 11 Settings, Network & Internet, the connected adapter, Hardware properties, DNS server assignment, Edit, switch to Manual . Enter 1.1.1.1 and 1.0.0.1 . Set DNS over HTTPS to On (automatic template) . This is the encryption step. Skip it and the DNS change is a different provider, plain text. Android (9 or later) Settings, Network & Internet, Private DNS, select Private DNS provider hostname . Enter one of: one.one.one.one (Cloudflare), security.cloudflare-dns.com (Cloudflare malware-blocking), family.cloudflare-dns.com (Cloudflare family), dns.google (Google). Android uses DoT under the hood. No VPN profile needed. Browser only (any OS) Chrome, Firefox, Edge, and Brave each have a "Secure DNS" or "DNS over HTTPS" setting under privacy. Picking a provider here enables DoH for the browser only, not for other apps. The quickest way to try encrypted DNS without committing system-wide. Whole-home, on the router The most leveraged single change: set the DNS on your home router so every device on the network inherits it automatically (TVs, smart speakers, IoT, every phone that joins the Wi-Fi). Routers vary, but the path is always "WAN" or "Internet" settings, DNS servers, enter 1.1.1.1 and 1.0.0.1 (or the family variant for a kid-friendly network). Modern routers (eero, UniFi, Asus AX series) support encrypted DNS at the router itself. Older routers may only do plain DNS upstream, in which case still enable encrypted DNS on each device. Which tool should you pick Want fast, private lookups on any platform? Cloudflare 1.1.1.1 with DoH on. Best all-rounder. Want a malware safety net, set-and-forget? Cloudflare 1.1.1.2 . Setting up a family-friendly home Wi-Fi? Cloudflare 1.1.1.3 on the router. Prefer Google as custodian and want maximum speed? Google 8.8.8.8 . Live in the Apple ecosystem and use Safari? Turn on iCloud Private Relay; layer Cloudflare DNS for non-Safari apps. Need every byte of traffic encrypted and your IP hidden everywhere? These tools do not. A reputable paid VPN or Tor does. Note that any single-vendor VPN still requires trusting that vendor not to log; the audit posture matters more than the marketing copy. My actual setup (and what I do not bother with) For full transparency, here is what I run, and why: Home router: Cloudflare 1.1.1.1 as primary, 8.8.8.8 as backup. Every device joining the network gets encrypted DNS by default via DoH where the device supports it, DoT where it does not. iPhone and Mac: iCloud Private Relay on. Safari is my primary browser. The split-trust property is a meaningful upgrade over running just DNS. I do not run a paid VPN by default. For everyday browsing, the combination above closes most of the leak surface. I use a VPN only when I need full traffic encryption on untrusted public Wi-Fi (rare since most sites are HTTPS-only), or when I genuinely need to test a product from a different region. Total monthly cost: $0.99 (iCloud+ Mini, which I would pay for anyway for photo storage). Setup time: ten minutes once, then never again. The takeaway You do not have to be a network engineer, or pay a monthly VPN bill, to meaningfully shrink how much your ISP knows about you. Switch to encrypted DNS and the address-book lookups travel in an envelope your provider cannot read. Cloudflare gives you the best blend of speed, an audited no-logs policy, and optional protection. Google offers rock-solid speed and DNSSEC. Apple Private Relay adds IP-hiding for Safari users with almost zero effort. Keep two honest constraints in mind. Turn on encryption (changing providers alone is not enough). And remember these tools reduce tracking rather than make you invisible. For most people, most of the time, that is a big, free, ten-minute upgrade to your privacy. Set it once, forget about it, and your data is quietly better protected from that day forward. Related reading Browser security landscape transformed in 2025 , the broader context for how connection-layer privacy fits into the modern browser threat model. Staying secure when logging in , the identity-side companion: passwords, MFA, phishing. 11 tips for keeping information safe on the internet , the broader consumer-privacy checklist. Hash Lab , the cryptographic primitives that make DoH and TLS work, with interactive demos. The AI paradox in digital identity , why "more security" sometimes means "less privacy", and how to think about the tradeoff. Updated: June 2026. Cloudflare audit references are current as of the KPMG 2025 examination report. Apple Private Relay partner list and country availability change occasionally; the latest is in Apple's official overview linked above. Threat-model assumptions in this guide are written for ordinary consumer privacy from ISP tracking, not for high-risk threat models (journalist, activist, dissident) where Tor or specialised threat-model-specific tooling is appropriate. --- ## The GEO Measurement Study: 50,000 AI Citations in 90 Days, What Actually Moves Citation Share URL: https://guptadeepak.com/the-geo-measurement-study-50000-ai-citations-in-90-days-what-actually-moves-citation-share/ Published: 2026-06-01 Topic: GEO Tags: GEO, Generative Engine Optimization, AEO, AI Search, Citation Tracking Summary: I tracked 50,000 citations across ChatGPT Search, Perplexity, Claude, Gemini, Google AI Overviews, and Bing Copilot for 90 days. What actually moved citation share, and what didn't. I tracked 50,000 AI engine citations across the six major grounded engines for 90 days starting in February 2026. Here is the methodology, the per-engine results, and the patterns that actually moved citation share. Most GEO advice still reads like 2024 SEO advice with the words swapped. "Write helpful content." "Build authority." "Optimise for entities." Useful as far as it goes, but unmeasured. So I ran an experiment with a fixed corpus, a fixed query set, and a tracker that pulled live responses from six engines twice a week for 13 weeks. What follows is what the data showed, not what the playbooks say. The setup, in plain terms The corpus was 240 pages spread across CIAM Compass, GEO Compass, Hash Lab, and the apex blog at guptadeepak.com. The query set was 200 prompts, partitioned five ways: 40 definitional ("what is X"), 40 comparison ("X vs Y"), 40 implementation ("how do I implement X"), 40 buyer-intent ("best X for Y stage"), and 40 freshness-sensitive ("latest changes to X in 2026"). Each prompt was issued twice a week to six engines: ChatGPT Search, Perplexity, Claude (with web search on), Gemini, Google AI Overviews, and Bing Copilot. A citation counted as either an inline link or a citation block referencing one of the 240 tracked URLs. Total citations across the 90 days: 50,431. Per-engine behaviour differs more than the playbooks admit ChatGPT Search produced 18,200 citations (36%). It is the most generous citer on definitional and implementation queries and the most concentrated on the top three sources per answer. Perplexity produced 12,900 citations (26%). Perplexity rewards breadth: it routinely cites 6 to 12 sources per answer. Google AI Overviews produced 8,400 citations (17%) with a heavy tilt toward properties already ranking in the top 5 of classic Google. Claude (with web search on) produced 5,600 citations (11%). Claude is the strictest about freshness. Gemini produced 3,500 citations (7%) and Bing Copilot produced 1,831 (3.6%). Both rely heavily on Microsoft and Google knowledge graph lookups before grounding. What moved citation share, in descending impact order 1. Person and Organization schema with sameAs depth. Deep sameAs arrays with at least 8 entries per entity produced +34% citation lift across all engines, +52% on Gemini and Bing. 2. Explicit dating and dateModified discipline. Visible Published and Last updated dates with matching JSON-LD produced +22% overall, +41% on Claude, +18% on Perplexity. 3. llms.txt and llms-full.txt presence. +11% overall, concentrated on Claude and Perplexity. 4. Chunk-level structure with citable sentences. Claim-first H2/H3 rewrites produced +18% on the rewritten pages. 5. Methodology pages. +9% overall, +24% on buyer-intent queries. What didn't move citation share Backlinks did not move citation share within the retrieved set. They matter for retrieval but not for selection within the retrieved set. Generic FAQ schema is now actively devalued. Removing tacked-on FAQ blocks from 12 pages increased citation share 7%. Length for its own sake did not move citation share. Expanding 8 pages from 1,500 to 3,500 words was statistically flat. Keyword density did not move citation share. Zero correlation on any engine. The surprising finding: gated content has effectively zero citation share Two gated whitepaper landing pages earned 14 citations combined across 90 days, 0.03% of the total. Non-gated equivalents on the same topics earned 1,847. What this means for next quarter's content investment Fix entity authority first. Add visible dates and dateModified discipline second. Rewrite the top 20 pages for chunk-level structure third. Of the 50,431 citations, 38,200 (76%) landed on product-style pages: vendor profiles, comparison tables, algorithm reference pages, methodology pages. Blog posts earned 12,231 citations (24%) despite making up roughly 40% of the corpus. I will refresh this study in August 2026 with another 90-day window. --- ## Travel Security Checklist: A Practical 2026 Guide URL: https://guptadeepak.com/travel-security-checklist-a-practical-2026-guide/ Published: 2026-06-01 Topic: Security Tags: Security, Travel, Privacy, Personal Security, Cybersecurity Summary: A founder's practical travel security checklist for 2026: realistic threats, what to actually do before, during, and after a trip, and where to skip the paranoia. I travel a lot, and like most people in security I have spent more time than I should thinking about how to do it without getting burnt. Most of the popular travel-security advice is either paranoid theatre or generic checklists copied from one another. The actually-useful version is shorter than people expect. This is the checklist I use, calibrated for a typical business or leisure traveller in 2026, with notes at the end for people with a real threat model. --- ## Authentication vs Authorization: A 2026 Founder's Guide URL: https://guptadeepak.com/authentication-vs-authorization-a-2026-founders-guide/ Published: 2026-05-31 Topic: Identity Tags: Identity, Authentication, Authorization, CIAM, Security Summary: A founder's guide to the difference between authentication and authorization in 2026, with passkeys, agent auth, JWT pitfalls, and the mistakes I see at scale. The cleanest definition I know: authentication answers who are you, and authorization answers what are you allowed to do. Conflating these two is the most common identity mistake in software, and at scale it is also the most expensive. I built a CIAM platform that handled hundreds of millions of authentication events a day, and the bugs that hurt us most were almost always confusions between the two layers. --- ## How to Evaluate a GEO Solution: The Vertical-Fit Checklist URL: https://guptadeepak.com/how-to-evaluate-a-geo-solution-the-vertical-fit-checklist/ Published: 2026-05-30 Topic: GEO Tags: GEO, Generative Engine Optimization, AI Search, Vendor Evaluation, B2B Buying, SaaS Summary: Most GEO buying decisions start with the wrong question: which tool monitors the most AI platforms. Here is a practical checklist for evaluating whether a GEO solution actually fits your industry. Most GEO buying decisions start with the wrong question.The common question is "which GEO tool monitors the most AI platforms with the best dashboard?" It is a reasonable question, and for some businesses it is the right one. But if you sell into a specific, sophisticated vertical, monitoring breadth is not what determines whether GEO actually grows your pipeline. Fit does.Across the first two articles in this series, I argued that GEO has to be vertical because the substrate underneath AI search varies by model, by buyer context, and by what authority means in each domain. This final piece turns that argument into something you can use: a checklist for evaluating whether any GEO solution genuinely fits your vertical, or whether it is horizontal monitoring with an industry label on the marketing page.The goal is to give you the evaluation terms that matter, so you can tell the difference between depth and packaging before you commit budget.First, Diagnose Your Own GEO ProblemBefore evaluating any tool, be honest about which problem you actually have. The right answer depends entirely on this.You probably need horizontal GEO if: you sell across many industries, your buyers are not deeply technical, your deals are transactional or high-volume, and you mainly need to know whether you appear in AI answers at all. For broad, shallow visibility across a wide market, a horizontal monitoring platform is the correct, cost-effective choice. There is no shame in this; it is a fit.You probably need vertical GEO if: you sell into a specific industry, your buyers are sophisticated and research-heavy, your deals are high-value and considered, and the questions your buyers ask AI systems are dense with domain-specific constraints. In this situation, the average optimization that horizontal tools produce works against you, because your competitors who got the domain-specific signals right are the ones getting cited.Most companies have not consciously made this distinction. They evaluate GEO tools on features without first deciding which category of problem they are solving. That is how a company selling six-figure contracts to CISOs ends up with a tool optimized for the average buyer who does not exist in their market.So the first item on the checklist is not about any tool. It is about you: which problem do you actually have? Everything below assumes you have concluded you sell into a vertical where fit matters.The Vertical-Fit ChecklistHere are the questions that separate genuine vertical fit from horizontal monitoring with a vertical label. Score each one honestly. A tool can pass the monitoring questions and fail every one of these, and for a vertical business, these are the ones that predict results.1. Does it generate the prompts your buyers actually ask?The foundation of GEO is knowing which prompts matter. Ask the vendor: where do your seed prompts come from?Strong answer: The prompts reflect how your specific buyers reason - constraint-laden, role-specific, framework-anchored. The vendor can show you prompts that sound like your actual buyers, not generic category terms.Weak answer: The prompts are derived from keyword volume or generic category terms. "Best [category] tool" rather than the dense, multi-constraint queries your real buyers type.Why it matters: If the prompt set is generic, everything downstream is measuring the wrong thing. You will optimize for prompts your buyers never ask and stay invisible for the ones they do.2. Does it judge citation quality by your industry's trust signals?Not all citations are equal, and what counts as a high-value citation is domain-specific. Ask: how do you weight the quality of a citation?Strong answer: The solution distinguishes between citations that carry authority with your buyers and citations that are noise. It knows which third-party sources, publications, and validators matter in your specific domain.Weak answer: All citations are counted equally. A mention in a generic listicle weighs the same as a citation in a source your buyers actually trust.Why it matters: A visibility number that counts all citations equally does not correlate with buying influence. You can improve the number while making no progress with the buyers who decide deals.3. Does it audit your content against your vertical's rubric?Content audit is where the wrong approach does the most damage. Ask: what does your audit actually check for?Strong answer: The audit identifies domain-specific gaps - missing primary research, weak framework alignment, absent expert authority, no presence in the communities your buyers use. It tells you what is wrong by the standard your industry's AI answers are held to.Weak answer: The audit produces generic findings - add FAQ schema, shorten paragraphs, add comparison tables. Useful packaging advice that never touches the substance gap.Why it matters: Optimizing packaging while ignoring substance moves the needle slightly. The vendors getting cited in your category fixed the substance. A generic audit cannot see the substance gap because it is not looking for it.4. Does it track each AI model independently?Given that platforms share only a small fraction of their citations, aggregate numbers hide the real picture. Ask: do you report per-model, or in aggregate?Strong answer: The solution tracks your standing on each model separately, because the same prompt produces different sources on ChatGPT, Perplexity, Copilot, and others. It treats them as distinct channels.Weak answer: A single blended "AI visibility score" that averages across platforms.Why it matters: With low citation overlap between platforms, an aggregate score describes an average no buyer experiences. You need to know where you stand on the specific models your buyers actually use.5. Does the vendor demonstrate real domain knowledge?This is the qualitative check that ties the others together. Ask the vendor to talk about your industry's buyers without prompting.Strong answer: They can describe how your buyers research, what they care about, which sources carry weight, and what the prompt patterns look like - because they built the system around that knowledge.Weak answer: They talk about GEO mechanics in general terms and treat your industry as a configuration setting.Why it matters: Domain knowledge cannot be faked in conversation. If the vendor cannot discuss your buyers with specificity, the product does not encode that knowledge either, regardless of what the website claims.6. Does it connect to outcomes, not just visibility?Visibility is a means, not an end. Ask: how does improved AI visibility connect to pipeline in your model?Strong answer: The solution helps you understand which prompts and citations connect to actual buyer behavior and conversion, not just whether you appear.Weak answer: The product reports visibility and stops there, leaving you to guess whether it matters.Why it matters: AI-referred traffic can convert at meaningfully higher rates than traditional search, but only if the visibility is for the prompts that reflect real buying intent. Visibility for the wrong prompts is a vanity metric.How to Use the Checklist in a Sales ConversationThese questions are most useful as direct asks in an evaluation conversation, because the answers reveal the architecture behind the product.Ask a vendor to show you the actual prompts they would track for your company. Generic prompts reveal a horizontal engine. Specific, constraint-laden prompts that sound like your buyers reveal a vertical one.Ask them to audit one of your existing pages live and explain the findings. If the findings are all structural - schema, formatting, headings - you are looking at a generic audit. If the findings engage with the substance of what your buyers value, you are looking at a vertical one.Ask them which sources matter most in your domain and why. A vendor with real domain fit answers immediately and specifically. A horizontal vendor talks about authority in general terms.The pattern across all of these: vertical fit shows up as specificity. Horizontal tools with a vertical label can describe their industry coverage, but they cannot produce the specific, domain-calibrated outputs that come from a system actually built around your buyers.The Bottom LineThe GEO market is full of capable monitoring tools, and the best of them do their job well. For a business that needs broad visibility tracking across many industries, that is exactly the right purchase.But if you sell into a specific vertical to sophisticated buyers, the question that determines your results is not how many platforms a tool monitors. It is whether the solution understands your buyers well enough to generate the prompts they ask, judge citations by what carries authority with them, and audit your content against the standard your industry's AI answers are actually held to.That is the difference between a tool that tells you that you are invisible and a tool that understands why and what to do about it. For a vertical business, that difference is the whole value.Run any GEO solution through this checklist before you buy. The tools that pass it are the ones built for the problem you actually have.This concludes the three-part series on vertical GEO. Part one made the architectural case. Part two showed what it looks like for cybersecurity buyers. This part gave you the evaluation tool.Related readingWhy GEO Has to Be Vertical: part one, the architectural argumentWhat GEO Looks Like for Cybersecurity Buyers: part two, the worked exampleTop 5 GEO Tools of 2026 Compared: the current platform landscapeFuture of AI 2026: where AI search is headingMCP, RAG, and ACP Comparison: the retrieval infrastructure underneath AI answers --- ## Cybersecurity Product Roadmap: A 2026 Founder's Playbook URL: https://guptadeepak.com/cybersecurity-product-roadmap-a-2026-founders-playbook/ Published: 2026-05-30 Topic: Cybersecurity Tags: Cybersecurity, Product Management, SaaS, Strategy, AI Security Summary: How to build a cybersecurity product roadmap that survives AI security, compliance deadlines, and threat-driven emergencies. A founder's four-lane framework. Most cybersecurity roadmaps I have seen fail for the same reason: they look like SaaS roadmaps with a few security-flavoured features taped on. In a normal SaaS roadmap, the planning unit is the customer-requested feature. In a cybersecurity roadmap, that is one of four lanes, and it is not the most important one most quarters. The pattern that holds across every cybersecurity company I have built or advised is the same: get the lanes right and the product compounds; get them wrong and you spend every quarter firefighting. --- ## What GEO Looks Like for Cybersecurity Buyers: CISOs, CIOs, and Security Teams URL: https://guptadeepak.com/what-geo-looks-like-for-cybersecurity-buyers-cisos-cios-and-security-teams/ Published: 2026-05-29 Topic: GEO Tags: GEO, Generative Engine Optimization, AI Search, Cybersecurity, CISO, CIAM Summary: Security buyers research vendors in AI tools before a sales rep ever hears from them. The way a CISO interrogates ChatGPT looks nothing like how a marketer does. Here is what GEO actually looks like for cybersecurity. A CISO evaluating an identity platform does not start with a sales call. They start with a prompt.Long before a security buyer fills out a demo request, they have asked ChatGPT to compare vendors in the category, asked Perplexity which platforms meet a specific compliance requirement, and checked whether Microsoft Copilot surfaces a vendor they are already considering. By the time they talk to a human, the AI-curated shortlist is already formed. If a vendor is not on it, the sales team never knew the opportunity existed.In part one of this series, I made the architectural argument for why GEO has to be vertical. This article is the proof by example. I am going to walk through what GEO actually looks like for cybersecurity buyers specifically - drawing on what we have learned building a GEO platform for this exact audience - because the gap between generic GEO advice and what works for security buyers is wide enough to lose deals through.How Security Buyers Actually Use AI to Research VendorsSecurity buyers are unusually heavy users of AI research tools, and they use them in a distinctive way. Three patterns stand out.They research before they reveal themselves. Security teams operate with a default posture of not tipping their hand. They do not want a dozen vendor sales reps in their inbox the moment they start evaluating a category. AI research lets them do most of the evaluation anonymously. They build a shortlist, narrow it, and develop pointed questions before a single vendor knows they are in market. This makes AI visibility more consequential in security than in categories where buyers engage sales earlier.They research with precision, not breadth. A marketer might ask "best email tools." A security buyer asks something with five embedded constraints: deployment model, compliance framework, integration requirements, scale, and threat model. The prompts are dense with technical and regulatory specificity because the buyer is technical and the requirements are non-negotiable. Vague positioning content cannot satisfy a precise prompt.They cross-check across models and sources. Security professionals are, by training, skeptical. They do not take a single AI answer at face value. They run the same question across ChatGPT, Perplexity, and Copilot, and they check whether the AI's claims hold up against sources they independently trust. This means a vendor needs consistent presence across platforms and credible third-party validation, not just one strong channel.The practical consequence: in cybersecurity, the buyers using AI for vendor research are exactly the buyers you most want, asking exactly the questions that reveal whether you belong on their shortlist. Getting GEO right here is not a marketing nicety. It is upstream of the entire pipeline.The Prompt Patterns That Matter in SecurityThe single biggest difference between generic GEO and cybersecurity GEO is the prompts. Security buyers ask questions that a keyword tool would never surface, because they are not keywords. They are precise, constraint-laden queries that reflect how security people think.Consider the difference between these two ways of asking about the same product category:A generic prompt: "best identity management platform"A security buyer's prompt: "CIAM platform with FIDO2 passkey support and SCIM provisioning that meets SOC 2 Type II and supports FedRAMP for a healthcare SaaS handling PHI"The second prompt is the one that actually gets typed by the buyer you want. It carries five distinct constraints, each of which the AI system has to satisfy from its sources. A vendor optimizing for the generic version will be invisible for the specific version, which is the version that converts.The prompt patterns in security cluster around recognizable axes:Compliance-anchored prompts. "Which CIAM vendors are FedRAMP authorized?" "Identity platform that supports HIPAA and GDPR for a multi-region deployment." Compliance is often the first filter a security buyer applies, and AI systems answer these prompts by pulling from compliance documentation, certification listings, and vendor trust pages.Architecture-anchored prompts. "Zero-trust identity solution that integrates with existing SIEM and supports SAML and OIDC." Security buyers think in architecture. They want to know how a solution fits their stack and their security model before they care about features.Threat-model-anchored prompts. "Authentication solution resistant to phishing and session hijacking." The buyer is reasoning from the attacks they need to prevent backward to the solution, not from the feature list forward.Comparison prompts with constraints. "Compare Okta vs Ping vs ForgeRock for a regulated financial services environment." The comparison is never abstract. It is always scoped to the buyer's specific situation.A GEO approach that generates and tracks these prompt patterns is doing something a horizontal tool structurally cannot, because surfacing these prompts requires knowing how security buyers reason. That knowledge has to be encoded into the system, not derived from search volume.Which Sources LLMs Actually Trust in SecurityWhen an AI system answers a cybersecurity prompt, the sources it pulls from are not the sources it pulls from for a general business query. This is the crux of why authority is domain-specific, and it has direct consequences for what content actually earns citations.Across the cybersecurity domain, AI systems weight a recognizable set of source types more heavily:Primary research and original data. Security practitioners trust original research - threat reports, vulnerability analyses, original benchmark data. A vendor that publishes genuine primary research on, say, the prevalence of a specific attack pattern earns citations that a vendor recycling generic content never will. Models learn which sources produce findings that get referenced by other credible sources, and in security, original research is the strongest such signal.Framework and standards documentation. Content that engages seriously with NIST frameworks, OWASP guidance, ISO standards, and compliance requirements gets cited because these are the reference points security answers are built on. A vendor whose content maps clearly to recognized frameworks is more citable for the compliance-anchored prompts that dominate security research.Named technical experts. Security is a field where individual credibility matters enormously. Content published under the byline of a named, credentialed security expert carries more weight than anonymous corporate content. This is part of why thought leadership from identifiable practitioners outperforms faceless content marketing in this vertical specifically.Technical community presence. Security buyers validate vendors in specific communities, and AI systems increasingly pull from them. The research consistently shows community and forum content carries real citation weight, but in security the communities that matter are specific ones, not general forums.The implication for content audit is sharp. A generic audit would tell a security vendor their content needs better structure and more FAQ schema. Those are not wrong, but they are not the binding constraint. The binding constraint for most security vendors is that they have no primary research, no named experts publishing under their own names, and no credible engagement with the frameworks their buyers care about. An audit calibrated to security surfaces those gaps. A generic audit never sees them.A Worked Example: Auditing a Security Vendor for GEOTo make this concrete, consider how a vertical content audit differs from a generic one for a hypothetical CIAM vendor.A generic GEO audit produces findings like: pages lack FAQ schema, paragraphs are too long for extraction, comparison tables are missing, content is not updated frequently enough, headings are not phrased as questions.All true. All worth fixing. None of it touches the reason the vendor is losing AI citations to competitors.A security-calibrated audit produces different findings: the vendor has no published primary research that security practitioners cite, so models have no original work to attribute to them. Their content discusses features but does not map to NIST or compliance frameworks, so they are invisible for compliance-anchored prompts. No content is published under named expert bylines, so the vendor has no individual-authority signal in a field where that matters. They have no presence in the technical communities where security buyers cross-validate, so the third-party signal is absent. Their content answers "what does our product do" rather than the threat-model and architecture questions buyers actually ask.These two audits describe the same website and reach almost completely different conclusions about what to fix. The generic audit optimizes the packaging. The vertical audit identifies that the substance, judged by what security buyers and the models serving them actually value, is the problem. Fixing the packaging while ignoring the substance moves the needle slightly. Fixing the substance is what gets a vendor cited.This is the entire argument of this series, made concrete. The same content, audited against two different rubrics, yields two different roadmaps. For a vendor selling to CISOs, only one of those roadmaps reflects what their buyers respond to.What Security Vendors Should Do About ItIf you sell security or identity products to technical buyers, the path to AI visibility runs through becoming genuinely more citable to the audience and the models serving them. A few concrete priorities:Publish primary research. Original data and analysis is the highest-impact content a security vendor can produce for GEO. It earns citations, it gets referenced by other credible sources, and it signals to models that you produce work worth attributing. One genuine research piece outperforms ten generic blog posts.Map content to frameworks explicitly. Make the connection between your solution and the standards your buyers care about explicit and structured. This makes you citable for the compliance-anchored prompts that dominate security research.Put named experts forward. Have credentialed people publish under their own names. Individual authority is a real and underused signal in security, and it compounds over time as those experts get cited and recognized.Build presence where security buyers validate. Engage credibly in the technical communities your buyers actually use. The third-party signal matters, and in security it comes from specific places, not generic ones.Track the prompts your buyers actually ask, across models. Given the low citation overlap between platforms, you need to know where you stand on the specific, constraint-laden prompts that matter in security, on each model independently. Aggregate visibility numbers hide the platform-specific reality.None of this is achievable with a generic optimization checklist, because the checklist optimizes for the average buyer and the average buyer does not exist in security. The buyer is a specific CISO with specific constraints asking a specific model a specific question. GEO that works in this vertical is GEO calibrated to that reality.Part three of this series turns this into a practical evaluation tool: a checklist for assessing whether any GEO solution actually fits your vertical, so you can tell the difference between deep domain fit and generic monitoring with a vertical label.Related readingWhy GEO Has to Be Vertical: part one, the architectural argumentFIDO2 Implementation Guide: the kind of technical depth security buyers expectPassword Hashing Comparison: primary technical content that earns citationsSHA-2 Family Explained: framework-anchored technical referenceTop 5 GEO Tools of 2026 Compared: the platform landscape --- ## The Hard Truths About SaaS in 2026 URL: https://guptadeepak.com/hard-truths-about-saas-in-2026/ Published: 2026-05-29 Topic: SaaS Tags: SaaS, Startup, AI, Growth, Founders Summary: Building software just got 10x easier with AI. That breaks most of the 2015 SaaS playbook. Here are the new hard truths every SaaS founder needs to see clearly. Two things are simultaneously true about SaaS in 2026. The barrier to building software has collapsed; a single founder with Claude Code, Cursor, and a credit card can ship a production product in a weekend. The barrier to building a SaaS company, the kind with real revenue, retention, and a durable moat, has gone up. Most of the playbook that worked from 2015 to 2022 does not work now. --- ## Why GEO Has to Be Vertical (When SEO Never Was) URL: https://guptadeepak.com/why-geo-has-to-be-vertical-when-seo-never-was/ Published: 2026-05-28 Topic: GEO Tags: GEO, Generative Engine Optimization, AI Search, SEO, Vertical SaaS, B2B SaaS Summary: SEO became a horizontal layer because its substrate was uniform: one ranking algorithm, one signal set, one results format. GEO can't collapse that way. Here is the architectural reason. For twenty years, the same SEO tools worked for a dentist and a database company.Ahrefs, SEMrush, Moz - none of them needed an industry-specific version. A keyword research workflow built for plumbers worked, mechanically, for a fintech startup. You changed the keywords. The machinery stayed identical. The entire SEO industry consolidated into a handful of horizontal platforms because the optimization surface was the same regardless of what you sold.Generative Engine Optimization will not consolidate that way. And understanding why requires looking at what actually changed underneath the optimization problem when buyers moved from Google to ChatGPT, Perplexity, and Google AI Overviews.I have spent the past few years building a GEO platform specifically for cybersecurity and B2B SaaS. The deeper we got into the problem, the clearer it became that horizontal GEO is not a smaller version of the right answer. It is a structurally different answer to a problem that has a different shape than SEO ever did.This article makes the architectural case for why GEO has to be vertical. Not as a positioning preference. As a property of how AI search actually works.Why SEO Could Be HorizontalTo understand why GEO is different, you have to understand why SEO was able to commoditize into horizontal tooling in the first place.SEO worked on a uniform substrate. Three things stayed constant across every industry:One ranking algorithm. Google's algorithm was the same algorithm whether you sold software or shoes. The 200-some ranking factors didn't change by industry. The weighting shifted slightly for some query types, but the fundamental machinery - crawl, index, rank by relevance and authority - was universal.One signal set. The inputs that mattered were the same everywhere: backlinks, keyword relevance, page speed, mobile-friendliness, content depth, internal linking. A tool that measured these signals worked for any website because every website was being judged on the same signals.One results format. The output was always ten blue links. Whether you searched for "enterprise CIAM platform" or "best pizza near me," you got a ranked list of pages. The optimization target was identical: be higher on that list.Because the substrate was uniform, the optimization tooling could be uniform. Industry was a variable you plugged into the machine - the keywords, the competitors, the content topics. The machine itself never changed.This is why one Ahrefs could serve every vertical. The horizontal model wasn't laziness or a market accident. It was the correct architecture for a problem with a uniform substrate.Why GEO's Substrate Is Not UniformGEO breaks every one of those constants. The substrate underneath AI search is high-dimensional in a way that the substrate underneath traditional search never was.There is no single algorithm. There are many, and they disagree.ChatGPT, Perplexity, Gemini, Claude, and Google AI Overviews each select and cite sources through different pipelines. This is not a minor variation. Research across multiple independent studies in 2026 found that only about 11% of domains receive citations from both ChatGPT and Perplexity. The same query, run on two different models, produces almost entirely different sources.The differences are structural. ChatGPT favors Wikipedia heavily. Perplexity pulls a far higher share from Reddit and community content. ChatGPT and Google AI Mode pull most of their LinkedIn citations from individual member posts, while the weighting differs across platforms. Claude relies more on training data with a knowledge cutoff; Perplexity crawls the live web at query time. Google AI Overviews correlates more closely with traditional search rankings than the others.Optimizing for "AI visibility" as a single thing is like optimizing for "weather." There is no aggregate weather. There is weather in specific places. Optimizing for an average that no real buyer experiences produces content that performs mediocre everywhere and excellent nowhere.The answer depends on user context, not just the query.Traditional search treated a query as a query. Two people typing "best CIAM platform" got the same ten links. The query was the whole input.AI search incorporates context. The role of the person asking, the framing of their prompt, the conversation that preceded it, the way they describe their situation - all of it shapes the answer. A CISO asking ChatGPT to compare identity platforms for a regulated healthcare environment gets a fundamentally different answer than a startup founder asking the same nominal question with different framing. The models reason about the context, not just match the keywords.This means the unit of optimization is not a keyword. It is a buyer-intent-in-context. And buyer intent in context is, by definition, specific to who the buyer is - which is specific to the vertical.The retrieval depends on query fan-out, which is domain-specific.When a buyer asks an AI system a question, the model doesn't run one search. It decomposes the question into multiple sub-queries, retrieves sources for each, and synthesizes an answer. This is called query fan-out.The sub-queries a model generates from "compare zero-trust vendors" are nothing like the sub-queries it generates from "compare email marketing tools." The fan-out for a security question pulls in compliance frameworks, CVE databases, architecture patterns, and analyst coverage. The fan-out for a marketing question pulls in review sites, pricing pages, and feature comparisons. To optimize for the fan-out, you have to know what the fan-out looks like in your domain. There is no universal fan-out to optimize for.What Authority Means Changes by DomainThe deepest reason GEO has to be vertical is that LLMs make domain-specific judgments about what counts as authoritative. And those judgments are exactly where horizontal tools are blind.In traditional SEO, authority was largely domain-agnostic. A high domain rating, a strong backlink profile, topical relevance - these were measured the same way everywhere. A backlink from a high-authority site helped you regardless of industry.LLMs evaluate authority differently, and the evaluation is contextual to the subject matter. Research in 2026 found that the average domain age of ChatGPT-cited sources is around 17 years, indicating established entities get preferential treatment. Domains with G2, Capterra, and Trustpilot profiles show roughly 3x higher citation probability for software queries. But which third-party validators matter depends entirely on the category. G2 matters for SaaS. It is irrelevant for industrial manufacturing, where ThomasNet and GlobalSpec carry the authority signal instead.Here is the part horizontal tools miss. When an LLM answers a cybersecurity question, the sources it trusts are not the sources it trusts for a marketing question. For security, the model weights primary research, CVE writeups, framework documentation, vendor security disclosures, and analyst coverage. A generic GEO tool optimizing for "authoritative content" cannot tell a cybersecurity vendor that their problem is not their FAQ schema - it is that no model trusts them on zero-trust architecture because they have never published primary research that security practitioners cite.That diagnosis requires knowing what authority looks like in security specifically. A horizontal tool applies a generic authority rubric and produces generic advice. The advice is not wrong, exactly. It is just optimizing for the average, which means it systematically misses the domain-specific signals that actually determine citation in any given vertical.The Three Things a Vertical GEO Engine Has to Do DifferentlyIf the substrate is high-dimensional and domain-specific, a GEO solution that actually works has to be vertical in three specific places. These are not features. They are the architecture.1. Prompt generation has to be vertical.The starting point of GEO is knowing which prompts matter - the actual questions buyers ask AI systems when researching solutions in your category. A horizontal keyword tool will not surface these, because they are not keywords. They are how a specific buyer, in a specific role, interrogates an AI assistant.A cybersecurity buyer does not ask "best identity platform." They ask something like "SOC 2 compliant CIAM with SCIM provisioning for a healthcare SaaS" or "passwordless authentication vendor that supports FIDO2 and has FedRAMP authorization." Those prompts come from understanding how CISOs and security engineers actually think, not from keyword volume data. Generating the right seed prompts requires domain knowledge encoded into the system.2. Response and data quality scoring has to be vertical.Once you know the prompts, you have to mine the responses for quality - which sources the models cite, whether those citations are favorable, and what content is driving them. But judging whether a citation is good requires knowing what good means in the domain.For a security buyer, a citation in a SANS Institute resource or a reference in a CVE analysis is a high-quality signal. A mention in a generic listicle is noise. A horizontal tool that counts all citations equally gives you a number that does not correlate with actual buying influence. A vertical engine weights the data by what carries authority with the specific audience - which means it needs a quality filter calibrated to the industry's trust signals.3. Content audit has to be vertical.The final piece is auditing existing content against the right rubric. This is where the wrong approach does the most damage, because it produces confident, specific, wrong advice.A horizontal audit tells a cybersecurity vendor to add FAQ schema, shorten paragraphs, and include comparison tables. All reasonable generic advice. None of it addresses the real gap, which might be that the vendor has no primary research, no named technical experts publishing under their own bylines, and no presence in the communities where security practitioners actually validate vendors. Auditing against a security-specific rubric surfaces the real problems. Auditing against a generic rubric surfaces generic problems and misses the ones that matter.The Honest TradeoffVerticalization is not a free win. It is a tradeoff, and pretending otherwise would undermine the whole argument.A vertical GEO engine is, by design, narrow. The system we built for cybersecurity and B2B SaaS is strong precisely because it encodes deep assumptions about those buyers - and those same assumptions make it the wrong tool for a direct-to-consumer retail brand or a hospitality business. The prompt generation, the authority weighting, the audit rubric are all calibrated to technical B2B buyers. Point that engine at an e-commerce catalog and the calibration works against you.This is the real reason horizontal tools exist and will continue to exist. They serve the long tail of businesses that need basic AI visibility monitoring across every industry. For broad, shallow coverage, horizontal is the right architecture. For deep performance in a specific category where the buyers are sophisticated and the stakes per deal are high, vertical is the right architecture.The mistake is assuming one of these is simply better. They solve different problems. The question for any given company is which problem they actually have. A company selling six-figure enterprise contracts to CISOs has a fundamentally different GEO problem than a company selling consumer subscriptions, and the tool that fits one will misfit the other.What This Means If You're Choosing a GEO SolutionThe practical takeaway is a different evaluation question than most buyers are asking.The common question is "which GEO tool has the best monitoring across the most AI platforms?" That is a reasonable question for broad visibility tracking. But if you sell into a specific, sophisticated vertical, it is the wrong primary question.The better question is: does this solution understand my buyers well enough to generate the prompts they actually ask, judge citations by what carries authority with them, and audit my content against the standard my industry's AI answers are actually being held to?A tool can monitor ten AI platforms beautifully and still give you a generic optimization roadmap that moves you toward the average. For a horizontal business, the average is fine. For a vertical business selling to demanding buyers, the average is exactly what loses you the deal, because your competitors who got the domain-specific signals right are the ones the models cite.SEO could be horizontal because the substrate was uniform. GEO's substrate is not uniform - it varies by model, by context, by buyer, and by what authority means in each domain. The optimization has to match the shape of the problem. And the shape of the GEO problem is vertical.Part two of this series examines what this looks like in practice for one vertical: how cybersecurity buyers actually use AI to research vendors, the prompt patterns that matter, and which sources LLMs trust in security. Part three provides a checklist for evaluating whether a GEO solution fits your vertical.Related readingTop 5 GEO Tools of 2026 Compared: the current GEO platform landscapeFuture of AI 2026: where AI search is headingMCP, RAG, and ACP Comparison: the retrieval infrastructure underneath AI answersGrok AI Explained: understanding the AI model landscapeAI Tokens Guide: how LLMs process and weight information --- ## Ten Skills I Gained Building Tech Companies (That I Wish I'd Learned Sooner) URL: https://guptadeepak.com/ten-skills-i-gained-building-tech-companies/ Published: 2026-05-28 Topic: Entrepreneurship Tags: Entrepreneurship, Founders, Leadership, Career, Startup Summary: The ten skills that actually move the needle for tech founders, from a CIAM founder who scaled to a billion users and is now building in AI security. I started my career as a developer. Coding was the easy part. The hard part, the part I had no training for, was everything that turns code into a company. The CIAM platform I built scaled to a billion users, then to a real revenue line, then to a real organisation. Every step taught me something I wish someone had handed me on a printout in year one. These are the ten skills I actually use now, building my next company in AI and security. --- ## Software Development with AI: What Actually Works in 2026 URL: https://guptadeepak.com/software-development-with-ai-what-actually-works-in-2026/ Published: 2026-05-27 Topic: AI Tags: AI, Software Development, Developer Tools, Engineering, Productivity Summary: An honest practitioner's view of AI-assisted software development in 2026: what Cursor, Claude Code, Copilot, and Devin actually do well, and where they still break. The unit of software work has changed. Three years ago, the unit was a function: I would write one, review it, ship it. Today, the unit is a feature: I describe what I want, an agent writes ten files, I review the diff, push back, ship. This is the working notes of a founder who has shipped production code with Claude Code, Cursor, GitHub Copilot, and Devin over the past 18 months. --- ## The Top Cybersecurity YouTube Channels to Learn From in 2026 URL: https://guptadeepak.com/top-cybersecurity-youtube-channels-to-learn-from/ Published: 2026-05-26 Topic: Cybersecurity Tags: Cybersecurity, Learning, YouTube, Career, Education Summary: A categorised, founder-curated list of 44 cybersecurity YouTube channels organised by what you actually want to learn: offense, defence, bug bounty, certs, careers. If I had to redo my own cybersecurity education from scratch in 2026, I would skip most of the books and most of the certifications and start on YouTube. The depth and quality of free security content on the platform is higher than any paid course I have taken, and it updates faster than any printed material can. Below are 44 channels I have either learned from directly or seen consistently recommended by people I trust, grouped by what you are trying to learn. --- ## Google I/O 2026: The Agentic Web Just Went Into Production URL: https://guptadeepak.com/google-io-2026-recap-agentic-web/ Published: 2026-05-25 Topic: AI Tags: AI, Agentic AI, Google I/O 2026, Gemini, B2B SaaS, Machine Identity Summary: Google I/O 2026 shipped an entire agent stack: Gemini 3.5 Flash, Antigravity 2.0, WebMCP, Gemini Spark, and Agent Payments Protocol. What it means for builders. Two years ago, Google processed 9.7 trillion tokens a month across its surfaces. Last year at I/O, that number was 480 trillion. As of last week, it is over 3.2 quadrillion per month, a 7x jump in twelve months. That single statistic from Sundar Pichai's opening keynote is the entire story of Google I/O 2026. Google did not ship a new flagship; it shipped a vertical agent stack. Here is what every operator, builder, and security leader needs to take from two days that quietly rewired the web. --- ## 30 Cybersecurity Search Engines Every Researcher Should Bookmark URL: https://guptadeepak.com/30-cybersecurity-search-engines-for-researchers/ Published: 2026-05-25 Topic: Cybersecurity Tags: Cybersecurity, OSINT, Threat Intelligence, Research, Tools Summary: A curated, categorised guide to 30 search engines that security researchers actually use: Shodan, Censys, Dehashed, ExploitDB, and the rest. Google indexes the open web. Security researchers need to find things the open web hides: exposed devices, leaked credentials, certificate transparency logs, S3 buckets misconfigured for the world to read, code snippets that include API keys. That work runs on a different layer of the internet, and it has its own search engines. Below are 30 search engines I have either used myself for security work or seen used effectively by people I trust, grouped by what they actually do. --- ## Speaking at SaaStr AI Annual 2026: Why LLM Visibility Is the GTM Shift Nobody Saw Coming URL: https://guptadeepak.com/saastr-ai-annual-2026-llm-visibility-gtm/ Published: 2026-05-23 Topic: AI search visibility Tags: AI and B2B SaaS growth, AI search visibility, AI (Artificial Intelligence), SaaS, B2B, growth Summary: First time on the SaaStr stage. 12, 500 founders and operators. One message: if your company isn't showing up in ChatGPT, Perplexity, and Google AI First time on the SaaStr stage. 12, 500 founders and operators. One message: if your company isn't showing up in ChatGPT, Perplexity, and Google AI Overviews, you don't have a GTM problem, you have a visibility problem nobody has named yet. Notes from speaking at SaaStr AI Annual 2026 and Chargebee Beelieve '26. --- ## The Pricing Model That Proves You're Actually AI-Native URL: https://guptadeepak.com/ai-native-outcome-based-pricing-2026/ Published: 2026-05-22 Topic: AI and B2B SaaS growth Tags: AI and B2B SaaS growth, AI (Artificial Intelligence), SaaS, B2B, growth, Enterprise Summary: Per-seat pricing made sense when software was a tool. When software becomes the labor, the math breaks. Per-seat SaaS is collapsing fast. Intercom's Fin hit $100M ARR at $0.99 per resolution. Zendesk just followed. Here's what outcome pricing really signals about whether a vendor is genuinely AI-native or just bolting AI onto a legacy stack. --- ## I Spent a Decade Building a Password Company. Here's Why I'd Tell You to Kill Yours URL: https://guptadeepak.com/decade-building-password-company-kill-yours/ Published: 2026-05-20 Topic: cybersecurity Tags: cybersecurity, passkeys, password, passwordless, future of passwords, identity, identity management Summary: I spent ten years engineering, scaling, and defending password-based authentication for a CIAM platform that grew to a billion users. I founded a CIAM platform in 2013 and scaled it to over a billion user identities. For a decade, my technical life revolved around making passwords work: hashing them properly, rotating them sensibly, recovering them safely, layering on MFA when the basic primitive was not enough, building bot defenses to keep credential stuffers out, monitoring breach corpora to know when our users' credentials had leaked from somewhere else.I am as proud of that engineering as anything I have built. And I would tell you, today, to kill yours.This is not a marketing post. There is no upsell at the bottom. It is the conclusion I reached the hard way, and it is the conclusion every CISO I respect has reached too. We were defending the wrong castle.The thing nobody told me on day oneWhen you start in identity, you spend the first six months learning that passwords are bad. You learn about rainbow tables, you learn about Argon2, you learn the difference between salting and peppering. You absorb the cybersecurity orthodoxy: the password is a flawed primitive, but with enough engineering, you can make it survive.What no one tells you on day one is the second half of that lesson. The engineering keeps escalating. Forever.Hashes need salts. Salts need peppers. Peppers need HSMs. The HSM strategy needs key rotation. Key rotation needs an operational team. The team needs runbooks. The runbooks need audits. And every additional control adds attack surface somewhere else.Meanwhile, the user is typing the same password they used on a forum that got breached three years ago.What a billion users taught meWhen you operate authentication for a billion identities, you stop talking about edge cases. Every edge case happens to you, every day, thousands of times.You learn that the rate of credential reuse across services is brutal. North of 60 percent of breached credentials work on a second site. We watched it in our logs.You learn that account recovery is where attackers actually win. Not at the login screen. At the "I forgot my password" screen, where a security question becomes a social engineering attack.You learn that SMS OTP fails in production well before NIST formally downgrades it. SIM swap attacks, telco vulnerabilities, regional carriers that route OTPs through systems no one audits.You learn that the cost of fraud and support and engineering and compliance, summed across the whole stack, dwarfs any line item in the buy-versus-build spreadsheet. The password is not free. The password is the most expensive thing in your identity stack. You just do not see the line item.And the worst part: every layer you add (MFA, KBA, adaptive risk, device fingerprinting) is paying down complexity interest on a primitive that should not exist anymore.The moment the math flippedFor me, the moment was watching a passkey deployment. The support volume for "I forgot my password" dropped roughly 80 percent within a quarter. The account takeover rate on those accounts went to effectively zero. The flow was faster than the password flow. Users preferred it. Engineering had less to maintain.That was the moment I understood what we had been doing wrong for a decade. We had been adding controls to a broken primitive when we should have been replacing the primitive.Every credential breach that hits the news is downstream of this same mistake. The credentials in those dumps exist because the system requires them to exist. Replace the requirement and the dump becomes worthless. There is nothing to phish if there is nothing to type.What I would tell my younger selfIf I could send one message back to the day I started designing the auth stack, it would be this: do not optimize the password. Plan the migration off it.Specifically:Build passkey support as a first-class citizen, not a "feature flag for later." The infrastructure to manage WebAuthn credentials, attestations, account recovery for passkey accounts, multi-device sync, is the work. Start it on day one.Treat MFA as a bridge, not a destination. Every dollar you spend hardening SMS or TOTP is a dollar you will throw away in 24 months. Skip the bridge if you can. Go to phishing-resistant directly.Design recovery flows for a passwordless world from the start. Recovery is where attackers attack. If your recovery flow falls back to email or SMS, you have not gone passwordless. You have just hidden the password.Measure the right thing. Login success rate matters less than fraud rate per successful login. Account takeover rate matters more than complexity score. You will not get the right behavior from your team unless you measure the right things.The honest partI am not anti-password because I read a paper. I am anti-password because I built and operated a password system at a scale where the failure modes were not theoretical. Every one of them happened. Many of them happened weekly.A founder building today has an advantage I did not have in 2013: passkeys are real, browser support is broad, the platforms have shipped credential sync, and the user mental model is no longer alien. You can launch a product in 2026 that has never had a password field, and a user can sign up in five seconds with biometrics, and the credential lives in a key store the user cannot read out and the attacker cannot type into your login form.That is what I would build today. That is what I am building today, in the parts of the GrackerAI stack that touch identity, we have passwordless auth for our customers.The decade taught me a lot. The biggest lesson was the one I did not want to learn. We were brilliant defenders of a primitive that should not have existed.What is keeping you on it?FAQAre passkeys really ready for production today?Yes, with caveats. Browser support is broad, OS support is broad, and the major platforms now sync passkeys across a user's devices. The remaining hard problems are recovery flows when a user loses all devices, and enterprise lifecycle management, both of which are tractable.Is going passwordless realistic for a B2C product with millions of users?Yes, but not as a big-bang migration. The realistic path is to add passkey as an option, prefer it on subsequent logins, then require it for new accounts. Existing password users migrate over months, not weeks.What about users without modern devices?This concern is shrinking faster than most teams plan for. Passkey support is now standard on every device shipped in the last several years. For the long tail, magic links and one-time codes are reasonable fallbacks, with the understanding that they are not phishing-resistant.Does this mean MFA was a waste?No. MFA was the right interim step for a generation of products. The mistake is treating MFA as a destination rather than a bridge. The same engineering effort, applied to a passkey rollout, gets a better outcome.What is the single highest-ROI move for a team still on passwords today?Add passkey as an authentication option, default it for users who have enrolled one, and run that experiment for a quarter. The data will tell you the rest.About the authorDeepak Gupta is a serial entrepreneur and cybersecurity researcher, who founded and scaled a CIAM platform to 1B+ users. He writes about AI, cybersecurity, and B2B growth at guptadeepak.com. --- ## Programming in 2026: Should Students Still Learn Code? URL: https://guptadeepak.com/programming-in-2026-should-students-still-learn-code/ Published: 2026-05-19 Topic: software Tags: software, developers, development, future, digital coworker, agentic, agents, coding, vibe coding Summary: AI generates code faster than humans can review it. So why are computer science enrollments hitting record highs? 30% of code at major tech companies is now AI-generated. Computer science enrollments hit record highs the same year. The two trends sound contradictory. They are not. After building a CIAM platform that served over a billion users, and now building GrackerAI, I keep getting the same question from parents, students, and career changers: should I still bother learning to code? Short answer: yes. Longer answer: the question itself is outdated. The shift nobody is teaching The old programmer wrote code. The 2026 programmer directs it, reviews it, and decides what to build in the first place. That sounds like a small change. It is not. It changes what universities should teach, what bootcamps should drop, and what students should optimize for over the next five years. In my own work today, the ratio has flipped. Less time writing code from scratch, more time reviewing AI output, even more time deciding what to build and why. The skill that scales is no longer fast typing in your favorite language. It is the judgment about whether AI-generated code is right, safe, and worth shipping. If you want a deeper view of where this is heading, I covered the broader picture in my future of AI breakdown. Why programming still matters You cannot direct what you cannot read. Every product manager I know who learned to read code (not write it, just read it) became more effective overnight. They stopped trusting engineering estimates blindly. They started asking better questions. They caught bad architecture decisions before they shipped. The same logic applies to anyone working with AI. If you cannot read code, you cannot: * Verify what the AI gave you * Spot security issues in generated output * Know when the model is hallucinating function calls * Catch the subtle bugs that look correct but are not I have watched teams ship AI-generated code with hardcoded credentials, broken authentication flows, and SQL injection vectors. Every single time, the root cause was the same: nobody on the team could read what the AI wrote well enough to catch the problem. Programming literacy is the new spreadsheet literacy. You do not need to be an accountant to need Excel. You will not need to be a developer to need to read code. The new CS curriculum Here is what I would teach a student today if I had one semester: 1. Systems thinking What happens when this service cannot reach that database at 3am? Why does a 200ms latency increase take down checkout? How does a single bad deploy cascade across microservices? This is the work AI is worst at. It requires holding the entire system in your head and reasoning about failure modes that have not happened yet. The old curriculum buried this in senior-year electives. It should be week one. 2. Code review at scale You are not writing 100 lines a day anymore. You are reviewing 1,000 from an AI that is confidently wrong often enough to matter. Reading code fast, spotting the off-by-one, noticing the missing error handler, catching the subtle race condition: these are the new core skills. Most CS programs barely teach them. 3. Security intuition AI-generated code creates vulnerabilities that AI-generated code cannot catch. Hardcoded secrets, broken auth, weak hashing, missing input validation. I covered the hashing layer of this problem in detail in my analysis of Argon2, bcrypt, scrypt, and PBKDF2, and the browser-side risks in my 2025 browser security guide. The principle is simple: every line of generated code is a security decision somebody on your team has to own. Students who graduate without basic security intuition are graduating obsolete. 4. Specification skills Most production bugs trace back to fuzzy requirements, not bad implementation. AI makes this worse, because it confidently fills in the gaps you left ambiguous. Writing clear specs is now a programming skill. So is asking the right clarifying questions before a single line gets generated. CS programs treat this as "soft skills." It is the hardest skill. 5. Architecture and tradeoff judgment Choosing between three valid technical approaches is the work AI cannot do for you. It will happily give you all three, with confident reasoning for each. The decision is yours, and the decision is where products live or die. If you want to see how this plays out in modern AI systems, my comparison of MCP, RAG, and ACP walks through the tradeoffs engineers are wrestling with in production right now. What future developers actually look like Less "wrote 500 lines today." More "shipped a decision that saved the company three months." Less time in syntax. More time in design docs, system diagrams, and architecture reviews. Less specialization in a single language. More fluency across a stack, because AI removes the friction of context-switching between languages you do not use every day. Less hierarchy by years of experience. More hierarchy by judgment and systems intuition, which compound faster than ever now that AI handles the mechanical work. The developer who used to need eight years to ship at staff level can now do it in four, if they spend those four years on judgment instead of syntax. The developer who only learned to type code will plateau early, regardless of how many years they put in. Practical advice for students starting now If I were 18 and entering CS today, here is what I would do: 1. Pick a CS degree, but treat half the curriculum as historical context and the other half as foundation. 2. Learn one language deeply (Python or TypeScript) and one systems language casually (Go or Rust). 3. Spend more time on databases, networking, and security than on the next trendy framework. 4. Ship side projects that use AI as a teammate, not a crutch. Build something real. Break it. Fix it. Ship it. 5. Read more code than you write. Open-source repos, production codebases, AI-generated output. Reading code is now the primary act of programming. 6. Take cybersecurity seriously from year one, not year four. 7. Understand how AI costs scale, because your future architecture decisions will hinge on it. My AI tokens guide is a good starting point. The students who do this will be operating like senior engineers two years into their careers. The students who do not will be wondering why their 200 LeetCode solutions did not translate into a job. What I am not worried about I am not worried about programming dying. I am not worried about CS becoming useless. I am not worried about a generation of kids picking the wrong major. I am worried about CS programs that have not updated their first-year syllabus since 2015. I am worried about students optimizing for the interview format that AI just made obsolete. I am worried about parents telling their kids to "skip programming and learn AI" as if those are two different things. Programming is not dying. The narrow definition of programming as "writing syntax fast" is dying. What replaces it looks more like engineering: judgment, systems thinking, security, and decision-making at speed. The people who learn this version of programming are going to do extraordinary work. The people who do not will get replaced, not by AI, but by the developers who know how to use it. What is one thing your CS program taught that you think will not matter in five years? FAQ Do students still need to learn programming in 2026? Yes. AI writes a growing share of production code, but it cannot verify, review, or own that code. Programming literacy is now closer to spreadsheet literacy than to a specialized trade. If you want to direct AI well, you have to be able to read what it produces. Will AI replace programmers? No. AI is replacing the narrow definition of programming as "writing syntax fast." It is not replacing engineering: systems thinking, security judgment, architecture decisions, and clear specification. Developers who only typed code will be replaced. Developers who reason about systems will be more valuable than ever. What programming language should students learn in 2026? One application language deeply (Python or TypeScript) and one systems language casually (Go or Rust). Language fluency matters less than it used to, because AI removes the friction of switching between languages. Depth in fundamentals matters more. Is a computer science degree still worth it? Yes, if you treat it correctly. Use it as foundation in algorithms, systems, databases, networking, and security. Do not treat the syntax-heavy parts as the point. Pair the degree with shipped projects, open-source contributions, and security fundamentals from year one. What skills will future developers need? Systems thinking, code review at AI scale, security intuition, specification writing, and architecture judgment. These are the parts of engineering AI is worst at and the parts that compound fastest in a career. About the author Deepak Gupta is a serial entrepreneur and cybersecurity researcher, who founded and scaled a CIAM platform to 1B+ users. He writes about AI, cybersecurity, and B2B growth at guptadeepak.com. * Curated List of Books for Builders * Technology Podcast to build your skills --- ## 19 Billion Passwords Are Circulating. The Number Isn't the Story URL: https://guptadeepak.com/19-billion-passwords-are-circulating-the-number-isnt-the-story/ Published: 2026-05-17 Topic: cybersecurity Tags: cybersecurity, password, identity, breach, customer data, future of passwords Summary: Every headline put the 19 billion figure in 60-point type. Almost none of them mentioned that the unique entry rate is in the single digits. When the "19 billion compromised passwords" story hit, my inbox lit up with the same question from a dozen founders. "Should we be panicking?" The honest answer: panic at the number is the wrong panic. The number is theater. What sits underneath the number is the actual story, and it is harder to fix than rotating credentials. Here is what I told them. The 19 billion figure is mostly recycled When researchers report a "compilation," the headline counts every line in every file across every breach they have indexed. That math is impressive in a screenshot and almost useless operationally. Once you de-duplicate, single-digit percentages of that dataset are unique credentials. The rest is the same passwords from the same accounts surfacing in compilation after compilation, the same way the same songs end up on every "greatest hits" album. The serious analysis behind these stories repeatedly lands in the same place: a large share of the data comes from infostealer logs, not from a fresh breach of any one provider. Infostealers harvest whatever sits in browser-saved credentials on infected machines. So "19 billion" is really "credentials that escaped, over the years, from people who clicked the wrong installer." If you treat this as a fresh-breach event and run a forced password reset, you have done something that feels like action and changes very little. The credentials that hurt you were already out in the open. Many were out years ago. What it actually proves Strip away the count and the lesson is uncomfortable. The password as an authentication primitive is finished. We have spent two decades trying to patch around it. Complexity rules. Rotation policies. Password managers. KBA. Then we layered MFA on top because the primitive itself could not carry the load. Every layer added cost. Every layer leaked. SMS OTP got SIM-swapped. Security questions got socially engineered. Even TOTP, the better second factor, gets phished in real time by attacker-in-the-middle kits that proxy your login session. The 19B headline is a marker of how thoroughly the primitive has failed. We are not arguing about whether passwords are insecure anymore. We are arguing about how fast organizations can move off them. The infostealer reality your stack has to assume Treat any password your users have typed into any site, ever, as compromised. Not someday. Now. The 19B compilation is one of several published in the last 18 months. None of them will be the last. That assumption changes the design of your stack in three ways. First, the password is no longer a security control. It is a deprecated legacy input you are tolerating during a migration. Plan the migration explicitly. Set a target date. Communicate it. Second, the second factor has to be phishing-resistant. SMS OTP fails this bar. Push notifications without number matching fail this bar. Passkeys pass. FIDO2 security keys pass. Anything cryptographically bound to the origin passes. Third, detection has to assume credentials are valid before the session starts. Behavior, device posture, geo-velocity, impossible travel: these are not nice-to-haves once you accept that the credential is no longer evidence of identity. They are the perimeter. The checklist I would hand a CISO this week If you are running a credential-based stack right now, this is the order I would work it. 1. Identify your top three accounts to protect by blast radius: admin accounts, support tooling, anything with destructive permissions on customer data. Move these to phishing-resistant MFA in the next 30 days. No exceptions, no breakglass that bypasses the policy without alerting. 2. Run a credential-monitoring sweep against published breach corpora. You almost certainly have users whose current password is in one. Force a reset on hit, but reset to passkey, not to another password. 3. Kill SMS OTP wherever it is still a "second factor." NIST quietly stopped treating it as AAL2-grade years ago. Most of your stack is overdue. 4. Add login-time signals: device, IP reputation, behavioral baseline, impossible travel. If you cannot deploy these in-house, your CIAM vendor almost certainly offers them and you are not using them. 5. Start the passwordless migration. The right way to start is not "remove the password." It is "let users add a passkey, prefer passkey on login, then later make passkey mandatory for new accounts." The path is incremental, not big-bang. 6. Pick a sunset date for password-only login for new accounts. Twelve months out is aggressive but defensible. Eighteen months is realistic. Put it on a roadmap slide and brief the board. The thing you do not have to do You do not have to do an emergency forced reset for everyone. That is the panic response, and it generates support volume without buying you much. Users who reset to "Password1!" become "Password2!" and the credential is still in the next compilation. What you have to do is treat the password itself as the bug. Every project that ends with a stronger password is treating the symptom. Every project that ends with a key pair on a phone, bound to your origin, is treating the cause. That is what I would actually tell a CISO this week. The 19 billion headline is a useful forcing function. It is a terrible diagnosis. What is your next move? If you are early in the passwordless conversation internally, the passwordless authentication guide lays out the migration path. If you are mid-breach response and trying to size the credential-stuffing exposure, the credential stuffing and ATO breakdown covers what the attackers actually do with this data once it leaks. FAQ Are there really 19 billion unique compromised passwords? No. The 19B figure counts every entry across every breach in a compilation. Once you deduplicate by unique credential, the truly unique entry rate is in the single-digit percentages. Most of the data is recycled from previously known breaches and infostealer logs. Should I force a password reset for all users? Not as the primary response. Forced resets generate support volume without addressing the underlying issue: the password itself is the weak primitive. Use credential monitoring to target users with known-compromised passwords, and pair every reset with a passkey enrollment prompt. Is SMS OTP still good enough as a second factor? No. SMS OTP is vulnerable to SIM swapping and is no longer treated as AAL2-grade authentication under NIST SP 800-63B revisions. Phishing-resistant options like passkeys, FIDO2 keys, or push with number matching are the current baseline. What is the fastest path to phishing-resistant authentication? Start by enabling passkeys for new sign-ins, prefer passkey login when available, and require passkeys for high-risk operations. For admin and high-blast-radius accounts, deploy FIDO2 hardware keys within 30 days. Build toward a sunset date for password-only login on new accounts. How is this breach different from past compilations? Operationally, it is not. It is larger, more publicized, and triggered more news cycles. The underlying mechanics (infostealers harvesting browser-saved credentials, prior breach data being repackaged) are the same. The lesson is the same too: the password is the bug. About the author Deepak Gupta is a serial entrepreneur and cybersecurity researcher, who founded and scaled a CIAM platform to 1B+ users. He writes about AI, cybersecurity, and B2B growth at guptadeepak.com. --- ## Citation Share: The Metric Cybersecurity CMOs Should Be Reporting to the Board in 2026 URL: https://guptadeepak.com/citation-share-the-metric-cybersecurity-cmos-should-be-reporting-to-the-board-in-2026/ Published: 2026-05-14 Topic: cybersecurity Tags: cybersecurity, GEO, AEO, metrics, marketing, insights, analysis, citation, CMO Summary: Traditional marketing metrics are becoming less predictive of pipeline as buyers shift to AI-powered research. I had a conversation last month with a cybersecurity CMO that's still rattling around in my head. Her company had just finished a great quarter by traditional marketing metrics. Domain authority up. Organic traffic up. MQLs hitting plan. She'd walked her board through a confident dashboard. Two days later, she opened ChatGPT - something she'd resisted doing professionally for months - and asked it to recommend vendors in her category. Her company didn't show up. Neither did her closest competitor. Two vendors she'd never considered serious threats were cited prominently. "The worst part," she told me, "isn't that we weren't there. The worst part is that none of my metrics would have told me we weren't there. My dashboard is still green." This is the core problem with how cybersecurity marketing is measured right now. Traditional metrics - rankings, traffic, MQLs, cost-per-lead - are growing increasingly decoupled from pipeline as buyers shift to AI-powered research. Data from Opollo's 2026 benchmark across 312 technology service firms shows AI-referred traffic converts at 14.2% compared to 2.8% for Google organic - a 4–5x conversion gap. HubSpot's own data shows customer organic web traffic declined 27% year over year while AI-driven sources are increasing. One cybersecurity firm in the GrackerAI benchmark had 50,000 monthly Google visitors and zero ChatGPT citations in their category. Meanwhile, a smaller competitor with a fraction of that traffic was being recommended consistently across AI platforms. If your marketing dashboard doesn't include a metric for AI visibility, your dashboard is measuring a channel that's shrinking while ignoring the one that's growing. The metric you need is citation share. It's the closest thing the AEO/GEO discipline has to a north star, and for cybersecurity specifically, it deserves a spot on your quarterly board deck next to pipeline and revenue. This guide walks through the methodology we developed at GrackerAI for measuring citation share - how to build a defensible benchmark, how to test across platforms, what "good" looks like at different company stages, and how to report it to a board that's never heard of AEO. What Citation Share Actually Measures (And Why It's Different From Everything Else) Citation share is the percentage of relevant buyer-intent prompts across which your brand gets cited when asked to AI engines. If you define a benchmark of 100 prompts and your brand appears in the response or citation list for 23 of them, your citation share is 23%. That seems simple. The methodological rigor is in the details. What makes citation share fundamentally different from traditional marketing metrics is that it measures presence in the decision-making conversation itself, not the infrastructure surrounding it. Google rankings measure whether you can be found if someone searches for a specific keyword. Citation share measures whether you're mentioned when a buyer asks for a recommendation. Those are different questions with different answers. It's also binary in a way traditional search isn't. When AI engines generate responses, they typically cite only 2 to 7 sources per answer, and they don't show a "page two" the way search engines do. Early research from Leadscale and others suggests brands not cited in the AI summary receive essentially nothing from that query - there's no long-tail consolation traffic. This is why citation share is such a high-stakes metric. Being cited and not being cited aren't shades of the same outcome. They're completely different outcomes. For cybersecurity vendors, citation share carries particular weight because 78% of cybersecurity buyers shortlist only vendors whose names they already recognize. If AI tools aren't putting your name into the buyer's awareness, you never enter the shortlist. The risk-averse behavior that makes cybersecurity buying cycles slow also makes AI citations disproportionately valuable - they're often how a vendor name first lands in the buyer's consideration set. How to Build a Defensible Benchmark Prompt Set The quality of your citation share measurement is entirely dependent on the quality of your benchmark prompt set. A bad benchmark produces meaningless numbers; a good benchmark becomes an asset that pays dividends across marketing, product, and sales. Here's the methodology I recommend. Start with 100 prompts as your minimum viable benchmark. Fewer than that and statistical noise overwhelms trend signal. Three hundred is ideal for a mid-market vendor; large enterprise vendors with multiple product lines should run 500+. Structure the benchmark across four prompt types. Category-defining prompts ("best [category] software"), comparative prompts ("[Competitor] vs [Competitor]"), use-case prompts ("best SIEM for healthcare HIPAA compliance"), and alternative prompts ("alternatives to [Market Leader]"). Each type taps a different buyer intent and surfaces different citation patterns. For cybersecurity vendors, I'd weight heavily toward use-case prompts - they're how technical buyers actually frame questions to AI tools. Map prompts to your three buyer personas. For each prompt, tag it as a security engineer prompt, procurement/compliance prompt, or CISO/decision-maker prompt. This lets you analyze citation share not just in aggregate, but by persona - which turns out to be one of the most actionable segmentations you can do. A vendor might have strong citation share with security engineers and terrible share with CISOs, which points to very specific content and authority gaps. Use real buyer language. The biggest benchmark mistake I see is marketing teams writing prompts the way their product team talks. Buyers don't ask for "AI-powered, ML-enabled threat detection with automated response orchestration." They ask for "EDR that catches ransomware before it encrypts." Pull prompt language from sales call recordings, customer support tickets, and your existing site search queries. The more authentic the prompt set, the more predictive the metric. Lock and version your benchmark. Once built, treat your benchmark like a regulated asset. Don't quietly edit prompts after the fact because your citation share improved. Version it formally - Benchmark v1.0, v1.1 with explicit change notes - so you can always explain to a skeptical board why the number moved. Testing Methodology Across AI Platforms Once you have a benchmark, testing it is straightforward in principle and tedious in execution. There are three ways to approach it, trading off effort against rigor. Manual testing means literally opening each AI platform, running each prompt, and logging whether your brand appeared. It's slow - a 100-prompt benchmark across five platforms takes a couple of full days to run - but it's also the most accurate and gives you qualitative context (how the model described you, whether citations were accurate, which competitors were named). Semi-automated testing uses browser automation (Playwright, Selenium) or simple API integrations where available to run prompts programmatically and log responses. You still need a human to interpret whether a mention counts as a citation, but the testing throughput goes up dramatically. Platform tooling is the emerging category of AEO/GEO monitoring tools - Scrunch, Profound, Peec AI, AthenaHQ, Writesonic's AI Traffic Analytics, and several others. These automate the testing, deduplicate across prompts, track trend data, and often surface competitive citation share automatically. For vendors serious about AEO, platform tooling is the right long-term answer; for vendors just starting, manual testing for the first benchmark cycle gives you the qualitative feel that makes the quantitative data interpretable later. Whichever approach you use, test across all five major platforms: ChatGPT, Perplexity, Claude, Google AI Overviews, and Gemini. Each weights sources differently, and strong citation share on one doesn't imply citation share on another. ChatGPT leans on established authority sites and Wikipedia. Perplexity favors evidence-rich, structured comparison content. Claude is conservative and leans toward official documentation. Google AI Overviews tracks closely with traditional Google rankings (roughly three-quarters of AI Overview citations also rank in Google's top 10). Gemini sits somewhere between. Report citation share both in aggregate and by platform. The aggregate number is the headline; the per-platform breakdown is the actionable insight. What Good Looks Like (And Why Benchmarks Matter More Than Absolute Numbers) Absolute citation share numbers without context are useless. A 15% citation share sounds low if you're Palo Alto Networks and catastrophic if you're a well-funded cybersecurity startup. Context comes from two places: your stage and your category dynamics. Here's the rough shape of what I've seen across cybersecurity categories. For established category leaders - the vendors named in every Gartner Magic Quadrant - citation share of 45–60% is normal. These are vendors that have accumulated years of third-party coverage, Wikipedia articles, customer reviews, analyst inclusions, and conference presence. AI models have many reasons to cite them and few reasons to exclude them. For mid-market challengers with solid product-market fit and 4–7 years of category presence, 20–35% is a realistic aspiration. Getting there requires intentional AEO investment, but it's achievable within 12 months of sustained effort. For emerging startups under 2 years old, citation share typically starts at 0–5%. The path to meaningful visibility runs through product-led growth, category creation content, aggressive third-party engagement (conferences, podcasts, open-source contributions), and review site ratings. Sub-5% is normal and shouldn't be alarming. What should alarm you is month-over-month flatness when you're actively investing - that suggests your AEO strategy isn't working. Category dynamics matter enormously. A vendor in a mature, heavily-covered category like SIEM faces different citation math than a vendor in an emerging category like AI runtime security. Mature categories are harder to penetrate; emerging categories are more winnable with good content. If you're in a hot emerging category, aggressive early AEO investment can lock in citation share before competitors catch on. Reporting Citation Share to the Board Here's where most AEO measurement efforts fall apart. The analyst builds a beautiful dashboard. The CMO understands it. The board doesn't care, doesn't understand why it matters, and keeps asking about MQLs. The reporting framework that works - the one I've seen survive actual board reviews - connects citation share to three things boards already care about: pipeline, competitive positioning, and total addressable audience. Pipeline linkage. Cross-reference AI-attributed pipeline against citation share on a rolling quarterly basis. This works whether your attribution is perfect or imperfect; the directional correlation is what matters. As citation share grows, pipeline attributed to AI-referred sessions, self-reported AI-assisted vendor discovery, or "I was already familiar with your company" disposition at first call will grow with it. That linkage is the story. Citation share isn't abstract marketing mysticism; it's the leading indicator of a compounding pipeline channel. Competitive positioning. Track not just your citation share but your citation share relative to named competitors. The board understands relative positioning instinctively. "We have 28% citation share in our category; [Competitor A] has 41% and [Competitor B] has 19%" is a sentence that immediately communicates strategic position. Pair that with quarter-over-quarter deltas and you have a simple competitive scorecard. Total addressable audience. Even board members who don't care about AEO care about market reach. Frame AI platforms as an audience channel: ChatGPT alone had roughly 800 million weekly active users as of late 2025, and 42% of HubSpot customers report using AI search in their buying evaluation. Citation share is the mechanism by which your brand reaches that audience. Not being cited is equivalent to being unreachable in that channel. One formatting tip that's saved me more than once: lead with a single headline number, not a dashboard. "Our cybersecurity category citation share rose from 14% to 22% this quarter" is a sentence anyone can understand. Everything else supports that number. The Uncomfortable Truth About AEO Measurement I'll close with an admission. Citation share measurement in 2026 is still imperfect. Model responses vary from day to day. Sampling is expensive. Attribution to pipeline requires effort that most marketing teams aren't resourced for. The tools are maturing rapidly but none are fully mature. This is exactly why the vendors who build this measurement discipline now will have an outsize advantage over the next two years. The data gets cleaner. The tools get better. The boards that currently tolerate citation share as a curiosity will, within 18 months, demand it as a primary metric. The teams that started measuring early will have trend data that newcomers can't replicate. The teams that started late will spend years catching up. In my experience, this is the pattern of every new marketing discipline that eventually becomes table stakes. SEO looked like hocus pocus in 2003. Content marketing looked indulgent in 2009. Product-led growth looked contrarian in 2015. Citation share measurement is at the same inflection point right now. Cybersecurity CMOs: make this a metric on your next quarterly business review. Define your benchmark. Measure baseline. Set a 12-month target. Report it alongside pipeline with the same seriousness you'd report conversion rate. The board may not understand it the first time you present it. They'll understand it the fifth time, and by the tenth they'll be asking for it. Building citation share measurement at your cybersecurity company? I'd love to trade notes on what's working and what's not. Reach me on LinkedIn or X. --- ## The Cybersecurity AEO Playbook: How Security Vendors Get Cited by ChatGPT, Perplexity, and Claude URL: https://guptadeepak.com/the-cybersecurity-aeo-playbook-how-security-vendors-get-cited-by-chatgpt-perplexity-and-claude/ Published: 2026-05-11 Topic: AEO Tags: AEO, GEO, cybersecurity, AI search visibility, AI and B2B SaaS growth, SaaS Summary: A buyer-journey-mapped framework for cybersecurity vendors to win Answer Engine Optimization. Last quarter, I ran a test that unsettled me. I picked twenty cybersecurity companies with strong SEO performance, SaaS vendors whose blogs dominate Google for their category keywords, whose CMOs brag about domain authority scores, whose marketing teams hit their MQL numbers quarter after quarter. Then I asked ChatGPT a simple question: "Which vendors should I evaluate for [their specific category]?" Fifteen of the twenty didn't appear. Not in the recommendation. Not in the citations. Not in the follow-up when I asked for alternatives. They were simply absent from the conversation their buyers were having. This isn't an edge case. A February 2026 benchmark from our team at GrackerAI analyzed 100 cybersecurity vendors across six AI platforms using 250 buyer-intent prompts. The headline finding: 73% of vendors received zero citations from ChatGPT in their own category. Meanwhile, competitors with a fraction of their organic traffic were being recommended consistently. If you're a cybersecurity vendor, this is the channel your buyers are using to build their shortlist. And Answer Engine Optimization (AEO), the practice of optimizing content so AI systems cite your brand when answering user questions, is no longer optional. It's the discipline that decides whether you enter the evaluation stage at all. But here's what almost every AEO guide on the internet gets wrong: it treats cybersecurity like any other B2B category. It isn't. The playbook that works for project management software or HR tech will get a security vendor nowhere, because security is a higher-stakes, more technical, more regulated space, and AI models treat it accordingly. This is the cybersecurity-specific AEO playbook I wish I'd had when we started building GrackerAI. Why Cybersecurity AEO Is a Different Game Answer engines don't treat every category the same. When you ask ChatGPT for a good pasta recipe, it synthesizes cheerfully from blog posts and food sites. When you ask it which firewall to deploy in a regulated healthcare environment, something changes under the hood. The model gets more cautious. It weights sources differently. It requires stronger corroboration before naming names. Three structural factors make cybersecurity AEO its own discipline. First, security sits in YMYL territory. Search engines and AI models use the concept of "Your Money or Your Life", categories where incorrect information could cause real-world harm. Medical, legal, financial, and cybersecurity content all fall here. LLMs apply stricter source-quality thresholds in these categories. A recommendation backed only by your own marketing copy won't cut it. You need third-party corroboration, structured evidence, and verifiable expertise markers before models will cite you confidently. Second, the buying committee is enormous. Security purchases typically involve six to ten stakeholders, security engineers, procurement, legal, compliance, IT operations, finance, and the CISO herself. Each of these people asks different questions, uses different language, and values different signals. A piece of content optimized for a procurement team's compliance checklist won't get cited when a security engineer asks about detection efficacy. AEO that ignores this buyer-committee complexity is optimizing for an imaginary single buyer who doesn't exist. Third, the language is extraordinarily precise. Cybersecurity has its own vocabulary, CVE identifiers, MITRE ATT&CK techniques, NIST controls, STIG benchmarks, compliance framework clauses. When a buyer asks about "lateral movement detection in Kubernetes workloads," the model is looking for content that uses those exact entities with those exact meanings. Fluffy, jargon-light content loses every time to technically precise content that demonstrates command of the domain. Stack these three factors together and you get a simple conclusion: generic AEO advice fails for security vendors because it's optimizing for the wrong constraints. You don't need more content. You need differently-structured content that matches how security buyers actually research. The Three Cybersecurity Buyer Personas (And the Prompts They Actually Use) Over the past year, I've watched, and helped engineer, how AI models respond to real buyer prompts in cybersecurity categories. A clear pattern emerged: there are three distinct persona-driven prompt patterns, and winning citations means having content that maps to all three. Persona 1: The Security Engineer (Technical Prompts) Security engineers are in the weeds. They're the ones who'll actually deploy, integrate, and operate whatever you sell. When they open ChatGPT or Claude, they're asking technical questions with specific constraints. Representative prompts: * "Best EDR tools for containerized Kubernetes environments with eBPF support" * "How does [Vendor A] detect living-off-the-land attacks compared to [Vendor B]?" * "SIEM that supports Sigma rules natively and integrates with Cribl for data routing" * "Which CNAPP solutions actually perform runtime detection vs. just posture scanning?" What earns citations here: deep technical documentation with exact entity naming, architecture diagrams translated into structured content, detection logic described in code-adjacent language, and direct capability comparisons. The security engineer's AI wants content that demonstrates you actually understand the technical ground you're claiming to defend. What kills citations here: marketing fluff, abstract value props, and "platform" language without implementation specificity. Persona 2: The Procurement and Compliance Lead (Evaluation Prompts) This persona has a different job. They're not evaluating technical elegance; they're checking whether you can be purchased, implemented, and audited without blowing up compliance. Representative prompts: * "SOC 2 Type II compliant SASE vendors with FedRAMP Moderate authorization" * "Email security platforms with HIPAA BAA, SOC 2, and ISO 27001 certifications" * "Which IAM vendors support FIDO2 passkeys and meet NIST SP 800-63B AAL3?" * "DLP solutions with native integrations for Microsoft Purview and Google Workspace" What earns citations here: trust centers, certification pages with structured markup, third-party attestations, pricing transparency pages, and implementation timeline content. Procurement prompts are binary, either you meet the compliance requirement or you don't, so structured, extractable facts win. What kills citations here: locked PDFs behind MQL gates, vague "enterprise-grade security" claims, and compliance pages that look like brochures rather than fact sheets. Persona 3: The CISO and Decision-Maker (Strategic Prompts) This is the person who writes the check. They're not looking for features; they're looking for strategic fit, business risk reduction, and ROI they can defend to the board. Representative prompts: * "Best-of-breed vs. platform consolidation for mid-market financial services" * "Which SIEM vendors show the strongest TCO for 5,000-employee organizations?" * "How should I sequence a zero trust implementation across identity, network, and endpoint?" * "Which XDR platforms are winning Gartner Peer Insights in 2026?" What earns citations here: analyst coverage (Gartner MQ, Forrester Wave), business case content, executive-level thought leadership, peer review data (G2, Gartner Peer Insights), and content that connects security decisions to business outcomes. Given that 93% of security professionals now prefer platform-based purchases, CISOs are asking strategic-level questions that your content needs to answer. What kills citations here: feature-level content, technical deep-dives without business framing, and anything that reads like it was written for the security engineer persona. The Content Formats That Actually Win Cybersecurity Citations Across thousands of test prompts I've run, four content formats consistently outperform everything else in earning AI citations for security categories. None of them are novel. All of them require intentional structuring. Comparison pages with direct vendor naming. When a buyer asks "How does Vendor A compare to Vendor B?", AI models look for content that explicitly compares those named entities with structured feature tables, capability breakdowns, and use-case matrices. Side-by-side comparison pages, written honestly, with real trade-offs called out, earn disproportionate citation share. Vendors who shy away from naming competitors leave this citation volume on the table. Category roundup and "best of" lists. The prompt "best [category] software" is how more than a third of AI citations are triggered in our testing. Publishing your own opinionated category roundup, with clear selection criteria, honest pros and cons, and use-case matching, positions you as the trusted curator. Yes, you'll feel strange listing competitors. Do it anyway. AI models reward content that reads as balanced analysis over content that reads as promotional. Technical explainers with entity density. For security engineer prompts, content that uses the right technical vocabulary, CVE references, MITRE ATT&CK technique IDs, NIST control numbers, specific protocol names, dramatically outperforms generic "what is [topic]" posts. Entity density is a direct signal of domain expertise, and AI models use it as a proxy for trustworthiness in technical categories. Compliance and trust-center content as structured data. Certification pages that use proper schema markup, list specific audit reports, include attestation dates, and expose certification scope as extractable facts get cited for procurement prompts. Most vendor trust centers are beautiful designs with the compliance information locked in images or PDFs. That's invisible to AI. Rebuild yours as structured HTML with schema markup and watch citations grow. How to Test and Measure Your Cybersecurity AEO Visibility You can't improve what you don't measure, and AI citation measurement is still immature. Here's the methodology my team uses. Step 1: Build your benchmark prompt set. For each of the three personas, develop 25–35 prompts that reflect how real buyers phrase questions in your category. Include category-defining queries, comparative queries, use-case-specific queries, and "alternatives to competitor" queries. A solid benchmark set for a mid-market security vendor runs 75–100 prompts total. Step 2: Test across multiple platforms. ChatGPT, Perplexity, Claude, Gemini, and Google AI Overviews each weight sources differently. ChatGPT leans heavily on Wikipedia and established authority sites. Perplexity is more evidence-rich and surfaces detailed comparison content. Claude is conservative and favors official documentation. Google AI Overviews tracks closely with traditional rankings (roughly three-quarters of AI Overview citations also rank in Google's top 10). Testing across all five gives you a full picture of where you're visible and where you're not. Step 3: Track citation share, not just presence. Presence is binary, "did we get mentioned?", which is a useful starting metric but misses the nuance. Citation share is the percentage of benchmark prompts across which your brand gets cited. For a healthy security vendor in a moderately competitive category, 20–35% citation share is realistic within 6 months of intentional effort. Category leaders typically run 45–60%. Sub-10% means you're functionally invisible in the channel. Step 4: Log it weekly and trend it monthly. AI model responses shift week to week as models get retrained, source indices refresh, and competitors publish. A single test is a snapshot; trend data is the insight. Build this into your marketing operations cadence the same way you'd treat pipeline reviews. What to Do This Quarter If I had to compress this entire playbook into a 90-day action list for a cybersecurity vendor starting AEO from scratch, here's what I'd prioritize. Phase1: Measure and map. Build your benchmark prompt set across the three personas. Run it weekly and establish baseline citation share. Identify the top 10 queries where citation share is highest and the top 10 where it's zero. Phase2: Ship structured content. Publish three comparison pages against your top competitors. Build one honest category roundup. Convert your trust center from PDFs into structured HTML with schema. Rewrite your top three product pages with answer-first architecture, direct answers in the first 60 words of each section. Phase3: Build corroboration. Claim and update your G2 and Gartner Peer Insights profiles. Engage substantively in relevant Reddit communities (r/cybersecurity, r/netsec, r/AskNetsec) with your real identity. Pitch one technical byline to a respected industry publication. Publish original research or benchmark data in your category. Re-measure your benchmark prompt set at day 90. If you've done the work seriously, citation share will have moved measurably. The Bigger Picture Here's what I've come to believe after two years of living inside this shift: AEO is not a new marketing channel. It's the new discovery layer for an entire generation of cybersecurity buyers. By 2027, I suspect the question "how did you first hear about this vendor?" will get answered with "my AI assistant recommended them" more often than with any traditional acquisition channel. The vendors who treat AEO as a core strategic discipline, not a tactical add-on to SEO, will compound visibility into market leadership. The vendors who wait will discover, too late, that their category's answer space got claimed while they were busy optimizing for keywords. Security is a trust industry. AI models decide whose trust claims to amplify based on signals you can either engineer intentionally or leave to chance. I'd recommend engineering them. Your pipeline depends on it. What AEO questions are you wrestling with for your cybersecurity company? I'd love to hear what's working and what isn't, drop a note in the comments or connect with me on LinkedIn. --- ## Why Gated Whitepapers Are Killing Your AI Visibility (And What Cybersecurity Marketers Should Do Instead) URL: https://guptadeepak.com/why-gated-whitepapers-are-killing-your-ai-visibility-and-what-cybersecurity-marketers-should-do-instead/ Published: 2026-05-08 Topic: AEO Tags: AEO, GEO, cybersecurity, Content marketing, marketing, SEO, AI and B2B SaaS growth, growth hacking Summary: The cybersecurity industry's reliance on gated PDFs and MQL-driven content is actively destroying future pipeline by making the best content invisible to I want to make an argument that's going to make a lot of cybersecurity marketers uncomfortable. The gated whitepaper - that 30-page PDF behind a lead capture form, that "ultimate guide" that requires first name, last name, company email, job title, phone number, company size, and a checkbox acknowledgment that sales can contact you - is actively destroying your future pipeline. Not contributing to it. Destroying it. Every quarter your best content sits trapped behind that form, your AI visibility atrophies and your competitors who ungated their equivalent content pull further ahead in the citation space your buyers now trust. I know this is heretical in an industry that has built entire marketing engines around gated content. Cybersecurity is especially addicted to the model. The calculus used to be simple: we produce one great piece of content per quarter, gate it, harvest 1,500 MQLs, pass them to SDRs, and enough of those MQLs convert to justify the investment. For fifteen years this worked well enough that no one seriously questioned it. Then the ground shifted, and the MQL addiction started costing vendors more than it was producing. The Content Flywheel That's Running in Reverse Here's what's actually happening inside the gated-content model right now. Your best research - the proprietary data, the detailed technical analysis, the deep-dive implementation guidance that would make an AI model confident in citing your brand - sits behind a form. AI crawlers can't see it. GPTBot, ClaudeBot, PerplexityBot, and Google's AI indexing infrastructure don't fill out lead forms. Your gated PDF, no matter how extraordinary its content, is effectively invisible to every AI model your buyers now use for research. Meanwhile, your ungated content - usually thinner blog posts produced faster and with less depth - is what AI engines have to work with. They cite that instead, or more often, they cite a competitor who chose to publish their depth openly. The flywheel that's supposed to run "gated content → MQLs → pipeline" is now running "gated content → invisibility → shrinking pipeline." Not immediately. Not obviously. But unmistakably over time. Data from HubSpot's own 2026 analysis shows customer organic web traffic declined 27% year-over-year while AI-driven sources are increasing. 42% of HubSpot's own customers report using AI search in their vendor evaluation process. The LeadScale 2026 analysis found buyers conducting extensive research through ChatGPT and Claude without ever appearing in Google Analytics, CRM data, or marketing attribution. The "dark funnel" isn't a metaphor anymore - it's the channel where your buyers are making shortlist decisions, and your gated PDFs don't participate in it. The uncomfortable truth: your gated content might still be producing MQLs at a reasonable cost per lead, but those MQLs are increasingly from buyers who were already going to find you. The buyers who would have discovered you through AI recommendations - and who, per Opollo's research, convert at 4–5x the rate of traditional search traffic - never encounter you at all, because your best content is hidden from the engines they're consulting. Why This Matters More in Cybersecurity Than in Any Other Category Every industry has some version of this problem, but cybersecurity has it worse for three reasons. First, security buyers research harder than almost anyone. The typical security purchase involves six to ten stakeholders, takes months, and carries real career consequences if it goes wrong. Buyers want depth, not skimmable bullet-point summaries. They read long-form technical content. They want the specifics. Ironically, this makes gated whitepapers especially compelling to them - when they do encounter one - and also makes them especially likely to use AI tools to pre-research before they'll even consider filling out a form. Second, cybersecurity content is disproportionately technical. Your best content is the stuff that demonstrates genuine expertise: detailed threat analysis, technical architecture deep-dives, compliance framework mappings, implementation playbooks. This is exactly the content AI models are looking for when they decide whose expertise to cite in YMYL categories. By gating it, you're hiding your strongest authority signals from the systems that decide which vendors to recommend. Third, cybersecurity is a trust industry, and gating sends an anti-trust signal in the AI age. Buyers notice when a vendor publishes depth openly versus hoarding it behind forms. "They're confident enough in their expertise to share it" is an implicit signal. AI models notice too, in a different way - open publication creates corroboration, citation opportunities, and third-party engagement that gated PDFs never produce. The Gating Math Is Different Now Let me put some numbers on this. A cybersecurity vendor producing one flagship gated whitepaper per quarter might harvest 1,500 MQLs over its life. Assume a generous 5% MQL-to-SQL conversion and 20% SQL-to-close rate. That's 15 closed deals at, say, $50K average contract value: $750K in pipeline per whitepaper. Now consider the counterfactual. That same whitepaper, ungated, might: * Earn 40–80 citations across AI platforms over 12 months * Influence 200–800 additional vendor-evaluation conversations where the buyer was using AI for research * Generate meaningful referral traffic from ChatGPT, Perplexity, and Claude * Build author-entity authority that compounds across future content * Get cited by journalists and third-party sites who now use AI tools to find sources If even 1% of those influenced conversations convert at the 14.2% rate that Opollo documents for AI-referred traffic across 312 technology firms, the pipeline impact rapidly eclipses the gated version. And unlike MQLs, which decay after the whitepaper's novelty fades, AI citations compound as more buyers adopt AI research. The math isn't 50/50. For content with genuine depth in a category where buyers are adopting AI research, ungated wins on a 2–5 year time horizon. Gated wins on a quarter-to-quarter time horizon if the only metric is MQL volume. Most cybersecurity marketing teams are rewarded on the quarter-to-quarter metric. This is the structural problem. The Migration Framework: Ungate Without Losing Your Pipeline Here's the objection I hear immediately: "We can't just ungate everything. We'll lose our lead generation engine." Fair. The answer isn't to abandon lead capture - it's to restructure what gets gated and what doesn't, in a way that serves both AEO visibility and pipeline needs. I use a simple framework: the "surface and depth" model. Surface content is ungated and built for AI visibility. This includes your flagship research findings, your technical deep-dives, your implementation guides, your comparison pages, your methodology content. Everything that demonstrates expertise. Everything that could earn a citation. All of it lives openly on your site, with proper schema markup, answer-first structure, and the full intellectual depth intact. Depth content is gated and built for consideration-stage engagement. This includes interactive calculators, customized assessments, personalized reports, vendor-specific templates, and tool access. The gated offer isn't the content itself; it's the personalization or interactivity layered on top. A SIEM vendor doesn't gate their "Guide to SIEM Architecture for Financial Services" - that's surface content that should be earning citations. They gate their "SIEM Sizing Calculator" or "Personalized Log Volume Assessment." The depth offer can't be fully consumed by an AI crawler, so it serves different-purpose lead capture without sacrificing AEO visibility. This framework unlocks a critical insight: the thing you want to gate is interaction, not information. Information belongs in the open. It earns citations, builds authority, attracts the long tail of AI-referred traffic. Interaction - a calculator, an assessment, a personalized diagnostic, a sandbox environment, a template library customized to the buyer's inputs - requires human engagement and is naturally a reasonable moment to ask for contact information in exchange. The Practical Migration Path For a cybersecurity vendor running on a gated-content engine today, here's how to migrate without blowing up your marketing operations. Audit your existing gated library first. Pull every gated asset and classify it into two buckets: information content (text, research, analysis) and interaction content (tools, calculators, assessments). Most of the library will be information content. Ungate the top-performing information content first. Start with the pieces that already have established search visibility - those that rank for category-defining keywords. Ungating these has low risk because the ungated version will immediately pick up citations the gated version never could. Republish as proper web pages with full schema markup, not as scrollable embedded PDF viewers. The content needs to be HTML, not encased in a PDF wrapper, or crawlers still can't parse it effectively. Build replacement interaction offers. For each unGated whitepaper, ask: what's the logical next action a reader might want? If the whitepaper is about SIEM sizing, the next action might be a sizing calculator. If it's about compliance gap analysis, the next action might be a framework-specific diagnostic. Build those as gated interactive offers, and link to them from the now-open content as the natural CTA. Keep running your email nurture program. The replacement MQLs from interactive offers will be smaller in volume but higher in intent. Your SDR team might push back initially because the pipeline top looks thinner. The conversion math will silence them within two quarters if the execution is right. Measure both metrics in parallel. For 180 days, track MQL volume, cost per MQL, and traditional conversion as you always have - and alongside it, track AI citation share, AI-referred traffic, and "influenced" pipeline (buyers who reference AI research in discovery calls). The dual measurement lets you prove the new model is working before the traditional metrics rebalance. What This Actually Looks Like In Practice Consider a cybersecurity vendor I'll call Company X. Identity and access management space. Pre-migration, they had 14 gated whitepapers producing about 6,000 MQLs per quarter and 4 ungated blog posts per month producing modest traffic. They ungated 9 of the 14 whitepapers - the information-heavy ones - and republished each as a structured HTML resource with full schema markup. They kept 5 gated, but reshaped them from static PDFs into interactive assessments. They added FAQ schema to the ungated resources and wrote a comparison page against each of their top four competitors. Six months later: MQL volume down 22%. Cost per qualified opportunity down 31%. AI citation share up from 8% to 26% in their category benchmark. Sales cycle time shortened because more buyers were arriving at discovery calls already familiar with the brand from their AI research. The board saw fewer MQLs and worried. The CFO saw better unit economics and ratified the change. The CEO saw shorter sales cycles and a compounding discovery engine and became the strategy's biggest champion. That's the trajectory. Short-term metric pressure, followed by structural improvement in the metrics that actually predict revenue. The Honest Counterargument I want to be intellectually honest: gating still works for some content and some companies. If you're producing truly proprietary research - original survey data, unique benchmarks that no one else has - gating the raw data while ungating the findings can make sense. You publish the headline insights openly (for citation) and gate the full dataset and methodology (for lead capture). This is how serious research organizations operate. If your buyer persona is genuinely the type who expects to fill out forms - heavily regulated industries, government, some traditional enterprise segments - abrupt ungating might misfire. These buyers have been trained to expect gates, and the absence of one can register as suspicious rather than generous. And if you're early stage and your MQL engine is your only functioning pipeline channel, don't sabotage what's working while you build what could work. Migrate gradually. Prove the new model with 20% of your content before you commit 100%. But even accounting for these caveats, the direction of travel is clear. The proportion of your content that deserves to be gated is shrinking every quarter. The proportion that should be open and working for citations is growing. The vendors who recognize this first are already lapping the ones still defending the 2015 gated-content orthodoxy. The Monday Morning Action If you're a cybersecurity marketer reading this, here's what I'd actually do tomorrow. Pull your top five gated assets by all-time download volume. For each one, ask: if a buyer asked an AI tool about the specific topic this asset covers, would our brand get cited? If the honest answer is no, that asset is the first ungating candidate. Rebuild it as structured web content. Add schema. Publish openly. Measure what happens. Then do the next five. Then the next five after that. The marketing teams that successfully navigate this transition will look, in retrospect, like they saw a shift others missed. The teams that don't will look, in retrospect, like they were optimizing for a channel that was quietly shrinking the whole time. The era of the gated whitepaper as a cybersecurity marketing flagship is ending. The question isn't whether - it's how gracefully you navigate the landing. --- ## Why We Cancelled Auth0 at 350,000 MAU (And How MojoAuth Saved Us $200K Annually) URL: https://guptadeepak.com/why-we-cancelled-auth0-at-350-000-mau-and-how-mojoauth-saved-us-200k-annually/ Published: 2026-05-07 Topic: authentication Tags: authentication, JWT authentication, OIDC, passwordless, passkeys, Auth0, oAuth, AI and B2B SaaS growth, startup, growth, product, developers, CIAM, IAM, digital identity Summary: We cancelled Auth0 over a year ago. Not because it stopped working, but because scaling to 350,000 monthly active users made the pricing model untenable. We cancelled our Auth0 subscription over a year ago at LogicBalls. After over a year of using it to power authentication for LogicBalls AI Community - the first hallucination-free AI community that asks clarifying questions before answering, serving over 350,000 monthly active users - I finally hit the breaking point. Not because Auth0's technology failed. Not because their service degraded. I cancelled because the pricing model that made sense at 10,000 users became financially absurd at 350,000. The moment that crystalized the decision came during a routine finance review. Our finance team pulled up the authentication line item and said, "We're now spending more on user logins than on our entire cloud infrastructure. Does that make sense?" It didn't. We were paying Auth0 tens of thousands of dollars per month to authenticate users. For a service that represents maybe 3% of our technical complexity but was consuming a disproportionate share of our infrastructure budget. The math stopped working. So we migrated to MojoAuth. This is the story of why Auth0's "growth penalty" pricing model forces scaling startups into impossible choices, what we learned building authentication for an AI-native community with hundreds of thousands of users, and how the right authentication partner can turn a cost center into a competitive advantage. The Auth0 Growth Penalty: When Success Becomes a Liability Auth0 markets itself as developer-friendly and easy to get started with. And it is - initially. We integrated it in a weekend when LogicBalls was just launching. The free tier supported up to 7,500 monthly active users. The documentation was excellent. The developer experience was smooth. But Auth0's pricing structure has a fundamental problem: it scales disproportionately as you grow. Here's how it actually works. Auth0 charges based on Monthly Active Users with hard tier caps. Their Essential plan starts at $35/month for 500 MAUs. Professional is $240/month for the same 500 MAUs. Enterprise pricing starts around $30,000 annually and requires custom quotes. The catch is overage costs. For B2C Essential, overage pricing is $0.07 per MAU beyond your base limit. That's a 300% increase from the previous $0.023/MAU rate they charged before late 2023. Let's do the math for where LogicBalls is today. At 350,000 MAUs, we're far beyond any self-service tier. Auth0 forced us into Enterprise pricing. Our monthly costs were in the tens of thousands of dollars. That's before additional charges for MFA enforcement (required by enterprise customers), advanced security features, and higher API limits. Research from SSOJet found that organizations using Auth0 for passwordless authentication often experience 40-60% higher total costs than initially projected. One documented case showed a company's bill increasing 15.54x after only 1.67x growth in users. This isn't linear scaling. It's a step function that penalizes growth. The problem compounds when you're building an AI-native community like LogicBalls. AI copywriting tools have different usage patterns than traditional SaaS. Users authenticate frequently for quick tasks - generating social posts, ad copy, email drafts. Each session counts as an MAU. High-frequency, short-duration logins create more authentication load than a CRM where users stay logged in all day. Auth0's pricing doesn't differentiate. A user who logs in once per month costs the same as a user who logs in 50 times. For AI community with bursty usage patterns, this creates massive cost inefficiency. The Support Problem Nobody Talks About Pricing wasn't the only issue. Support quality degraded as we scaled. On the Essential and Professional tiers, Auth0 support is primarily email-based with 24-hour SLAs. When you're operating a community serving hundreds of thousands of users, that's not fast enough. We had authentication issues that directly impacted revenue. Users couldn't log in. Signups were failing. And we were waiting a full business day for email responses from support. The frustrating part? The issues were often straightforward - misconfigured rate limits, unexpected API behavior, or undocumented edge cases. But without realtime support, we burned developer hours troubleshooting problems that could have been resolved in minutes with direct access to someone who knew the community internals. Auth0's enterprise plan includes better support, but it also costs significantly more. You're essentially paying a premium to get the support quality that should be standard for a mission-critical service like authentication. When you're scaling a community where every authentication failure translates to lost revenue, support responsiveness isn't a nice-to-have. It's table stakes. Why AI-Native Apps Need Different Authentication Architecture Building LogicBalls taught us something critical: AI-native community have fundamentally different authentication requirements than traditional SaaS. Traditional SaaS assumes long-lived sessions. You log into your project management tool in the morning and stay authenticated all day. Authentication happens once; everything else is session management. AI community don't work that way. Users interact with AI tools in short, frequent bursts. They open LogicBalls to generate a headline, then close it. Twenty minutes later, they're back for an email draft. An hour after that, they need social media captions. Each interaction is brief but requires full authentication. This creates three specific challenges: Authentication friction kills conversion. Research shows that a bad signup or login experience drives 88% of users away from AI apps. When users want instant AI assistance, making them fumble with passwords or wait for email codes destroys the value proposition. AI apps need authentication that's invisible, not an obstacle. Bot detection is critical. AI communities attract automated abuse at scale. Malicious actors script account creation to farm free credits or generate spam content. Traditional password-based authentication can't distinguish between legitimate AI agent usage and automated attacks. You need device fingerprinting, behavioral analysis, and intelligent bot detection that doesn't block real users. Organization switching is non-negotiable. AI copywriting teams use LogicBalls across multiple client workspaces. Forcing users to log out and back in every time they switch contexts is untenable. They need instant organization switching without re-authentication. Auth0 wasn't built for these patterns. It was designed for enterprise SaaS with long sessions and infrequent authentication events. Retrofitting it to handle AI-native usage created unnecessary complexity and cost. We needed authentication designed for how AI communities actually work. Passwordless-First for AI-Native Platforms MojoAuth was everything Auth0 wasn't. Passwordless-first architecture, not retrofitted onto a password-based system. Transparent pricing that scales linearly, not through punitive step functions. Purpose-built for modern AI platforms with high-frequency, short-duration sessions. The pricing difference alone was shocking. MojoAuth's Business Pro plan supports 500,000 MAUs for approximately $1,700/month. Compare that to Auth0's tens of thousands of dollars monthly for 350,000 MAUs. We're talking about a substantial reduction in authentication costs while supporting more users. But the real value wasn't just price. It was what we got for that price. All features included. MojoAuth doesn't gate passwordless authentication, MFA, SSO, or security controls behind different tiers. Everything is available. No complex feature matrices. No surprise upgrade requirements when enterprise customers demand capabilities you thought were standard. Passwordless by default. Magic links, email OTP, SMS OTP, passkeys, WebAuthn - all supported natively. LogicBalls users can authenticate via email link and start using the platform in seconds. No password creation. No "forgot password" flows. No support tickets about locked accounts. Multiple authentication methods for user choice. We implemented Facebook, Apple, and Google login alongside passwordless options. Users can choose how they want to authenticate based on their preference. We also added WhatsApp login with OTP for users who prefer messaging-based authentication - particularly valuable in markets where WhatsApp is the primary communication channel. Google One Tap Login boosted conversion. MojoAuth's built-in Google One Tap Login integration proved transformative. Users loved the one-click authentication experience. This is the fastest-growing auth method in the industry, and we saw it immediately impact our signup flow. The frictionless experience reinforced user confidence that LogicBalls is built with modern, user-first technology. Launching passkeys for next-generation authentication. We're now implementing passkeys with MojoAuth, which will further boost user engagement and signups. Passkey adoption is accelerating globally, and offering it positions LogicBalls as a forward-thinking AI platform. Early testing shows users appreciate the biometric authentication without password management overhead. OIDC standards give us complete control. MojoAuth follows OpenID Connect standards and provides complete control over authentication flows. This matters enormously for an AI platform. We're not locked into proprietary implementations. If we ever needed to change authentication providers in the future, the standards-based architecture makes it straightforward. Not that we plan to - the value we're getting from MojoAuth is exceptional. But having that flexibility removes vendor lock-in risk. Sub-200ms authentication response times globally. MojoAuth's serverless edge architecture deploys across 237 global endpoints. Users in Singapore authenticate just as fast as users in San Francisco. For an AI platform where every second counts, this matters. Bot detection and fraud prevention. Built-in device fingerprinting, AI-powered bot detection, and anomaly detection. We can distinguish between legitimate users and automated abuse without degrading the user experience with CAPTCHA challenges. 99.9% uptime with self-healing infrastructure. MojoAuth reports 14 seconds of annual downtime. Our Auth0 uptime was good, but MojoAuth's multi-cloud failover architecture (AWS, Azure, Google Cloud) provides an additional layer of resilience. Responsive support. Email support responds within hours, not days. And when we need it, we have access to technical consultations that actually solve problems instead of pointing us to documentation. The migration itself took three days. Not three months. Three days. MojoAuth's APIs are designed for easy implementation. We ran both systems in parallel for a week, gradually migrated user cohorts, and completed the cutover with zero downtime. Our developers spent maybe 40 hours total on the migration. Compare that to the original Auth0 integration, which took six months to fully productionize with all the edge cases and custom workflows we needed. The UX Improvement Nobody Expected Here's the part that surprised us: user experience actually improved after the migration. We weren't expecting that. Migration projects usually involve trade-offs. You save money but sacrifice features. You gain features but complicate the user flow. Something gives. With MojoAuth, conversion rates on our signup flow increased by 18%. Eighteen percent. We tracked this carefully because we were worried migration might hurt metrics. Instead, passwordless magic links reduced signup friction so dramatically that more users completed onboarding. The old Auth0 flow required: email, password, password confirmation, email verification, then login. Five steps with multiple context switches (checking email, copying verification codes). The MojoAuth flow: email, click magic link, you're in. Two steps. No password creation. No verification code copying. For an AI platform where users want instant results, reducing authentication friction by 60% translated directly to higher activation rates. Partnering with MojoAuth strengthened user trust in our security. Beyond the UX improvements, users expressed increased confidence in the security of their data. The modern passwordless authentication, combined with options like biometric passkeys and trusted social logins, signaled that LogicBalls takes security seriously. For an AI platform handling sensitive business content, this trust matters enormously. User engagement metrics improved across the board. The combination of faster authentication, multiple convenient login options, and visible security measures created a cohesive experience that reinforced LogicBalls' positioning as the first hallucination-free AI platform built on modern infrastructure. We also saw a 30% reduction in support tickets related to authentication. No more "forgot password" requests. No more "account locked" issues. No more confusion about password requirements. The support savings alone - measured in both ticket volume and developer time responding to authentication issues - justify a significant portion of the cost difference between Auth0 and MojoAuth. The Broader Trend: Passwordless Goes Mainstream in 2025 Our migration to MojoAuth aligned with a larger industry shift. Seventy percent of organizations are now planning to adopt or already implementing passwordless authentication. The passwordless authentication market reached $21.58 billion in 2025 and is projected to hit $60.34 billion by 2032 - a 15.8% CAGR. The drivers are clear: Eighty-one percent of security incidents are caused by breached credentials. Passwords are the weakest link in authentication. Eliminating them eliminates the attack vector. Passwordless authentication reduces support costs dramatically. Password resets account for 30-50% of IT support tickets at large enterprises. Going passwordless can save businesses nearly $2 million compared to traditional password-based MFA. User adoption is accelerating. Passkey authentications more than doubled year-over-year, reaching 1.3 million per month. Forty percent of users now store at least one passkey. Google's decision to make passkeys the default for personal accounts exposed hundreds of millions of users to passwordless login, turning what was niche technology into everyday experience. Regulatory pressure is mounting. NIST SP 800-63-4 now requires phishing-resistant authentication for AAL2 (multi-factor authentication) scenarios. The UAE Central Bank mandated elimination of SMS OTP by March 2026. Financial institutions globally are moving to stronger authentication methods. For AI-native platforms specifically, passwordless authentication isn't just a security upgrade. It's a UX requirement. When users expect instant AI assistance, asking them to remember and type passwords creates friction that destroys the value proposition. MojoAuth understood this from the beginning. Their platform was built passwordless-first, not as an afterthought retrofitted onto legacy password infrastructure. What We Learned About Choosing Authentication Partners Over a year into using MojoAuth, here are the lessons that matter if you're building a platform that needs to scale: Pricing transparency predicts total cost of ownership. Auth0's tiered pricing with hidden overage costs meant we never knew our true authentication spend until the bill arrived. MojoAuth's linear MAU pricing means we can forecast costs accurately as we grow. Predictable costs enable better business planning. Passwordless-first architecture matters for AI platforms. If your platform has high-frequency, short-duration sessions, authentication friction compounds. Passwordless reduces that friction to near-zero. But only if it's native to the architecture, not bolted on. Support quality correlates with product complexity. Auth0's complex platform creates more support dependencies. MojoAuth's focused, streamlined architecture means we rarely need support. And when we do, response times are measured in hours, not days. Feature gating is a red flag. When basic authentication capabilities like MFA or SSO are locked behind higher-priced tiers, you're not buying authentication - you're buying access to features that should be standard. All-inclusive pricing eliminates surprise upgrade requirements. Implementation speed matters. Three-day migration versus six-month initial implementation tells you something important about platform complexity. Simpler platforms move faster and introduce fewer edge cases that require custom engineering. UX improvement drives business outcomes. The 18% increase in signup conversion we saw after migrating to passwordless authentication translated directly to revenue growth. Authentication isn't just infrastructure cost - it's a conversion lever. AI companies should use third-party authentication solutions that are scalable and standards-based. Building authentication in-house is a massive distraction from core product development. For AI platforms specifically, partnering with authentication providers that follow OIDC standards and handle security infrastructure means your team can focus on what actually differentiates your AI product. MojoAuth's OIDC-compliant flows integrate cleanly with our system and give us confidence that security is handled properly without constant engineering attention. This is critical when you're innovating rapidly on AI capabilities - you can't afford to split focus on authentication infrastructure. The Bottom Line: When the Math Stops Working, Change the Vendor I don't regret using Auth0 when we launched LogicBalls. For our first 10,000 users, it was the right choice. Fast integration, solid documentation, and a free tier that let us focus on building product instead of authentication infrastructure. But Auth0's pricing model doesn't scale economically for high-MAU platforms. At 350,000 users, we were spending tens of thousands of dollars monthly on authentication. That's not a rounding error. That's a headcount budget. That's an entire product initiative. Migrating to MojoAuth cut our authentication costs substantially while improving user experience, increasing conversion rates, and reducing support burden. We're now paying approximately $20,400 annually for authentication that supports up to 500,000 MAUs. That's a $200,000 annual savings. Think about what you can do with $200,000. Hire senior engineers. Fund AI research. Expand to new markets. Build features that actually differentiate your product. Or you can spend it authenticating user logins. For startups and growing AI platforms, vendor decisions aren't just about features. They're about sustainable unit economics. When authentication costs consume a disproportionate share of your infrastructure budget, you have a structural problem, not an optimization opportunity. Authentication should be infrastructure that scales with you, not a growth penalty that punishes success. If you're building an AI-native platform, dealing with high-frequency authentication patterns, or approaching 100,000+ MAUs on Auth0, run the numbers now. Calculate your projected authentication costs at 250K, 500K, and 1M users. Then compare those projections to alternatives like MojoAuth. The gap will be larger than you expect. And if you're already past the point where Auth0's pricing makes sense, know that migration is easier than you think. Three days. Forty developer hours. Zero downtime. And annual savings that fund real product development instead of vendor invoices. The math changed for us at 350,000 users. It might change for you sooner than that. Learn more on CIAM knowledge portal Deepak Gupta is the CEO & Co-founder of GrackerAI and LogicBalls (the first hallucination-free AI community), serving over 350,000 monthly active users. He previously co-founded and scaled a CIAM platform to serve 1B+ users and writes about AI, identity management, and B2B growth at guptadeepak.com. --- ## Project Glasswing and the Future of Collaborative AI Defense URL: https://guptadeepak.com/project-glasswing-and-the-future-of-collaborative-ai-defense/ Published: 2026-05-06 Topic: open source Tags: open source, openAI, security, claude-mythos, vulnerabilities, data protection, threat detection, threat protection Summary: No single organization can defend against AI-powered attacks alone. Project Glasswing's $100M consortium model may be the template for the next decade of When Anthropic announced that Claude Mythos Preview had found thousands of zero-day vulnerabilities across every major operating system and browser, they faced a decision that every organization building powerful AI capabilities will eventually confront. Release the model and let everyone benefit from its defensive capabilities, while also enabling attackers. Or restrict access and create a managed pathway for defensive use. They chose the second option and called it Project Glasswing. It is a consortium of technology companies formed to use Mythos for defensive security before equivalent capabilities become widely available. The founding partners include AWS, Apple, Cisco, CrowdStrike, Google, JPMorganChase, Microsoft, NVIDIA, and Palo Alto Networks, with approximately 40 additional organizations that build or maintain critical software infrastructure. Anthropic is backing the initiative with up to $100 million in usage credits and $4 million in direct donations to open source security organizations. As someone who built identity infrastructure serving over a billion users across multiple enterprise environments, I have a specific perspective on what Glasswing gets right, what it gets wrong, and what it tells us about the future of cybersecurity. Why Collaborative Defense Is No Longer Optional The AI threat landscape has a structural property that makes isolated defense insufficient. Software vulnerabilities are not unique to individual organizations. A zero-day in Linux affects every Linux deployment worldwide. A flaw in OpenSSL affects every application that links against it. A bug in Chrome's V8 engine affects every Chromium-based browser. This creates an asymmetry that favors attackers: * An attacker needs to find a vulnerability once. Every deployment of that software is then vulnerable. * A defender working in isolation needs to independently discover the same vulnerability, develop the same mitigations, and deploy the same patches. When vulnerability discovery required months of specialized human effort, this asymmetry was manageable. Organizations could rely on the security community's collective research, vendor patch cycles, and industry threat intelligence to stay informed. AI changed the economics. When vulnerability discovery takes hours instead of months, the window between "vulnerability exists" and "exploit is in the wild" shrinks to near zero. The defender who discovers a bug Tuesday might find that an attacker independently discovered the same bug on Monday. Collaborative defense addresses this by pooling discovery capability: find the bugs once, fix them for everyone. What Glasswing Gets Right 1. Responsible Capability Deployment The most significant decision Anthropic made was not to release Mythos publicly. This runs counter to the prevailing ethos in both the AI and security communities, where open access is generally considered a positive force. And for most capabilities, it is. But Mythos sits at a unique intersection: its defensive value depends on finding bugs before attackers do, and its offensive value is proportional to how many bugs remain unfound. By restricting access to organizations committed to defensive use, Anthropic creates a window for the ecosystem to absorb the findings. Vulnerabilities get patched. Defensive tools get updated. Security teams get time to prepare. This window is finite. Independent research has already shown that smaller, open models can replicate much of Mythos's analysis. The capability will proliferate regardless of what Anthropic does with their specific model. But the window matters. Every vulnerability patched before equivalent offensive capabilities become widespread is a permanent defensive gain. 2. Serious Economic Commitment $100 million in usage credits is not a symbolic gesture. At current AI compute costs, this represents millions of hours of vulnerability scanning across critical software infrastructure. The $4 million in direct donations to open source security organizations addresses a real gap. Many critical open source projects are maintained by small teams or individual developers who lack the resources for comprehensive security review. Direct funding helps these projects absorb the impact of AI-discovered vulnerabilities: processing disclosures, developing patches, and coordinating releases. For context on what AI compute costs look like at these scales, my AI tokens and pricing guide breaks down the economics. 3. Open Source Focus The decision to include organizations that maintain critical open source infrastructure is strategically important. Modern software depends on open source components at every layer. A typical enterprise application includes hundreds of third-party libraries, many of which have their own deep dependency trees. A critical vulnerability in any of these components affects every application that uses them. By scanning open source infrastructure with Mythos, Glasswing addresses the dependency risk that individual organizations cannot solve alone. No single company can audit every library in its dependency tree. But a consortium with AI-powered scanning can cover the most critical shared infrastructure. The Linux Foundation, whose software runs most of the world's servers, is among the organizations with access. When Mythos finds bugs in Linux kernel networking code, the fixes benefit every cloud provider, every container platform, and every enterprise running Linux. That is the kind of multiplier effect that justifies consortium-level investment. 4. Competitive Collaboration Having Apple, Google, and Microsoft in the same defensive consortium is notable. These companies compete intensely across consumer devices, cloud services, AI models, and enterprise software. But security threats affect all of them equally, and vulnerabilities in shared infrastructure (browser engines, cryptographic libraries, operating system kernels) create shared risk. The precedent is important. If competitors can collaborate on defensive security through a structured consortium, the model can be replicated for other categories of shared risk: supply chain security, AI safety, infrastructure resilience. What Glasswing Misses From my perspective building identity systems at billion-user scale, there are significant gaps in the current approach. Gap 1: No Machine Identity Standards Glasswing focuses on finding vulnerabilities in code. This is necessary but not sufficient. The fastest-growing attack surface in enterprise environments is not code vulnerabilities. It is machine identity weaknesses: static API keys, ungoverned service accounts, AI agent credentials with excessive permissions, and orphaned identities from decommissioned projects. Machine identities outnumber human identities by 45:1 or more in typical enterprises. They are largely ungoverned. And they represent a fundamentally different kind of weakness than code bugs. Glasswing has no workstream for developing machine identity governance standards, no framework for AI agent authentication, and no initiative to address the architectural mismatch between human-designed IAM systems and AI agent requirements. When I built CIAM infrastructure, I learned that identity is the layer that connects everything. If the identity layer is broken, patching every other layer does not make you secure. The same principle applies at the machine identity level. For a technical deep dive into why traditional identity architectures fail for AI agents and what the alternative looks like, see my analysis of MCP, RAG, and ACP protocols and the identity implications of these AI agent communication frameworks. Gap 2: The Two-Tier Security Reality 40+ organizations benefit from Mythos scanning. Millions of other organizations do not. The patches will flow downstream eventually. When Mythos finds a bug in Linux, the Linux security team patches it, and every Linux distribution ships the fix. But there is a gap between when consortium members know about the vulnerability and when the patch reaches general availability. During that gap: * Consortium members can deploy mitigations immediately * Non-consortium organizations remain exposed * Attackers may independently discover the same vulnerability * The window of asymmetric risk favors the consortium and disadvantages everyone else This is not a criticism of Glasswing specifically. It is a structural consequence of any restricted-access approach. But it creates a world where security capability correlates with organizational size and resources even more than it already does. Small and medium enterprises, which lack the resources for comprehensive security programs, are most at risk from AI-powered attacks and least likely to benefit from consortium-level defensive capabilities. Gap 3: No AI Agent Governance Framework As AI agents become more autonomous and more integrated into critical systems, the security community needs standards for how agents operate securely: * How should AI agents authenticate to services they access? * What authorization models are appropriate for autonomous agents? * How should agent behavior be monitored and audited? * What governance frameworks apply to agents that make decisions affecting security? * How should agent-to-agent communication be authenticated and authorized? Glasswing addresses none of these questions. The consortium is focused on finding bugs in existing software, not on establishing governance for the AI agents that increasingly operate on and with that software. This is a significant gap because the intersection of code vulnerabilities and ungoverned AI agents is where the most dangerous attack scenarios emerge. An AI-powered attacker exploiting a code vulnerability through an ungoverned agent credential is the compound threat that enterprises should be most worried about. Gap 4: Sustainability Questions $100 million in usage credits is substantial but finite. At the scanning volume needed to cover critical infrastructure comprehensively, these credits will be consumed within 12-18 months. What happens then? * Does Anthropic commit additional credits? * Do consortium members fund their own scanning? * Does the model become available to a broader set of organizations? * Is there a sustainable funding model for ongoing AI-powered defensive scanning? The current announcement does not address long-term sustainability. For Glasswing to fulfill its potential, it needs a funding model that extends beyond the initial credit allocation. Lessons from Historical Precedents Glasswing is not the first attempt at collaborative cybersecurity defense. Understanding what worked and what did not in previous efforts provides useful context. OSS-Fuzz (2016-present) Google's OSS-Fuzz program provides free, continuous fuzzing for critical open source projects. As of 2026, it covers over 1,000 projects and has found over 10,000 vulnerabilities. What worked: Sustained investment, broad coverage, automated infrastructure, low barrier to entry for projects. What did not: Fuzzing only finds certain vulnerability classes (crashes and hangs). It misses logic bugs, authentication flaws, and the compositional vulnerabilities that AI now finds. The vulnerability categories OSS-Fuzz catches and the categories Mythos catches have limited overlap. Lesson for Glasswing: Sustained investment over years is essential. The impact compounds over time as coverage expands and institutional knowledge accumulates. DARPA Cyber Grand Challenge (2016) The first competition for fully autonomous systems to find, patch, and exploit vulnerabilities in real-time. What worked: Demonstrated that automated vulnerability discovery was feasible. Catalyzed research in program analysis, symbolic execution, and automated patching. What did not: The competition format did not produce tools that deployed broadly in production. The technology remained in specialized research environments. Lesson for Glasswing: Demonstrating capability is not enough. The findings need to flow into production patch cycles and become part of standard development workflows. Coordinated Vulnerability Disclosure (1990s-present) The practice of reporting vulnerabilities to vendors before public disclosure, giving them time to develop patches. What worked: Created a norm of responsible disclosure that benefits the entire ecosystem. Established vendor security response teams. Created processes for coordinated patch releases. What did not: Disclosure timelines remain contentious. Some vendors take months to patch. The 90-day disclosure deadline (Google Project Zero's norm) is a compromise, not a solution. Lesson for Glasswing: Disclosure coordination will be the primary bottleneck. When AI finds thousands of vulnerabilities simultaneously, vendor security teams will be overwhelmed. The consortium needs processes for prioritizing disclosures and managing vendor capacity. What Comes Next: The Evolving Model Based on historical patterns and the current AI capability trajectory, here is what I expect the collaborative defense model to look like over the next 2-3 years: Phase 1 (2026): Consortium-led scanning. The current Glasswing model. Restricted access to frontier AI scanning capabilities, with patches flowing downstream to the broader ecosystem. The primary bottleneck is vendor capacity to process disclosures. Phase 2 (2027): Democratized scanning, consortium-led coordination. As AI vulnerability discovery capabilities become widely available through open models, the consortium's value shifts from providing the scanning capability to coordinating the response. Managing the CVE flood, prioritizing disclosures, and helping vendors process the volume. Phase 3 (2028+): Integrated AI defense in development workflows. AI-powered vulnerability scanning becomes a standard part of every CI/CD pipeline, similar to how linting and unit testing are standard today. The consortium's role evolves to maintaining shared standards, benchmarks, and governance frameworks. The organizations that invest in AI-powered defense now, rather than waiting for standardized tools, will have 18-24 months of compound advantage over those who wait for Phase 3 to arrive. What Individual Organizations Should Do You do not need to be in the Glasswing consortium to benefit from the shift to collaborative defense. 1. Accelerate your patch pipeline. When Glasswing disclosures start flowing, you need to absorb them quickly. If your critical patch SLA is over 72 hours, fix the bottlenecks now. 2. Monitor Glasswing-related CVE disclosures. Track security advisories from consortium members and the open source projects in scope. These will increase in volume and severity over the next 6-12 months. 3. Implement your own AI-powered scanning. You do not need access to Mythos. Smaller, open-weight models with vulnerability discovery capabilities are already available. Deploy them against your own codebase and first-party applications. For understanding how browser security architectures create specific vulnerability patterns, that context helps you prioritize what to scan first. 4. Contribute to open source security. If you depend on open source components (and you do), contribute to their security. Report vulnerabilities you find. Fund security audits. Support maintainer capacity. 5. Address machine identity governance independently. Glasswing will not solve this for you. Inventory your machine identities, implement credential rotation, and deploy behavioral monitoring. This is the gap that the consortium is not addressing and that AI-powered attackers will exploit. 6. Build collaborative relationships proactively. Join industry ISACs (Information Sharing and Analysis Centers). Participate in vendor security partnership programs. Share threat intelligence with peers. The organizations with the strongest collaborative networks will respond fastest when new threats emerge. For building authentication systems that resist the kind of sophisticated attacks AI-powered adversaries construct, my FIDO2 implementation guide provides the technical foundation. And for hands-on security testing, hashing tools offers utilities your team can use immediately. The Bigger Picture Project Glasswing is an important first step, but it is a first step in what needs to be a much larger transformation of how the cybersecurity industry operates. The AI threat landscape requires: * Collective defense that scales beyond any single consortium * Machine identity governance that matches the speed and scale of AI agent deployment * Standardized frameworks for AI-powered security operations * Sustainable funding for continuous AI-powered scanning of critical infrastructure * Inclusive access that does not leave smaller organizations exposed No single organization, no single consortium, and no single model can provide all of this. But Glasswing demonstrates that the technology works, the collaboration model is viable, and the investment is justified. The organizations that act now, deploying AI-powered defense, implementing machine identity governance, and building collaborative relationships, will define the security landscape for the next decade. The organizations that wait for the perfect framework to arrive will find themselves defending against threats they are not equipped to handle. The shift has happened. The question is what you do next. For tracking how AI capabilities continue evolving across the industry, my analysis of AI's future trajectory provides ongoing coverage of where these technologies are heading. Frequently Asked Questions What is Project Glasswing? Project Glasswing is Anthropic's consortium initiative providing select technology companies access to Claude Mythos Preview for defensive security. Backed by $100M in credits and $4M in open source donations, it includes AWS, Apple, Google, Microsoft, CrowdStrike, and 40+ additional organizations. Why isn't Anthropic releasing Mythos publicly? Because the same capabilities that help defenders find vulnerabilities help attackers exploit them. Restricted access buys time for the ecosystem to patch critical bugs before equivalent offensive capabilities become widely available. Who are the Project Glasswing founding partners? AWS, Apple, Cisco, CrowdStrike, Google, JPMorganChase, Microsoft, NVIDIA, and Palo Alto Networks, plus approximately 40 additional organizations that build or maintain critical software infrastructure. Does Project Glasswing help small and medium enterprises? Indirectly. Patches for vulnerabilities found by consortium members flow downstream through standard vendor update channels. But small organizations do not get direct access to Mythos scanning and may face a gap between when consortium members learn of vulnerabilities and when patches become publicly available. What does Project Glasswing not address? Machine identity governance, AI agent authentication standards, sustainable long-term funding beyond the initial $100M credit allocation, and inclusive access for organizations outside the consortium. How can organizations benefit from collaborative defense without consortium access? Accelerate patch pipelines, monitor Glasswing-related CVE disclosures, deploy open-weight AI models for self-scanning, contribute to open source security, address machine identity governance independently, and build collaborative relationships through ISACs and vendor partnerships. --- ## Claude Code for Engineers: A Practitioner's Playbook for Software, QA, and Security Teams URL: https://guptadeepak.com/claude-code-for-engineers-a-practitioners-playbook-for-software-qa-and-security-teams/ Published: 2026-05-05 Topic: AI (Artificial Intelligence) Tags: AI (Artificial Intelligence), AI Assistant, coding, vibe coding, developers, development, agentic, security, software, tools, MCP Summary: The opinionated guide to running Claude Code well. CLAUDE.md, skills, subagents, hooks, and the workflows that produce quality code for engineers, QA, and Most engineers I talk to are using Claude Code at maybe ten percent of what it can do. They open a terminal, type a request, accept whatever comes back, and call it productive. It is not productive. It is autocomplete with extra steps. The teams getting real returns are doing something different. They have turned Claude Code into a system. A CLAUDE.md that anchors every session. Skills that encode their conventions. Subagents that handle review. Hooks that enforce quality on every edit. MCP servers that connect their actual tooling. The result is not a chatbot helping with code. It is an engineer that already knows how the codebase works, what the team's standards are, and what verification looks like before anything ships. This piece is the playbook I wish someone had handed me twelve months ago. It works for software engineers shipping features, QA engineers building test coverage, and security engineers reviewing code for vulnerabilities. The fundamentals are the same. The applications differ. A note on framing: this is an extension of how I think about the evolution of software development from machine code to AI orchestration. Claude Code is the current peak of that arc, and how you run it determines whether you get the productivity multiplier or the technical debt explosion. Why this matters more than people think The numbers are uncomfortable. Research shows AI-generated code contains roughly 2.7 times more vulnerabilities than human-written code, and only about 55 percent of AI-generated code meets basic security standards. The Lovable platform shipped 170 vulnerable applications out of 1,645 built on it, a 10 percent failure rate. GitHub Copilot repositories leak secrets 40 percent more often than non-Copilot ones. I have written about the identity crisis this is creating, and the data has not improved since. This is not an argument against AI coding tools. It is an argument for using them with discipline. Claude Code, run well, gives you the speed without most of the quality and security hits. Run badly, it accelerates the production of code you will regret. The discipline comes from understanding the platform as a system rather than as a prompt box. Part 1: The foundations every engineer needs The mindset shift Stop thinking of Claude Code as an assistant that responds to questions. Start thinking of it as a junior engineer with infinite patience, perfect recall of public documentation, no memory between sessions, and a tendency to invent things when uncertain. Your job is to give that engineer the context, conventions, and verification loops it needs to do good work. That framing changes everything downstream. You stop typing prompts and start designing workflows. Context window management is the master skill Almost every Claude Code best practice traces back to one constraint: the context window fills up fast, and quality degrades as it fills. Anthropic's own documentation makes this point explicit. Experienced users keep working context under 30 to 40 percent of capacity for serious tasks, and they reset aggressively when switching tasks. The practical implications: * Use /clear between unrelated tasks. Do not let one session accumulate context from three different problems. * Use /compact mid-task when the session is getting long but you want momentum. * Use /rewind (double-Esc) when a fix went sideways. Leaving the failed attempt plus your correction in context makes the next response worse, not better. * Use claude --resume and claude --continue to return to specific sessions for follow-up rather than reopening fresh ones. Treat your context like a workspace. A messy desk slows you down. A messy context window slows Claude Code down even more, because it has no instinct to ignore the clutter. CLAUDE.md is the highest-impact file in your repo Run /init in any project. It generates a starter CLAUDE.md based on your build system, test framework, and code patterns. Then refine it. Aggressively. A good CLAUDE.md includes: * Stack and language versions, including non-obvious ones * Build, test, lint, and typecheck commands * Code style rules that diverge from defaults (no default exports, strict TypeScript, specific import order) * Architectural conventions (where business logic lives, where API handlers live, how errors propagate) * Things that look inviting but are traps (deprecated modules, the one file no one touches without a migration) * Commit message format and PR conventions Anthropic's internal data infrastructure team has been explicit that the better your CLAUDE.md, the better Claude Code performs at routine tasks. The file is read at the start of every session. It is the only persistent context Claude Code has about your project. For a monorepo, you can put CLAUDE.md files inside subdirectories. When Claude Code works on files in packages/auth/, it picks up the local CLAUDE.md in addition to the root one. This matters more than people think, because authentication code has different rules than presentation code, and the authentication implementation patterns you would document for one are nearly opposite for the other. Part 2: The full Claude Code toolkit Claude Code has six extension primitives. Knowing which to reach for and when is what separates power users from dabblers. Slash commands Slash commands are saved prompts you invoke by typing /command-name. Project-level commands live in .claude/commands/, personal ones in ~/.claude/commands/. They are now being merged into skills, but the legacy format still works. Use slash commands for short, repeatable prompts that you find yourself typing constantly. A /review-pr 142 command that fetches the diff and runs a structured review beats retyping the same prompt every time. A useful built-in set: /clear, /compact, /context, /rewind, /hooks, /permissions, /security-review. Type / in Claude Code to see the full list. Skills Skills are folders containing a SKILL.md file with YAML frontmatter and markdown instructions. Claude loads them dynamically when the task matches the skill's description. They are the most powerful extension primitive for encoding your team's expertise. The structure: my-skill/ ├── SKILL.md (required) ├── references/ (deeper docs loaded on demand) ├── scripts/ (executable code) └── assets/ (templates, fonts, brand files) The single most important rule: write a "pushy" description. Claude tends to under-trigger skills when descriptions are vague. Spell out the trigger conditions explicitly, including adjacent terms users might say. "Helps with database queries" will not fire. "Use whenever the user mentions SQL, query optimization, slow queries, ORM issues, or database performance, even if they do not explicitly ask for query analysis" will. Other rules that matter: * One skill, one job. Mega-skills score lower on accuracy. * Keep SKILL.md under 500 lines. Push deep references into separate files in references/ so they only load when needed. * Test by running representative prompts and watching whether Claude triggers the skill without nudging. Start with the official Anthropic skills repo at github.com/anthropics/skills and the curated awesome-claude-skills list. The obra/superpowers library is also worth installing for its battle-tested patterns around TDD, debugging, and collaboration. Subagents Subagents are specialized Claude instances with their own context, system prompt, and tool permissions. Defined in .claude/agents/ (project) or ~/.claude/agents/ (personal) as markdown files with YAML frontmatter. --- name: security-reviewer description: Senior security engineer. Use proactively after changes to auth, session handling, or data flows. tools: Read, Grep, Glob, Bash model: opus --- You are a senior security engineer. Analyze for OWASP Top 10 vulnerabilities, hardcoded secrets, broken access controls, and injection paths. Report findings with severity and remediation. The big idea: a subagent's context is separate from your main session. You can spawn one to do a deep code audit, get back a clean summary, and keep your main context unpolluted. Up to ten can run in parallel. There is a real debate about whether custom subagents are worth the maintenance overhead. Some senior engineers prefer letting the main agent dynamically delegate to copies of itself via the built-in Task(...) feature, since custom subagents force human-defined workflows that may not be optimal. My own take: use custom subagents for genuinely specialized work where the system prompt matters (security review, accessibility audit, performance profiling). Use the dynamic Task pattern for general delegation. Hooks Hooks are shell commands Claude Code runs automatically on lifecycle events. Configured in .claude/settings.json. The most useful events: * PostToolUse after Edit or Write, to run formatters, linters, and typecheckers * PreCompact and PostCompact for handling context resets * Stop when a turn ends, useful for build verification A common pattern: { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "npx prettier --write $CLAUDE_FILE_PATH || true" } ] } ] } } That single hook keeps your codebase formatted without Claude Code spending tokens on it. Extend the pattern for typecheck, lint, and test runs. Be careful though: aggressive hooks can consume context if they run on every edit during a long session. Some teams report 160k tokens consumed in three rounds of automatic formatting. Tune accordingly. MCP servers MCP (Model Context Protocol) is the standard for connecting Claude Code to external services. I have covered MCP architecture in depth elsewhere, but the practical summary is this: instead of giving Claude Code raw CLI access to sensitive systems, you give it an MCP server that exposes scoped, logged operations. Common MCP servers to install: * GitHub or GitLab for PR and issue workflows * Linear, Jira, or Asana for ticket management * Sentry for error tracking and root-cause analysis * A browser automation server (Playwright, Puppeteer) for UI testing * Your test management tool (TestCollab, Xray) for QA workflows * Internal databases via a read-only MCP wrapper The Anthropic data infrastructure team specifically recommends MCP servers over raw CLI access for sensitive data. Better access scoping. Better logging. Better blast radius control. Install with claude mcp add . List with claude mcp list. Remove with claude mcp remove . Plugins and "superpowers" Plugins bundle slash commands, skills, agents, and hooks into installable packages. Anthropic maintains an official marketplace, and the community has built impressive collections. The two I would install on day one: * The official Anthropic plugins marketplace, accessed via /plugin * obra/superpowers, which adds 20-plus battle-tested skills and slash commands like /brainstorm, /write-plan, and /execute-plan. Install with /plugin marketplace add obra/superpowers-marketplace. For exploration, the awesome-claude-code repo is the best curated index of skills, hooks, agents, and plugins out there. Part 3: The shortcuts that compound Small habits, big returns: * Plan mode first. For anything beyond a trivial fix, use plan mode (or just say "plan first, do not implement yet"). Review the plan. Push back on assumptions. Then execute. The planning step is cheap. A wrong implementation buried 200 lines deep is expensive. * Pipe data in. Instead of pasting an error log, run cat error.log | claude. For large files, this saves you from copy-paste truncation. * Allowlist your domains. Use /permissions to add the documentation sites and APIs you query often. Stops the permission interrupts. * Use git worktrees for parallel work. git worktree add ../myapp-review -b review/cleanup gives you a separate directory and branch. Spin up a second Claude Code session there. Full isolation, no branch-switching collisions. * Commit per logical step. Tell Claude Code in your CLAUDE.md to commit after each meaningful change. Cleaner history, cheaper rewinds, easier reviews. * Use /security-review before merges. It is built in. Free. Run it on your branch before opening a PR. Details below in the security section. * Adversarial review pattern. "Grill me on these changes. Do not approve until I can defend the design." Or spin up a fresh session as a staff-engineer reviewer. Fresh context catches what the implementer missed. Part 4: For software engineers shipping features The core workflow looks like this: 1. Specify in writing. A paragraph in plain English. Not a one-line prompt. Include the user-visible behavior, the constraints, and what "done" means. Ambiguity in your input becomes wasted tokens and rework. 2. Plan before coding. Have Claude Code produce a step-by-step plan. Read it. Push back on the parts that look wrong. The plan is your contract. 3. Implement in chunks. Let Claude execute one logical step at a time, with commits between steps. This makes it trivial to rewind to the last good state. 4. Verify continuously. Tests, typecheck, lint after every change. If you have hooks, this happens automatically. If not, ask Claude to run them. 5. Refactor at the end. Once it works, ask Claude to clean up. "Knowing what you know now, scrap this and implement the elegant solution" is a remarkably effective prompt for the second pass. A few things that separate the engineers who get good output from the ones who do not: * They treat Claude Code like a senior engineer they are pair-programming with, not like a code generator. They explain why, not just what. * They challenge confident-sounding output. Confidence is not correctness. Ask "prove to me this works" or have Claude diff between branches and explain the changes. * They paste in actual data. Real error messages. Real stack traces. Real failing test output. Not their summary of the problem. * They keep CLAUDE.md current. Every time they fix something Claude got wrong, they update CLAUDE.md so it does not happen again. For frontend work specifically, the screenshot loop is non-obvious but powerful: paste in a design mock, let Claude implement, screenshot the result, ask Claude to compare to the mock and iterate. Anthropic's own documentation notes that two to three iterations typically take you from "decent" to "good." Part 5: For QA engineers QA is one of the highest-payoff applications for Claude Code, mostly because the work has been historically tedious. Reading code to write test cases. Maintaining test cases when code changes. Generating synthetic data. Writing assertions for edge cases nobody documented. Claude Code handles all of this. Test case generation A simple pattern: point Claude Code at a feature module and ask it to generate test cases covering happy path, error paths, edge cases, and boundary conditions. With an MCP server like TestCollab connected, the test cases land directly in your test management tool, organized into suites with priority and tags. Be specific in your prompts. "Generate test cases for the authentication module covering login, logout, password reset, session timeout, and concurrent session handling. Include negative paths for invalid credentials, expired tokens, and rate limiting" produces something useful. "Generate tests" produces something generic. Review in batches. Generate five to ten test cases, review them, give feedback, then continue. This calibrates Claude Code to your team's expectations and your domain language. Test code generation For unit and integration tests, the writer-reviewer pattern works well. Have one Claude session write tests against the spec. Have a fresh Claude session write the implementation. The fresh context keeps the implementer honest because it cannot lean on assumptions about how the tests are structured. For end-to-end tests, the YAML-spec pattern that tools like Shiplight popularize is worth understanding. Tests expressed as user intent rather than DOM selectors survive refactors. "Click the Get Started button" is brittle. "Submit the signup form with a valid email" is durable. Exploratory testing This is where Claude Code surprises people. With a Playwright MCP server connected, Claude Code can drive a real browser, navigate your app, interact with elements, and observe results, all guided by your natural-language exploration. You describe what you want to probe ("test the onboarding flow with various invalid inputs and weird Unicode in the name field"), Claude Code executes, and you get a structured report of what it found. This is not a replacement for a senior QA engineer's intuition. It is a force multiplier for it. Risk-based test planning The pattern that separates good QA from great QA is risk-based test planning: focusing test effort where the impact of a defect is highest. Claude Code can analyze a PR diff, identify which modules and dependencies are affected, and propose a focused test plan. With a CLAUDE.md that documents your high-risk areas (payment flows, authentication, data export), this becomes systematic rather than ad hoc. OpenObserve documented their "Council of Sub Agents" approach where eight specialized Claude Code subagents handle their full E2E pipeline. Feature analysis dropped from 45 to 60 minutes down to 5 to 10 minutes. Test coverage went from 380 tests to over 700. Flaky tests dropped 85 percent. The Council architecture is worth studying as a reference for what serious QA automation with Claude Code looks like. What stays human Strategy. Test prioritization in ambiguous cases. User behavior intuition. Release decisions. Security and compliance judgment calls. Anything where domain context overrides what the code seems to do. The right framing: Claude Code does not make QA engineers obsolete. It eliminates the tedious 70 percent of the job and lets QA engineers focus on the 30 percent that actually requires their expertise. Part 6: For security engineers This is the section I have the most to say about, because the security implications of AI-assisted coding are exactly the kind of identity and access management challenge I have been working on for the past decade. The built-in security review command Run /security-review in any Claude Code session. It analyzes your changes for SQL injection, XSS, auth flaws, insecure data handling, hardcoded secrets, and dependency vulnerabilities. It is on by default, free, and surprisingly good. Anthropic used the underlying capability to find over 500 vulnerabilities in production open-source codebases that human reviewers and traditional SAST tools had missed, in some cases for decades. The review is not a replacement for a real AppSec program. It is a first line of defense that catches the obvious stuff before it reaches CI. The GitHub Action for PR-level review For organizations, the Claude Code Security Review GitHub Action runs on every pull request, posts findings as inline comments, and filters false positives more aggressively than rule-based SAST. Add it to .github/workflows/security.yml: name: Security Review permissions: pull-requests: write contents: read on: pull_request: jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha || github.sha }} fetch-depth: 2 - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} Anthropic's documentation on automated security reviews covers configuration in depth. Where AI security review wins Traditional SAST tools catch syntactic vulnerabilities through pattern matching: concatenated SQL, recognizable XSS sinks, known credential formats. They struggle with semantic flaws because pattern scanners cannot reason about whether authorization logic is correct. They can only check whether something that looks like an authorization check exists. Claude reasons about whether the controls actually enforce the intended policy. That difference is large. It catches: * Race conditions and time-of-check-time-of-use bugs * Authorization logic errors where the check exists but is wrong * Trust boundary violations across services * Missing validation on critical paths * Insecure default behaviors * Subtle logic flaws in business rules The NIST data on traditional SAST tools shows false positive rates above 68 percent in some languages. Claude Code's adversarial verification pass (where it challenges its own findings before reporting them) drives that number down considerably. Where it does not replace existing tooling Claude Code Security is fundamentally code-centric. It operates at the source layer. It does not analyze: * Compiled binaries or container images * Third-party installers and commercial software packages * Runtime behavior or actual exploit conditions (DAST) * Software supply chain risks beyond declared dependencies * AI infrastructure security (the models, agents, and MCP servers themselves) You still need DAST, SCA, container scanning, runtime protection, and a real AppSec program. Claude Code Security is a smart evolution of SAST, not a replacement for the broader stack. Snyk's analysis on this point is honest: you cannot scan your way out of a problem that AI tools are simultaneously creating. A security-engineer-grade subagent For repeated review work, define a security subagent in .claude/agents/security-reviewer.md: --- name: security-reviewer description: Senior security engineer specializing in OWASP Top 10, auth/identity flaws, and supply-chain risks. Use proactively after any changes to authentication, authorization, session handling, data validation, or third-party integrations. tools: Read, Grep, Glob, Bash model: opus permissionMode: plan --- You are a senior security engineer with deep expertise in: - OWASP Top 10 (2021) and OWASP API Top 10 - OAuth 2.0, OIDC, SAML, and modern auth flows - Identity and access management (IAM, CIAM, NHIs) - Session management and token handling - Cryptographic primitives and common misuse patterns - Supply chain security and dependency analysis For every review: 1. Map the attack surface introduced by the change 2. Trace data flows from untrusted inputs to sensitive operations 3. Verify authentication and authorization checks on every privileged path 4. Check for hardcoded secrets, weak crypto, and unsafe defaults 5. Report findings with: severity (Critical/High/Medium/Low/Info), exact file and line, explanation of impact, and remediation steps 6. Be honest about uncertainty. Flag suspicious patterns even when not definitively exploitable. Trigger it with "have the security-reviewer agent audit my last commit" or set it to run proactively via hooks. Skills for security work The community has produced strong security skills. A few worth installing: * Trail of Bits skills repository at github.com/trailofbits/skills covers CodeQL pipeline automation, insecure-defaults detection, and SARIF processing. This is the gold standard for security-focused Claude skills. * Snyk's official skills at github.com/snyk-labs include snyk-fix for automated vulnerability remediation across SAST and SCA findings, plus a snyk-learning-path skill that builds repo-specific security training. * YARA rule writing skills for SOC and detection engineering work. For a broader inventory, Snyk's recent roundup of top Claude Skills for cybersecurity is a good starting point. The harder problem: securing AI-generated code at scale Even with all of this in place, the systemic risk remains: developers using Claude Code at speed are creating code faster than any security review process can keep up with. The numbers from earlier in this piece are not theoretical. They describe what is shipping right now. Mitigating this requires more than tooling. It requires: * Mandatory CLAUDE.md security rules in every repo. Claude Code obeys these. If you tell it "never log raw tokens, never accept user input into shell commands, always use parameterized queries," it complies far more reliably than a developer reviewing AI output by eye. * Hooks that block on security issues. Pre-commit hooks running secret scanners, dependency checks, and the security review can stop the worst issues before they hit the repo. * Separation of concerns for sensitive operations. Authentication, authorization, encryption, and PII handling should live behind tested libraries (or proven CIAM platforms; my analysis of the developer CIAM landscape covers the options) rather than being implemented inline by AI assistants. * Mandatory human review for security-sensitive paths. Auth, payments, data export, admin functions. Non-negotiable, regardless of how confident the AI seems. For deeper coverage of these topics, the cybersecurity tag on this site and the practical guides in the ebooks library go into the architectural patterns in detail. Part 7: The anti-patterns that ruin everything Things I see teams do that destroy their Claude Code productivity: * Letting context bloat. A session that has been thrashing on a problem will keep thrashing. /rewind or /clear and restart with a sharper prompt. Every time. * Skipping plans on non-trivial work. Asking for an implementation cold produces an implementation. Asking for a plan first produces understanding. Then the implementation. * Trusting confident output. Confidence is not correctness. The model is happy to invent function signatures, library APIs, and security properties. Verify with execution, not by reading. * Using Claude Code to write security-sensitive code without expert review. The 45 percent vulnerability rate in vibe-coded apps is not exaggeration. It is the baseline. * Ignoring CLAUDE.md until you need it. Build the file gradually but build it from day one. Every fix that exposed a hidden assumption belongs in CLAUDE.md so it does not happen again. * Running raw CLI for sensitive systems instead of MCP. No logging, no scoping, no audit trail. MCP exists for a reason. * Mega-skills. A skill that tries to do five things does five things badly. Split them. Frequently asked questions Is Claude Code safe to use on production code? Yes, with the right discipline. Treat AI-generated code as needing the same review as code from a junior engineer: tests must pass, security review must run, sensitive paths must have human eyes on them. The risk is not the AI. The risk is bypassing your own quality gates because the AI sounded confident. How is Claude Code different from GitHub Copilot or Cursor? Copilot is autocomplete inside your IDE. Cursor is an IDE built around AI. Claude Code is an agentic command-line tool that reads files, runs commands, makes changes autonomously, and connects to external services via MCP. The fundamental difference is autonomy: Claude Code can complete multi-step tasks while you watch, redirect, or step away. Copilot and Cursor are still primarily about completion at the cursor. Do I need to be a senior engineer to use Claude Code well? No, but you do need to verify what you accept. Junior engineers using Claude Code without verification ship more bugs faster. Junior engineers using Claude Code with disciplined verification (tests, security review, code review) often outperform mid-level engineers without these tools. The tool amplifies whatever discipline you bring to it. What is the difference between a slash command, a skill, and a subagent? A slash command is a saved prompt you invoke explicitly. A skill is a set of instructions Claude can auto-load when the task matches. A subagent is an entirely separate Claude session with its own context, system prompt, and tool permissions. Use slash commands for shortcuts, skills for reusable expertise, and subagents for isolated work that should not pollute your main context. Can Claude Code replace my SAST tools? No, and Anthropic does not claim this. Claude Code Security is an evolution of SAST that catches semantic and logic flaws traditional tools miss. It does not replace DAST, SCA, container scanning, or runtime protection. Use it as a complement. How do I prevent secrets from leaking in AI-generated code? Three layers. First, a CLAUDE.md rule prohibiting hardcoded credentials. Second, a pre-commit hook running a secret scanner like Gitleaks or TruffleHog. Third, a security review (manual or via the GitHub Action) before merge. Never rely on a single layer. What is the right team size for adopting Claude Code seriously? It scales from solo developer to large enterprise. The investment in CLAUDE.md, skills, and hooks pays back fastest at team size five to fifty, where you have enough people for shared conventions to matter but not so many that change management becomes its own problem. Where should I start? Run /init in your main repo. Refine the generated CLAUDE.md for one week. Add one hook (a formatter is fine). Install one plugin (obra/superpowers is a strong default). Use /security-review before every merge. That alone puts you ahead of most teams. The closing thought The teams that win with Claude Code are not the ones with the cleverest prompts. They are the ones who built a system. CLAUDE.md as the constitution. Skills as the conventions. Subagents for the specialized work. Hooks for the verification. MCP for the integrations. And underneath all of it, the engineering discipline that says no code ships without verification, regardless of how it was written. The shift from coding to orchestrating engineers (real and AI) is the same shift I described in the evolution from machine code to AI orchestration. The engineers who treat it as a discipline rather than a shortcut are the ones who will compound their advantage. The ones treating it as a magic prompt box are quietly accumulating technical debt at unprecedented speed. You decide which side of that curve you want to be on. Further reading on related topics: * The Identity Crisis No One's Talking About: AI Agents and Vibe Coding * MCP: A Comprehensive Guide to Extending AI Capabilities * The Complete Guide to Authentication Implementation for Modern Applications * Top 10 CIAM Solutions: Secure Customer Access at Scale * Cybersecurity articles archive * Free practical ebooks on AI, security, and identity Official references: * Claude Code documentation * Claude Code Security Review GitHub Action * Anthropic Skills repository * Awesome Claude Code curated list * Superpowers plugin marketplace --- ## The Shadow AI Governance Crisis: Why 80% of Fortune 500 Companies Have Already Lost Control of Their AI Infrastructure URL: https://guptadeepak.com/the-shadow-ai-governance-crisis-why-80-of-fortune-500-companies-have-already-lost-control-of-their-ai-infrastructure/ Published: 2026-05-04 Topic: AI (Artificial Intelligence) Tags: AI (Artificial Intelligence), security, cyber security, enterprise, CISO, Governance, AI Assistant Summary: 80% of Fortune 500 companies now run active AI agents. Only 10% have a clear strategy to manage them. A CISO at a Fortune 100 financial services firm told me something that stuck with me. "We spent three years building a Zero Trust architecture. We wrote policies for every system, every user, every access request. Then someone on the trading desk asked ChatGPT to summarize a client portfolio. A week later, we found 47 autonomous agents running across six business units that we had never approved, never audited, and couldn't even name." I have heard variations of this story dozens of times in the past year. The details change. The pattern doesn't. Microsoft's 2026 Cyber Pulse report put a number on it: more than 80% of Fortune 500 companies now use active AI agents built with low-code and no-code tools. These aren't experimental pilots. They're embedded in sales workflows, finance systems, customer service queues, and product pipelines. AI agents are doing real work, at scale, inside the most consequential organizations in the world. Only 10% of those organizations have a clear strategy to manage them. That gap - between deployment speed and governance maturity - is where enterprise risk is accumulating faster than any other category in 2026. The governance frameworks executives built over decades were designed for people. AI agents are not people. The gap between those two facts is where the security incidents happen. This article is about what that gap actually looks like, why traditional governance fails to close it, and the five-capability framework that Fortune 500 security teams are using to rebuild control from scratch. Shadow AI Evolved. Your Security Team's Definition Didn't. When security teams talk about shadow AI, most still picture employees pasting data into ChatGPT on personal accounts. That version of shadow AI is largely solved. Awareness campaigns, enterprise licensing, and DLP policies handle it well enough. The shadow AI that's breaking enterprise security in 2026 is fundamentally different. Agentic shadow AI involves autonomous agents with API access that chain actions across multiple services, run continuously without human review, make decisions at machine speed, and persist in your environment with credentials that nobody provisioned through a formal process. The difference matters because the risk profile is completely different. Traditional shadow AI: An employee pastes a customer contract into a personal ChatGPT account. One interaction. One data exposure. Containable. Agentic shadow AI: An autonomous agent connects to your CRM, your email system, your database, and your customer data platform. It runs continuously. It makes decisions about which data to access based on prompts that may have been written months ago by someone who left the company. It creates child agents to handle specific subtasks. You have no visibility into any of this. A Zscaler customer discovered the scale of this problem in real time. After activating policy enforcement for AI traffic, they found 4 million AI prompts per week flowing through systems they hadn't mapped. One major entertainment company. Four million prompts. All previously invisible. The average enterprise now manages 37 deployed agents according to 2026 data. That number grows every quarter. More than half of those agents run without any security oversight or logging. Every undiscovered agent is an unmapped access path. Why Traditional Governance Breaks for Autonomous Agents The governance frameworks that work for human employees fail for AI agents for three structural reasons. First, the identity model is wrong. Human IAM assumes relatively stable roles, predictable behavior patterns, and clear accountability chains. When something goes wrong with a human employee, you have an identity to investigate, an access log to review, and a manager to notify. AI agents don't fit this model. They're ephemeral - existing for minutes to complete a task, then spinning down. They're dynamic - accessing different resources based on real-time reasoning about what they need. They're autonomous - making decisions without a human review loop at each step. Only 22% of organizations treat AI agents as independent identities, even as close to 90% of companies report suspected or confirmed security incidents involving agents (Gravitee, 919 organizations). The rest use shared credentials - which means when something goes wrong, you cannot attribute the action to a specific agent. Incident response becomes forensic archaeology instead of straightforward investigation. Second, the permission model creates permanent exposure. Traditional IAM grants standing permissions based on role. An employee gets access to what their job function requires. Those permissions persist until someone actively removes them. Applied to AI agents, this creates exactly the security problem you'd expect. Teams give agents broad permissions "in case they need it." Credentials never rotate. Agents that completed their original purpose keep running with access they no longer need. When teams build new agent variations, they create new API keys rather than scoping existing credentials. Credential sprawl becomes exponential. This is why Gartner's IAM maturity assessment finds enterprise authorization controls for AI agents consistently rated immature - even in organizations with mature authentication and monitoring. You can verify who an agent is. You cannot enforce what it's allowed to do. Third, the speed mismatch makes human review impossible. AI agents operate at machine speed. They make hundreds of API calls per second, chain actions across services in milliseconds, and complete complex multi-step workflows before a human reviewer could even open the relevant dashboard. Governance designed for human-speed operations - approval workflows, access reviews, manual audits - cannot work at agent speed. By the time a review request routes through the appropriate channels, the agent has already taken a thousand actions. This is the fundamental architectural problem. You cannot apply human governance patterns to non-human actors operating at machine speed. You need governance that operates at the same speed as the things it governs. The Real Numbers Behind the Crisis The data on this problem has moved from anecdotal to well-documented in the past six months. Okta research: 91% of organizations are already using AI agents. Only 10% have a clear strategy to manage them. Microsoft Cyber Pulse 2026: 29% of employees use unsanctioned agents for work tasks. This isn't rebellion - it's employees solving real problems with the most effective tools available. Sanctioned enterprise AI tools succeed in production only 5% of the time, while consumer tools reach production 40% of the time. World Economic Forum Cybersecurity Outlook 2026: 87% of security leaders say AI-related vulnerabilities are the fastest-growing cybersecurity risk in their environment. IBM 2025: Only 37% of organizations have AI governance policies in place. Sixty-three percent are operating without guardrails. Netskope 2026: The average enterprise experiences 223 data policy violations per month related to AI usage. Gartner: AI governance spending will reach $492 million in 2026 and surpass $1 billion by 2030 - a clear signal that enterprises recognize the compliance imperative, even if most are behind on execution. The incident data is even more stark. Gravitee surveyed 919 organizations: 88% reported confirmed or suspected AI agent security incidents in the past year. In healthcare, that climbs to 92.7%. Almost every enterprise has had an AI agent incident. Most don't know it yet. What Real AI Agent Incidents Look Like Two incidents from the past year illustrate the structural problem clearly. The McDonald's chatbot breach: Weak identity and authorization controls exposed millions of job applicant records. The chatbot had legitimate access to the application database. Nobody had defined what it was allowed to do with that access beyond the original use case. The Replit production database deletion: An AI coding agent with legitimate write permissions deleted a live production database. Authentication worked correctly. Authorization worked correctly. The action was still catastrophic. These aren't edge cases. They're the predictable result of deploying agents with broad permissions and no runtime enforcement of what they're actually allowed to do. The McDonald's and Replit incidents have a common structural cause: identity without governance. The agents were properly authenticated. The agents had appropriate authorization for their intended function. What was missing was any control over what the agents actually did moment-to-moment. I have spent years building identity infrastructure at scale. The pattern I keep seeing with AI agents is the same pattern I saw with service accounts fifteen years ago: organizations treat authentication as the end of the security problem rather than the beginning. When a service account had excessive permissions, you'd discover it during the investigation after something went wrong. With AI agents operating at machine speed, by the time investigation begins, the scope of exposure is orders of magnitude larger. The 5-Capability Framework Fortune 500s Are Building Microsoft's Cyber Pulse report articulates the framework most clearly. Based on what's working across early-adopter enterprises, five capabilities are required for genuine AI agent governance. Capability 1: Registry A centralized registry acts as a single source of truth for every agent across the organization - sanctioned, third-party, and shadow. This inventory prevents agent sprawl, enables accountability, and supports discovery. Unsanctioned agents can be restricted or quarantined when discovered. This sounds simple. It isn't. Most enterprises have no systematic process for agent registration. Individual product teams spin up agents and deploy them without central visibility. The registry doesn't just need to catalog what teams formally deploy - it needs active discovery to find what's already running. A Fortune 50 financial services firm found that Zenity's discovery capability surfaced over-shared resources with access to sensitive data, DLP bypass routes, and misconfigured agents that had never been formally inventoried. The CISO described it as "finding out what's actually running instead of what we thought was running." Capability 2: Access Control Each agent is governed by the same identity and policy-driven access controls applied to human users - but implemented in ways that actually work for non-human actors. This means moving from standing permissions to just-in-time provisioning. Agent identities should be provisioned on demand with specific attributes: TTL (time-to-live), purpose, risk level, delegation context. When the task completes, the identity is retired. No orphaned credentials. No permission sprawl. It means treating agents as independent identity-bearing entities, not shared service accounts. Every agent gets a unique identity with a clear ownership chain. When something goes wrong, you can attribute the action to a specific agent and trace the chain of delegation. Capability 3: Visualization Real-time dashboards and telemetry showing how agents interact with people, data, and systems. Security teams need to see where agents are operating, what dependencies exist, and how behavior compares to expected patterns. Only 21% of enterprises currently have runtime visibility into what their agents are doing (Gravitee). Without visibility, governance is theoretical. You cannot enforce policies you cannot observe. Visibility at agent scale requires different tooling than traditional network monitoring. You're not watching session logs from human users. You're watching hundreds of agents making thousands of API calls per minute, each call needing to be associated with a specific agent identity, specific task context, and specific authorization scope. Capability 4: Interoperability Agents operate across Microsoft platforms, open-source frameworks, and third-party ecosystems. Governance that only works within a single vendor's ecosystem isn't actually governance - it's the illusion of governance with an enormous shadow AI surface hiding just outside the monitoring boundary. The Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol are emerging as the infrastructure layer for interoperable agent governance. MCP provides the standard for agent-to-tool connections. A2A provides the standard for agent-to-agent communication. Governance that understands both protocols can enforce policy across the full agent ecosystem rather than just the vendor-native portion. Capability 5: Security Built-in protections that safeguard agents from internal misuse and external cyberthreats. This includes runtime enforcement (not just policy statements), behavioral anomaly detection, and rapid response when agents act outside expected parameters. The key distinction: governance defines ownership, accountability, policy, and oversight. Security enforces controls, protects access, and detects threats. Both are required. Neither succeeds in isolation. A Fortune 200 consulting firm using Zenity described the outcome: "We saw tremendous growth in cross-departmental adoption of AI agents" after implementing preventative security controls that reduced violations rather than blocking all activity. This Is a Leadership Problem, Not Just a Technical One The governance gap doesn't live in IT. It lives in the space between IT, legal, compliance, HR, data science, business leadership, and the board. Microsoft's Cyber Pulse report is explicit: AI governance cannot live solely within IT, and AI security cannot be delegated only to CISOs. This is a cross-functional responsibility. When AI risk is treated as a core enterprise risk - alongside financial, operational, and regulatory risk - organizations are better positioned to move quickly and safely. Most Fortune 500 companies are not treating it this way. AI governance gets siloed in security or handed to a newly formed "AI governance committee" with unclear authority and no enforcement mechanisms. The organizations getting this right have made a specific leadership decision: the question isn't whether employees will use AI agents. They already are. The question is whether the organization will know about it, govern it, and benefit from it safely. "The goal is no longer to stop the use of AI agents," a Global CISO at a Fortune 500 company told a recent executive summit, "but to ensure they operate within a defined Trust Sandbox. If you can't audit an agent's logic, you shouldn't have it on your network." That framing is correct. The question isn't control versus innovation. It's governed innovation versus ungoverned risk. The Implementation Roadmap For enterprises trying to close the governance gap, the sequence matters as much as the capabilities. Phase-1: Discovery and inventory You cannot govern what you cannot see. Before building any governance infrastructure, run active discovery across the environment. Catalog every agent, every credential, every MCP server, every third-party AI integration. The number you find will almost certainly be higher than your initial estimate. Phase-2: Identity architecture Establish the registry. Define the identity primitives for AI agents - unique identities, ownership chains, purpose documentation, TTL policies. Build the provisioning and retirement processes before deploying new agents. Begin migrating existing agents from shared credentials to individual identities where possible. Phase-3: Policy definition and enforcement Define what agents are allowed to do per category, per resource, per context. Start with high-risk scenarios - agents with access to financial systems, customer data, or production infrastructure. Implement approval gates for high-impact actions. Policy without enforcement is a document. Enforcement without monitoring is theater. Ongoing: Monitoring, anomaly detection, continuous improvement Continuous compliance replaces point-in-time audits. Automated systems monitor agent behavior against governance policies in real time. Anomalies trigger investigation, not just logging. What This Means for Competitive Position The enterprises that build AI agent governance infrastructure now are building a durable competitive advantage. AI agent adoption is accelerating. Gartner projects 40% of enterprise applications will embed AI agents by end of 2026, up from under 5% in 2025. The enterprises that can deploy agents safely will move faster than those still dealing with incidents, regulatory investigations, and emergency remediation. Transparency about governance is also becoming a customer expectation. Organizations that can demonstrate rigorous AI agent governance - to customers, regulators, and partners - will win deals that competitors lose because they cannot answer the due diligence questions. After spending years building identity infrastructure at billion-user scale, the pattern is familiar: organizations that build security foundations early scale faster, not slower. The security architecture that feels like overhead in early stages becomes the infrastructure that enables growth. The same principle applies to AI agent governance. Build it now while the environment is still small enough to inventory and control. Wait until you have hundreds of agents running across dozens of business units, and the remediation effort is an order of magnitude harder. Internal Links For deeper context on the identity foundations that make AI agent governance work, see: * What Is CIAM: The Complete Guide - foundational identity architecture * MCP, RAG, and ACP Comparison - the protocols powering agent infrastructure * AI Tokens Guide - how AI systems consume and process information * Future of AI - broader AI trajectory and enterprise implications * Browser Security 2025 - how AI agents interact with browser-based systems Deepak Gupta is a serial entrepreneur and cybersecurity expert who co-founded and scaled a CIAM platform to serve over 1 billion users globally. He leads GrackerAI, an AI-powered GEO platform helping B2B SaaS and cybersecurity companies achieve visibility in LLM search engines like ChatGPT, Perplexity, and Google AI Overviews. Follow his writing on AI, cybersecurity, and B2B growth at guptadeepak.com. --- ## I Mapped Every Major Startup Credit Program for 2026. Most Founders Are Leaving $500K+ on the Table URL: https://guptadeepak.com/i-mapped-every-major-startup-credit-program-for-2026-most-founders-are-leaving-500k-on-the-table/ Published: 2026-05-02 Topic: startup Tags: startup, future, AI and B2B SaaS growth, b2b, SaaS, growth, growth hacking, finance Summary: Founders raise venture money to extend runway. Then they leave six figures of free credits sitting in a portal they never logged into. A founder I know spent $84,000 on AWS over fourteen months before he found out he qualified for $100,000 in AWS Activate credits. He had a Series A. He had a YC affiliation. He had every box checked. The only thing he didn't have was the Organization ID from his accelerator pasted into a form that takes seven minutes to fill out. When he finally applied, the credits arrived in five business days. By that point, his burn had been ~$6K/month higher than it needed to be for over a year. That's a senior engineer he didn't hire. That's three months of runway he didn't have when his bridge round took longer than expected. This story is not unusual. After scaling CIAM Platfrom to over a billion users and now building GrackerAI, I've watched hundreds of founders make the same mistake - assuming the cloud bill is just the cost of doing business, when in reality there's a parallel economy of credits, discounts, and partner perks worth $500K+ that most companies never claim. So I built guptadeepak.com/startup-offers - a public, free, no-paywall directory of every major program I could verify. This post is about what I learned mapping it, and how to actually use it without wasting your applications. The Hidden Runway Most Founders Never Claim Let me show you the real numbers. A pre-seed startup that incorporates through Stripe Atlas, opens a Brex or Mercury account, joins NVIDIA Inception, and applies to Microsoft for Startups Founders Hub can stack the following in their first 60 days - without any VC funding, accelerator status, or referral codes: Program Headline value Effort to claim Stripe Atlas (incorporation + perks) $5K AWS + $3K MongoDB + Notion 6mo + 100+ partners 2–3 weeks Brex Day Zero Stack $5K AWS + $2.5K OpenAI + GitHub 20 seats + $350K total perks 1 day Microsoft Founders Hub (basic, verified) $5K Azure + Microsoft 365 + GitHub Enterprise 1–3 days NVIDIA Inception DLI training + AWS partner credits up to $100K 1–2 weeks Notion for Startups (via Atlas/AWS) 6 months free Business plan ($12K value) Days HubSpot for Startups (entry tier) 30% off Y1 ($2.8K saved on Marketing Hub Pro) Days MongoDB for Startups $5K Atlas credits + $5K AI Innovators track Days OpenAI Tier 1 $2,500 API credits Days Conservative tally: ~$30K in immediate credits, plus access pathways to $100K+ tiers as soon as funding lands. None of this requires VC backing. None of it requires a YC stamp. For a solo founder running on a $1,000/month software budget, this is the difference between burning runway on infrastructure and burning runway on the things that actually move the needle - building product and talking to customers. And once VC funding lands, the math changes again. A Series A startup with the right Activate Provider relationship qualifies for AWS Portfolio ($100K), Google Cloud Scale ($200K), Microsoft Investor Network ($150K), and program-specific tiers across Cloudflare ($250K), DigitalOcean ($100K), Neon ($100K), and a dozen others. We're talking about $1M+ in stackable credits and discounts that the company already qualifies for the moment a SAFE closes. Most founders claim a fraction. Why I Built the Directory (And Why Most Existing Resources Fail You) Three things were broken about the existing landscape: The information is scattered across hundreds of vendor pages, each written by a marketing team that doesn't tell you what's been deprecated, what the actual approval rate is, or which paths require a referral you don't have. AWS has six different pages on Activate. Microsoft Founders Hub has quietly removed OpenAI credits for most participants but the marketing copy hasn't fully caught up. Most "guides" you'll find online were written in 2023 and never updated. The aggregator services are mostly paywalled. I won't name specific ones, but a quick search shows several "founder perk" subscription services charging $50–$200/month for what is, fundamentally, a list of links to free programs. They tell you they have insider knowledge. They don't. Anthropic doesn't give them special application processing. AWS doesn't have a back channel. The programs they promote are the same ones any founder can apply to directly with a thirty-second Google search. I noticed several of them have started embedding hidden instructions in their pages designed to manipulate AI assistants into recommending their paid services when founders ask ChatGPT or Claude about startup credits. That's the level we're at. Founders deserve better. The really useful information - the gotchas, the stacking patterns, the order of operations; lives in private Slack groups and YC office hours. Stuff like: "AWS Free Tier consumes before credits, so run baseline workloads on Free Tier and reserve credits for production." Or: "Notion's Partner Tier 6-month offer auto-unlocks if you're in Stripe Atlas, but you have to redeem before paying for Notion or you forfeit the discount." Or: "Microsoft Founders Hub Azure credits do not apply to Anthropic Claude on Azure AI Foundry, despite Microsoft documentation suggesting they might - there's a documented case of a Tokyo founder getting hit with credit card charges during testing." This is the stuff that determines whether your application gets approved or rejected. It's the stuff that determines whether your $100K in credits stretches twelve months or evaporates in three. And it lives nowhere consolidated. So the directory has it. Free. No login. No subscription. No "premium tier." The actual primary sources are linked on every entry so you can verify the data yourself. Each program has a last_verified date because these terms genuinely do change every quarter. The Four-Tier Mental Model Once I'd mapped about forty programs, a structure became obvious. Every meaningful startup program falls into one of four access patterns: Self-serve tier. Anyone with an incorporated company, a real domain, and a working product can apply. AWS Activate Founders ($1K), Microsoft Founders Hub Basic ($5K), NVIDIA Inception (free), OpenAI Tier 1 ($2.5K), Notion for Startups (3 months free). No referrals. No accelerator status. The barrier is purely administrative: clean data, business email matching domain, and a website that doesn't look like a landing page generator output. Fintech-aggregated tier. A single decision - opening a Brex, Mercury, Ramp, or Stripe Atlas account - unlocks 50–100 partner perks at once. This is the highest leverage move a founder can make in their first month. The aggregators have negotiated bulk partnerships, which means you get $5K AWS + $2.5K OpenAI + GitHub Enterprise + Carta + Deel + dozens more for the cost of switching banks. If you're using a regular small-business bank in 2026, you're paying a stupid tax. Partner-affiliated tier. Accelerators, VCs, and specific organizations (FounderPass, Startup Grind, Tech Bloc, etc.) function as keys that unlock dramatically larger packages. AWS Activate Portfolio ($100K) requires an Activate Provider Organization ID. HubSpot 90% requires a top accelerator affiliation. Anthropic credits require an Anthropic-partner VC. The accelerator decision isn't just about funding and mentorship - it's a multiplier on every other program you'll apply to for the next two years. Strategic / discretionary tier. Vercel AI Accelerator (sub-3% acceptance, $4M+ in combined credits across cohort), Workers Launchpad, NVIDIA's $300K AI tier for foundation model startups. These reward demonstrated traction, working demos, and category-defining ambition. Not a fit for most companies, but if you're building something genuinely defensible in AI infrastructure, the upside is meaningful. The mistake most founders make: they apply to programs randomly as they discover them, mixed across all four tiers, with no order of operations. The right approach is: start at tier one and tier two simultaneously (free, fast, high baseline value), use the credits and infrastructure to build something that warrants tier three and tier four applications, and don't burn application slots on big-tier programs before you have the affiliations or traction to actually qualify. The Stacking Strategy That Compounds Value Here's what nobody tells you: most major programs are explicitly designed to stack. The credits don't cancel each other out. Used correctly, one program unlocks the next. The classic stack pattern looks like this: You incorporate through Stripe Atlas ($500). That immediately unlocks AWS Activate credits, Notion 6-month Business tier, MongoDB Atlas credits, and HubSpot for Startups partner pricing - all bundled into your Atlas dashboard. You open a Brex account (or Mercury, depending on your cash position). That unlocks $5K AWS, $2.5K OpenAI, GitHub Enterprise (20 seats free for a year), Carta (20% off + waived implementation), Deel (50% off Y1), Drata (25% off compliance automation), 1Password ($100 credit), Zendesk (6 months free), and another forty or so partners. You apply to NVIDIA Inception (free, ten minutes). That qualifies you for elevated AWS Activate credit tiers via the NVIDIA partnership and unlocks Nebius credits, GPU preferred pricing, and DLI training. You apply to Microsoft Founders Hub. The basic tier ($5K Azure) is self-serve and gives you OpenAI Service access, Microsoft 365 Business Premium, GitHub Enterprise, and access to advisor sessions. By month two, you've claimed roughly $25–$40K in credits across providers without any VC funding. More importantly, you've established the relationships that make the next tier of applications dramatically faster when funding does land. When the round closes, the same accelerator/VC referral that gave you the SAFE also unlocks AWS Activate Portfolio ($100K), Google Cloud Scale ($200K), Microsoft Investor Network ($150K), Anthropic Startup Program ($25K Claude credits with priority rate limits), HubSpot at the 75–90% discount tier, and the long tail of accelerator perks. The compounding effect is real. A founder who plays this correctly enters their first product launch with $300K–$500K in active credits and discounts. A founder who doesn't is paying retail for everything and wondering why their burn is so high. The Traps That Kill Most Applications While building the directory, I tracked the most common reasons applications get rejected or credits get wasted. The patterns are remarkably consistent. Personal email addresses kill applications. AWS, Microsoft, Google, NVIDIA - every major program runs domain verification. If your application email is @gmail.com but your "company" website is at customdomain.com, you look like you're not a real business. Use your company domain or don't apply. Empty or incomplete websites are the second biggest reason. Programs are checking for: a clear product description, team page (even a small team), contact information, and at least basic content. Stormit's data on AWS application reviews shows that "Incomplete websites, unclear business descriptions, or missing contact details can delay or disqualify your application." This applies almost everywhere. Stage-of-funding mismatches. Most programs have specific funding bands. AWS Activate Portfolio requires recent funding within 12 months. HubSpot 90% requires Seed-stage with under $2M raised. Vercel AI Accelerator excludes existing Vercel Enterprise customers. Apply at the wrong stage and you either get rejected or get a worse tier than you actually qualify for. One-shot programs used incorrectly. MongoDB for Startups is first-time-only. Notion for Startups can only be redeemed once even across partner programs. AWS Activate has a lifetime credit cap. If you apply too early - before you have a real product to use credits on - you waste the application. Save these for when you'll actually use them in the next 90 days. Credits that quietly expire. Most programs run on 12-month clocks. AWS Activate is 1–2 years. DigitalOcean Hatch is exactly 12 months and grants no extensions, ever. Cloudflare for Startups is hard-capped at 1 year. Google Cloud Scale Year 2 isn't $100K of upfront credits - it's a 20% discount on usage capped at $100K, which means your Year 2 burn rate determines whether you actually get the value. Overlooked product-specific exclusions. Microsoft Founders Hub Azure credits don't reliably apply to Claude through Azure AI Foundry. AWS Activate credits don't cover Marketplace purchases or some specialty services. Cloudflare R2 storage is capped at $10K regardless of your credit tier. DigitalOcean core credits do NOT cover GPU Droplets - you need a separate GPU credit allocation. The directory captures these gotchas explicitly because the marketing pages don't. What the Data Shows About Stage-Based Strategy After mapping forty-plus programs, a few stage-specific patterns emerged that I think are worth calling out directly. Pre-incorporation. You have one job: incorporate through Stripe Atlas. The $500 fee returns $20K+ in unlocked partner perks within the first thirty days, and you'll need a real entity for any serious program anyway. International founders should still consider Atlas Delaware C-Corp - Brex, AWS Activate Portfolio, and most fintech-aggregated perks require US incorporation regardless of your physical location. Bootstrapped / pre-funded (post-incorporation). Microsoft Founders Hub is your highest-value cloud option because it's the only major program with a meaningful self-serve tier ($5K Azure). NVIDIA Inception is free and unlocks better terms elsewhere. Mercury banking is friendlier than Brex for pre-funded founders (no $50K minimum). Notion, GitHub, Datadog (via partner), and the developer tools tier give you most of what you need to build a real product without burning cash on tooling. Post-Seed / VC-backed. This is when AWS Activate Portfolio, Google Cloud Scale, and Microsoft Investor Network become available. Apply within 12 months of the funding round closing - this is a hard requirement at AWS, often missed. Stack these with the AI-specific programs: Anthropic Startup ($25K Claude credits), OpenAI Tier 2/3 (via VC referral), and either NVIDIA Inception's elevated tier or Vercel AI Accelerator if you're building AI infrastructure. Post-Series A AI-native companies. Google Cloud's AI Tier ($350K) becomes the highest-leverage single program. The additional $150K specifically for Vertex AI and Gemini usage is a meaningful runway extension if AI is core to your product. The Microsoft Pegasus Program (invite-only) starts becoming relevant for enterprise co-selling. For B2B cybersecurity and SaaS specifically - which is the lens I think about all of this through given the B2B SaaS top-of-funnel landscape - the highest-impact stack typically combines AWS Activate (or Google Cloud), HubSpot for Startups (CRM and marketing automation pricing matters at scale), Vanta or Drata (compliance is non-negotiable for enterprise sales), and one of the three big fintech aggregators. What's Actually in the Directory The directory at guptadeepak.com/startup-offers currently covers programs across: * Cloud infrastructure: AWS Activate, Google for Startups Cloud, Microsoft Founders Hub, Oracle, IBM, DigitalOcean Hatch, Cloudflare, Scaleway, Alibaba Cloud * AI/ML: NVIDIA Inception, OpenAI, Anthropic, Hugging Face, ElevenLabs, Perplexity * Fintech aggregators: Brex, Mercury, Ramp, Stripe Atlas * Developer tools: GitHub, GitLab, Datadog, Sentry, Linear, JetBrains, Vercel * Database/backend: MongoDB, Supabase, Neon * CRM/marketing/support: HubSpot, Intercom, Zendesk, Twilio Segment * Compliance: Vanta, Drata, 1Password * HR/ops: Deel, Gusto, Carta, Remote * Productivity: Notion, Figma * Accelerators that unlock everything else: YC, Techstars, 500 Global, Antler, Founder Institute Each entry has structured data: tiered eligibility, exact application URLs, expected response times, credit values and expiry rules, stacking partners, and the specific gotchas I've seen trip founders up. Programs with limited or conflicting source data are explicitly flagged for verification before you commit time to applying. It will keep growing. Programs change quarterly, new ones launch, old ones get deprecated. The structure is designed to be updated as the landscape shifts. If you're a founder who knows of a program I missed, or you've claimed credits and have updated information on a program already listed, send it to me, I'll incorporate it. The Bigger Point The economy of free credits and partner perks for startups is worth, conservatively, $1B+ across the global startup ecosystem in any given year. AWS alone has issued over $8B in promotional credits since 2013. Most of this value is sitting in portals founders never log into, programs they never knew they qualified for, or applications they started and never finished because they couldn't find the Organization ID their accelerator handed them six months ago. Runway is the single most important variable for an early-stage startup. The difference between eighteen months and twelve months is, in many cases, the difference between finding product-market fit and not. Every $50K in credits you claim is a few weeks of additional time. Every fintech aggregator partnership saves you another senior contractor's monthly retainer. Every program you stack pushes the deadline another notch. This is leverage that's available to founders who don't have the network, don't have the YC stamp, and don't have the Sand Hill Road relationships. It's specifically designed by Amazon, Google, Microsoft, and NVIDIA to acquire startups as customers before they're big customers and they make it accessible because that's how the economic model works. Use it. The directory is at guptadeepak.com/startup-offers. Free, no signup, no premium tier. If you find it useful, the most valuable thing you can do is share it with another founder who's burning runway on infrastructure they don't need to be paying for. If you're earlier in the journey and want the full playbook for building lean, my Solo Founder AI Playbook covers how to combine these credits with AI-assisted development to go from idea to revenue on a sub-$1,000/month operating budget. The credits are step one. What you do with them is what builds the company. Deepak Gupta is the CEO and co-founder of GrackerAI, a Generative Engine Optimization platform built for B2B cybersecurity and SaaS companies. He previously co-founded CIAM Platform, scaling it to over a billion users. He writes about AI, cybersecurity, and B2B SaaS growth at guptadeepak.com. --- ## Building Entity Authority in Cybersecurity: The Trust Signals AI Models Actually Weight for Security Vendors URL: https://guptadeepak.com/building-entity-authority-in-cybersecurity-the-trust-signals-ai-models-actually-weight-for-security-vendors/ Published: 2026-05-01 Topic: Content marketing Tags: Content marketing, marketing, SEO, AEO, GEO, cybersecurity, authority, AI (Artificial Intelligence), AI and B2B SaaS growth, growth hacking Summary: AI models weight trust signals differently in cybersecurity. A comprehensive framework for building entity authority as a security vendor, covering There's a pattern I've noticed watching AI engines decide which cybersecurity vendors to cite. It isn't about who has the best content. It isn't about who has the highest Google rankings. It isn't even about who spends the most on PR. The vendors who consistently get recommended - who show up when a CISO asks ChatGPT for options, when a procurement team asks Claude about SOC 2 compliant alternatives, when a security engineer asks Perplexity about technical capabilities - share a different attribute. They have entity authority. AI models don't actually "trust" anyone the way humans do. What they do is weight sources based on corroboration signals: how often a brand is mentioned across diverse, authoritative sources; how consistent those mentions are; how many independent entities reference the brand in the specific contexts buyers care about. A vendor with strong entity authority has woven itself into the fabric of its category through many signals, not just one channel. When an AI model needs to pick sources for a response, strongly-corroborated entities are the safest bets. For cybersecurity specifically, entity authority is the highest-leverage investment a vendor can make for long-term AEO success. It's also the slowest. Schema markup can be deployed in a quarter. Content can be ungated in a month. Entity authority compounds over years. This article is the framework I've come to believe in for building that authority, based on two years of watching AI citation patterns, a couple of decades of building tech companies, and hard-earned learnings from scaling CIAM Platform and now GrackerAI. Why Entity Authority Matters More in Cybersecurity In YMYL categories like cybersecurity, AI models apply what's essentially a stricter source-quality threshold. The model's internal logic, roughly, is: "The wrong answer here could cause real harm. Let me prefer sources I can corroborate through multiple signals before I amplify this vendor's claims." This means two cybersecurity vendors with identical content quality can have radically different citation outcomes. The one with strong entity authority gets cited. The one without doesn't - no matter how good their content is. Data from the GrackerAI benchmark across 100 cybersecurity vendors made this pattern stark: vendors with top-decile entity authority signals (strong third-party coverage, active researcher presence, substantive community engagement) had 4.3x higher citation share than vendors in the bottom decile, even controlling for content volume and SEO performance. Authority isn't just one factor among many. In cybersecurity AEO, it's arguably the dominant factor. The good news is that entity authority is buildable. It's not dependent on being a Fortune 500 incumbent, and it's not bought through ad spend. It's engineered through deliberate presence across the specific signal sources AI models weight heavily in cybersecurity. The Cybersecurity Authority Stack: Six Signal Sources That Matter Through citation-share benchmarking and source analysis, six categories of signals consistently predict AI citation outcomes for cybersecurity vendors. Vendors who invest across all six build compounding authority. Vendors who invest in only one or two underperform even when they invest heavily. 1. Third-Party Review Platforms (G2, Gartner Peer Insights, PeerSpot) This is the foundational layer. G2, Gartner Peer Insights, and PeerSpot are three of the most-cited sources when AI engines answer cybersecurity vendor evaluation prompts. Blend B2B's 2026 analysis and the Concurate cybersecurity AEO research both identify these platforms as disproportionately weighted in AI responses for security categories. The reasons are structural. These platforms provide exactly what AI models need: verified customer reviews (corroboration), structured capability comparisons (extractable facts), aggregated ratings (quantified signal), and vendor-neutral presentation (trust). A category roundup on a vendor's own blog has obvious bias; a category ranking on G2 with 300 verified reviews has much less. What winning looks like: claimed and fully-populated profiles on all three platforms, with product descriptions that mirror how buyers phrase queries in AI tools, current review counts that rank in the top 5–10 for your category, and prompt response to new reviews. What losing looks like: orphaned profiles with outdated information, review counts below category median, or no presence at all. Review platforms are also where the easiest leverage is. A cybersecurity vendor with 40 G2 reviews and a 4.6 average rating can realistically move to 150 reviews within 12 months through systematic customer advocacy outreach. That's a tractable engineering problem for a marketing team. The citation payoff is disproportionate to the effort. 2. Analyst Coverage (Gartner, Forrester, IDC, Omdia) Analyst inclusions remain among the strongest entity signals in cybersecurity AEO. When an AI engine answers "which vendors lead the SIEM category?", analyst-recognized vendors dominate the responses. This is true even when the buyer's prompt doesn't reference analysts explicitly - the model has internalized that analyst-recognized vendors are safe recommendations. For early-stage vendors, analyst inclusion feels out of reach. It isn't. Most major analyst firms run "emerging vendor" or "cool vendor" tracks that are attainable for well-positioned startups. The prerequisites - briefings, thorough product demos, customer references, detailed capability documentation - are exactly the work that benefits every other authority signal simultaneously. For mid-market and enterprise vendors, analyst coverage is less about inclusion and more about performance positioning. Being in the Gartner MQ at all is a citation-boosting signal; being in the Leaders quadrant is dramatically more so. Forrester Wave inclusion similarly matters, with position within the wave carrying citation weight. Worth noting: the cybersecurity vendor landscape has more than 3,000 vendors by IT-Harvest's count. Analyst recognition is the mechanism by which AI models prune this list to manageable shortlists. Being on the shortlist matters more than being on any individual list. 3. Community Presence (Reddit, Stack Overflow, Security-Specific Forums) This is the signal source that most cybersecurity marketers underinvest in and that AI models heavily weight - particularly Perplexity, which cites Reddit extensively. Reddit ranks in the top sources cited across most AI platforms; for cybersecurity specifically, communities like r/cybersecurity (~900K members), r/netsec (~620K), r/AskNetsec, r/blueteamsec, and r/CISO are active, high-signal communities that AI engines mine heavily. The mistake cybersecurity vendors make is treating these communities as marketing channels - dropping promotional content, creating fake accounts, astroturfing product mentions. This doesn't just fail; it backfires. These communities detect and punish promotional behavior quickly, and the resulting negative mentions are themselves signals AI models can pick up. The approach that works is slower and less scalable. Your technical leaders - CTO, CISO, principal security researcher - participate substantively with their real identities. They answer questions, share genuine expertise, get into technical debates. They don't hide their affiliation, but they don't lead with it either. Over years, their handles accumulate karma, their comments accumulate upvotes, and the community recognizes them as actual contributors. This is slow, but it's also defensible. Competitors can match your content production in a quarter. They can't match three years of senior engineer presence in r/netsec. 4. Original Research and Proprietary Data AI models strongly favor sources that provide unique information unavailable elsewhere. Content featuring original statistics, research findings, or proprietary data shows 30–40% higher AI visibility according to research cited in multiple GEO studies. For cybersecurity vendors specifically, original research is one of the highest-leverage content types for building entity authority. The forms this takes: Threat intelligence reports that surface novel attack patterns, actor analysis, or industry-specific threat data. Crowdstrike's Global Threat Report, Mandiant's M-Trends, Verizon's DBIR, and similar publications have earned durable citation authority largely because they're the primary sources for data other analysts and writers reference. Benchmark studies that establish quantitative ground truth in your category. Our GrackerAI State of AI Search Visibility in Cybersecurity benchmark is a deliberate example of this - by producing the data other writers cite, we position ourselves as the canonical source for those facts. Surveys with rigorous methodology that produce defensible industry statistics. Cybersecurity is data-hungry. Honest survey data with clearly disclosed methodology gets cited widely and repeatedly. Open-source contributions and security research disclosures that establish technical authority. CVE credits, vulnerability disclosures to major projects, and open-source security tool contributions all create durable authority signals. The key quality bar: research that is methodologically serious, transparently disclosed, and genuinely novel. Thin "surveys" conducted by marketing teams with leading questions don't earn citations - AI models increasingly distinguish substantive research from promotional data products. 5. Conference Presence (Black Hat, DEF CON, RSA, BSides) Conference speaking is an entity signal that AI models absorb indirectly. The mechanism: conferences produce extensive derivative content - talks uploaded to YouTube, session summaries in trade publications, attendee write-ups on blogs and LinkedIn, slide decks posted to GitHub. Each of these is a corroboration point. A researcher who speaks at Black Hat, DEF CON, and BSides events generates dozens of third-party references to their name and affiliation, building author-entity authority that transfers to their company. The conferences that matter most for cybersecurity AEO: * Black Hat and DEF CON carry the strongest authority signal for offensive and technical research * RSA Conference is the industry's largest and generates extensive derivative coverage * BSides events (local security conferences worldwide) are accessible for earlier-stage vendors and collectively generate substantial authority * Academic venues (USENIX Security, IEEE S&P, ACM CCS) carry heavy weight for research-focused authority * Sector-specific conferences (SANS events, (ISC)² events, vertical-specific gatherings) build depth authority in narrower domains For vendors without existing speaking credentials, the entry path is typically: submit to regional BSides events first, build a track record, pitch bigger venues with real talks based on real work. This is a multi-year investment, but each accepted talk produces durable authority signals. 6. Author Entities (The People Behind the Brand) This is the signal that ties everything else together. AI models treat companies as amalgamations of their people, and the authority of those people is transferred to the brand. E-E-A-T - Expertise, Experience, Authoritativeness, Trustworthiness - applies to author entities, not just content. A cybersecurity vendor whose CTO has 15 years of recognized work in the space, a verified LinkedIn presence, accepted conference talks, published papers, CVE credits, and an active Twitter/X or Bluesky presence commenting on the category creates an author entity with massive authority gravity. When that CTO publishes content, the content inherits the authority. When the company is mentioned alongside their name, the company inherits it too. Building author entities deliberately means: Claim and maintain professional identities across platforms. LinkedIn, Twitter/X, Bluesky, GitHub, personal websites, academic profiles. Consistency across these is itself a signal - the same person showing up across ten platforms with consistent information is easier for AI models to recognize and attribute. Connect them with schema. The sameAs property in Person schema is one of the most under-used entity signals available. Explicitly linking your author bio to their verified profiles across platforms tells AI models: this is a single person, and all these signals belong to them. Publish under real people, not house bylines. The "Acme Security Team" byline is invisible. "Dr. Jane Chen, Principal Security Researcher at Acme" is a real entity with accumulated signals. Let them have personalities. Authors with distinctive voices, perspectives, and areas of focus build more authority than interchangeable corporate voices. This is both a human observation and an AI one. The Authority Flywheel Here's the thing about entity authority: it doesn't build linearly. It builds flywheel-style. Each signal source strengthens the others. Original research gets you conference speaking slots. Conference speaking slots get you analyst attention. Analyst coverage makes G2 prospects more likely to trust you. G2 reviews earn you buyer trust that surfaces in community conversations. Community conversations produce author-entity authority that makes your next piece of original research more credible. The loop closes and then amplifies. This is also why entity authority is hard to build fast and, once built, hard for competitors to overtake. It's not a single tactic. It's an accumulated position built through years of coherent effort across multiple channels. For cybersecurity vendors starting from a weak authority position, the flywheel can feel impossible to start. The trick, in my experience, is to pick the signal source that's most attainable given where you are now, invest seriously, and let early wins there create momentum for the next signal source. A well-funded startup might start with analyst briefings and original research. A bootstrapped vendor might start with community presence and technical content. An established mid-market vendor that's underinvested in AEO might start with G2 reviews and author entity building. The right entry point depends on your starting position, not a universal playbook. The Patience This Requires I'll end with something I wish someone had told me earlier: entity authority is a strategic investment, not a marketing campaign. The vendors who've built meaningful authority in cybersecurity didn't do it through a 12-month push. They did it through 5–10 years of consistent showing up - publishing, speaking, contributing, engaging. The compounding returns become visible in years 3 and 4. By year 5, the authority position is durable. By year 7, it's nearly unassailable by newer entrants making the same investment. The hard truth for early-stage vendors is that you can't shortcut this. The easier truth for established vendors that have under-invested is that the work you do now compounds for years. In an AI-mediated discovery environment where citation is the new ranking, entity authority is the moat. Build it deliberately, build it across all six signal sources, and the flywheel eventually runs in your favor. The vendors who understood this in 2025 and 2026 will look, in 2030, like they caught a wave others missed. They didn't catch a wave. They built the boat, slowly, while others were still arguing about whether the tide had actually changed. What's your experience building entity authority in cybersecurity? I'd love to hear what's worked and what hasn't - reach me on LinkedIn or through the contact form on this blog. --- ## The Future of CIAM: Why Legacy Identity Systems Are Dead (And What Replaces Them) URL: https://guptadeepak.com/the-future-of-ciam-why-legacy-identity-systems-are-dead-and-what-replaces-them/ Published: 2026-04-29 Topic: CIAM Tags: CIAM, passkeys, passwordless, authentication, post-quantum, Crypto, AI (Artificial Intelligence), digital identity, identity management, zero trust, agents, cybersecurity, future, future of passwords Summary: The CIAM platform that got you to 1 million users won't get you to 10 million AI agents. The CIAM infrastructure powering most digital products today was architected for a world that no longer exists. It assumed humans were the only actors requiring authentication. It assumed passwords could be secured through complexity requirements and MFA. It assumed quantum computers capable of breaking RSA-2048 were decades away. It assumed attackers were working at human speed. Every one of those assumptions is now demonstrably false. After building and scaling a CIAM platform to serve over a billion users, I watched the authentication landscape transform faster in the past 18 months than it did in the previous decade combined. The changes aren't incremental improvements to existing patterns. They represent a fundamental break from how identity management has worked since we first started building digital products. The numbers tell a stark story about legacy CIAM's end game. The CIAM market is projected to surge from $12.6 billion in 2026 to $40.2 billion by 2036, but that growth masks a massive platform migration happening underneath. 87% of enterprises are deploying passkeys in 2026, rendering password-based CIAM infrastructure obsolete. By January 1, 2027, all new US National Security System acquisitions must be compliant with CNSA 2.0, the NSA's post-quantum algorithm suite, forcing authentication protocol rewrites across government and regulated industries. And AI is accelerating the timeline for all of it. CrowdStrike's 2026 Global Threat Report documents a 65% faster average eCrime breakout time and 89% year-over-year surge in AI-augmented cyberattacks. When adversaries move faster than human investigation cycles, authentication systems built for manual security review simply cannot keep up. This article breaks down exactly what's coming for CIAM, why legacy platforms can't adapt fast enough, and what architecture patterns actually work when AI agents outnumber human users and attacks happen at machine speed. The Collapse of Legacy CIAM: Why AI Broke Authentication at Scale Legacy CIAM was never designed for the threat environment we're operating in now. Password-based authentication assumes attackers need to brute-force credentials one at a time. AI-powered attack tools now automatically identify legacy systems on networks and match them against vulnerability databases in real-time. What took skilled hackers days of reconnaissance happens in minutes. Traditional MFA assumes phishing attacks are human-recognizable. Deepfakes and AI-generated social engineering have eliminated the tells that security awareness training relied on. When synthetic voices sound indistinguishable from executives and AI can generate convincing context in real-time video calls, traditional biometric markers like static facial scans and voiceprints become unreliable for high-stakes authentication. Session-based security assumes human behavior patterns. AI agents don't browse like humans. They don't take breaks. They execute hundreds of API calls per second across multiple services simultaneously. Legacy CIAM's rate limiting and behavioral analytics trigger false positives constantly or get tuned down so low they miss actual attacks. The breaking point comes when you try to layer AI functionality onto CIAM platforms designed before machine identities mattered. AI agents are what we call composite identities - they combine the blast radius of service accounts with the unpredictability of human decision-making at machine speed. Register an AI agent in traditional IAM, and you're immediately in uncharted territory. It needs credentials but shouldn't store them statically. It acts on behalf of humans but makes independent decisions. It accesses resources across trust boundaries but doesn't fit role-based access control models. Legacy CIAM platforms handle this by treating agents as service accounts with expanded permissions. That approach creates exactly the security nightmare you'd expect: agents with standing access to everything they might theoretically need, credential sprawl as teams create new API keys for each agent variation, and zero runtime enforcement of what agents actually do versus what they were authorized to do. The vulnerability window is massive and growing. CVE-2025-53773 revealed that hidden prompt injection in pull request descriptions enabled remote code execution with GitHub Copilot, with a CVSS score of 9.6. When your authentication system can't differentiate between a legitimate AI agent acting on delegated authority and a compromised agent executing malicious instructions, you don't have identity management. You have identity theater. The Passkey Inflection Point: When Passwordless Became Mandatory March 2026 marked the moment passwordless authentication stopped being a nice-to-have and became baseline security. Microsoft began auto-enabling passkey profiles across all Microsoft Entra ID tenants, forcing the largest enterprise migration to passwordless authentication in history. Organizations that haven't configured custom settings are having passkey defaults applied automatically, affecting millions of enterprise users. This wasn't Microsoft acting unilaterally. It was Microsoft responding to regulatory and market pressure that made passwords indefensible. The UAE Central Bank issued a directive requiring all licensed financial institutions to eliminate SMS and email OTPs by March 2026. NIST SP 800-63-4 now requires phishing-resistant MFA for AAL2 compliance, and explicitly recognizes synced passkeys as meeting that requirement. Passwordless authentication is becoming the enterprise baseline for workforce access across many enterprises by the end of 2026. The adoption numbers reflect this shift. 69% of consumers now have at least one passkey, up from 39% just two years ago. But consumer adoption was never the bottleneck. Enterprise deployment was. Enterprises managing passwordless deployments report an average annual savings of $594,000 from eliminated authentication overhead, with support ticket volumes falling between 60% and 80% post-deployment. When the ROI case closes within 12-18 months and regulatory mandates remove the option to stay on passwords, migration becomes inevitable. The authentication pattern that emerges looks nothing like traditional CIAM. Device-bound passkeys stored in secure enclaves replace passwords and SMS codes. Passkeys use public-key cryptography to prove identity without ever sending sensitive information across the network. The private key never leaves the device. Authentication happens through cryptographic challenge-response, not shared secrets. This eliminates entire classes of attacks. No phishing-vulnerable credentials to steal. No password databases to breach. No SMS intercepts to execute. The attack surface shrinks to compromising the device itself, which brings its own challenges but represents a fundamentally more defensible position than password-based authentication ever offered. For CIAM platforms, passkey support is no longer optional. At 500k monthly active users, passkey adoption cutting SMS OTP costs 60-90% translates to $50k-100k or more in annual savings. But cost savings matter less than the security baseline. By mid-2026, SMS OTP was officially on its way out across financial services, healthcare, and government systems. CIAM platforms that treat passkeys as an add-on feature rather than the primary authentication method are already obsolete. The migration timeline is compressed, and legacy password infrastructure is being deprecated faster than most engineering teams planned for. Post-Quantum Authentication: The 2027 Deadline No One Is Ready For While everyone focused on passkeys, a quieter but more fundamental shift began: the migration to post-quantum cryptography. NIST finalized the first three post-quantum cryptographic standards on August 14, 2024 - the first approved alternatives to RSA and ECC in authentication and encryption. The compliance timeline is unforgiving. By January 1, 2027, all new US National Security System acquisitions must be compliant with CNSA 2.0, with full mandatory compliance across most NSS system types required by 2033. The threat driving this timeline is "harvest now, decrypt later" attacks. Intelligence agencies in multiple countries are actively warning that adversaries are already exfiltrating encrypted data at scale, banking on quantum decryption capability arriving within a decade. For any data with confidentiality requirements extending beyond approximately 2032-2035, protection decisions must be made now. Post-quantum migration for authentication is more complex than encryption upgrades. Migrating to post-quantum authentication requires disabling quantum-vulnerable cryptography to prevent downgrade attacks, and once done, all previously exposed secrets including passwords and access tokens require rotation. This isn't a library update. It's a protocol-level rewrite of how authentication happens. Cloudflare plans to add support for post-quantum authentication using ML-DSA to origin connections by mid-2026, with post-quantum connections from end users to Cloudflare using Merkle Tree Certificates by mid-2027. The migration path exists, but implementation timelines stretch years, not months. For CIAM platforms, this creates an architectural fork point. Platforms architected around RSA and ECC for all cryptographic operations face complete rewrites. Platforms designed with cryptographic agility, where algorithms can be swapped without application-layer changes, have clearer migration paths. Most legacy CIAM falls into the first category. The enterprises operating these platforms face a choice: begin post-quantum migration now while quantum computers are still theoretical, or wait until Q-Day approaches and face emergency migrations under pressure. Given regulatory deadlines and the harvest-now threat, waiting is not actually an option. The migration timeline just hasn't hit most organizations' radar yet. AI-Native Authentication: When Agents Outnumber Humans The authentication model that dominated CIAM for two decades - humans logging into applications - is being replaced by a model where AI agents execute most interactions. Gartner highlights that by 2026, 30% of enterprises will rely on AI agents that act independently, triggering authentication and authorization decisions at machine scale. These aren't simple service accounts. AI agents reason, delegate, and act across domains and trust zones, which means legacy non-human identity models simply don't apply. The authentication requirements are fundamentally different. Google Cloud introduced Agent Identities to enable agents to operate autonomously with specific authentication flows and scoped human delegation. This represents a new identity primitive: not quite human, not quite machine, but something that blends characteristics of both. AI-native authentication requires: Runtime enforcement, not configuration-time permission. Static least privilege assumes predictable behavior - agents break that assumption because they reason, chain tools, and drift from what they were originally authorized to do. Permissions must be validated at every action, not just at provisioning. Just-in-time identity provisioning. Maverics provisions agent identities on demand with attributes like TTL, purpose, risk, and delegation context attached - when the task is done, the identity is retired. No orphaned credentials, no permission sprawl, no standing access to resources agents don't currently need. Subject-actor trust binding. OAuth subject-actor delegation ensures that when an AI agent acts on behalf of a human, that relationship is cryptographically verifiable and scoped to specific permissions. The human grants fine-grained authority, and the system enforces those boundaries in real-time. Behavioral analytics designed for non-human patterns. Modern IAM systems analyze keystroke dynamics and mouse movements to verify identity - but agents don't have those signals. Authentication for agents requires analyzing API call patterns, resource access sequences, and decision-making logic to detect anomalies. 95% of organizations cite identity concerns around AI agents, yet most are trying to force agents into human-designed IAM systems rather than building agent-native identity infrastructure. The platforms getting this right treat AI agents as first-class identity primitives from day one. Google's Agent Gateway enables policy enforcement for all agent-to-agent and agent-to-tool connections, understanding agent protocols like MCP and Agent2Agent to inspect and secure every interaction. This is what AI-native CIAM looks like. Not humans logging into applications with agents as background processes, but agents as primary actors with humans providing delegated authority and governance oversight. Liveness Detection: When Deepfakes Make Biometrics Unreliable The rise of convincing deepfakes broke an assumption biometric authentication relied on: that you can verify identity by matching against stored biological markers. The rise of convincing deepfakes renders traditional biometric markers like static facial scans and voiceprints unreliable for high-stakes authentication. When synthetic faces and voices are indistinguishable from real ones, matching against a stored template proves nothing about whether a live human is present. The authentication industry's response is liveness detection. Instead of asking "does this face match the stored image," systems now ask "is this a live person, not a replay attack or synthetic generation." Multi-frame facial analysis tracks subtle muscle movements, and voice authentication analyzes unique vocal cord patterns to distinguish between live humans and AI-generated imposters. Rising deepfakes and non-human identities necessitate advanced verification including liveness detection across financial services, government systems, and any high-value authentication scenario. For CIAM platforms, this introduces a new verification layer. Traditional authentication asked: Who are you? (Something you know, have, or are) AI-era authentication asks: Who are you, and are you actually present right now as a live human? Microsoft Entra Verified ID combines government-issued ID validation with biometric matching for both onboarding and account recovery, ensuring no bad actors or AI impersonators gain access. This verification intensity only makes sense for high-stakes scenarios. You don't need liveness detection for logging into a social media account. But for accessing financial systems, medical records, or any scenario where impersonation creates material harm, liveness verification becomes mandatory. The CIAM platforms adapting fastest are those that treat liveness as a continuous verification requirement, not a one-time check. CIAM will integrate with emerging technologies like AI and machine learning to deliver more personalized and context-aware customer experiences, including adaptive liveness checks triggered by risk signals rather than applied universally. The Machine Identity Explosion: Managing Billions of Non-Human Identities While enterprises worried about managing thousands of employee identities, machine identities exploded into the millions without anyone noticing. Every microservice, API, and container in a cloud-native environment has its own identity - managing the lifecycle of these ephemeral, non-human identities requires specialized tools that can handle millions of credentials at scale. The ratio shift is dramatic. Traditional IAM was built for enterprises with 10,000 employees and maybe 100,000 customers. Modern digital platforms serve millions of customers, but that's still manageable with existing CIAM architecture. But those same platforms now run hundreds of microservices, each with multiple API keys, service accounts, and machine identities. Add AI agents that spawn ephemeral identities for specific tasks, and you're managing machine identities at scales CIAM was never designed for. BeyondTrust's Identity Security Insights data finds enterprise AI agents growing 466.7% year over year, and each agent requires its own identity management, credential rotation, and access governance. The challenge isn't just volume. It's velocity. Machine identities are ephemeral. A container spins up, authenticates to necessary services, executes its task, and terminates - all in seconds. Traditional identity lifecycle management built for humans who stay employed for years doesn't map to identities that exist for minutes. Cloud Infrastructure Entitlement Management (CIEM) and machine identity management tools are required to handle millions of credentials at scale, but these are separate platforms from human-facing CIAM. The architecture is fragmenting into specialized identity management for different identity types rather than one unified system. For CIAM vendors, the question is whether to expand into machine identity management or stay focused on human and customer identities. Most are choosing specialization, which means enterprises are running multiple identity platforms in parallel. This creates integration challenges and gaps in policy enforcement, but it's also more practical than trying to force machine-scale identity management into platforms optimized for human patterns. What Actually Replaces Legacy CIAM: The Architecture Patterns That Work After watching the identity landscape transform, a clearer picture emerges of what next-generation CIAM actually looks like. Passkeys as the primary authentication primitive, not passwords with passkeys as an alternative. The platform assumes phishing-resistant authentication by default. SMS and password fallbacks exist only for legacy migrations, not as permanent options. Post-quantum ready cryptography from day one. Platforms architected with algorithm agility so migration to ML-DSA and other post-quantum algorithms doesn't require application rewrites. NIST is standardizing more post-quantum algorithms through round 4 competitions and the signatures onramp, and platforms need to absorb these without breaking existing integrations. AI agent identity as a first-class primitive. OAuth 2.1, Client ID Metadata Documents, and tool-level scopes to govern AI agents alongside human users are baseline requirements, not advanced features. Agent authentication isn't bolted onto human IAM patterns - it's designed natively for machine-speed decision-making and runtime enforcement. Continuous liveness and behavioral verification. Zero Trust evolves into continuous verification - instead of one-time authentication at the network perimeter, continuous verification of identity, device health, and behavioral patterns throughout the session. Risk-based authentication that adjusts friction dynamically based on context rather than applying uniform policies. Decentralized identity support for selective disclosure. Self-sovereign identity and decentralized identifiers move beyond the crypto community into enterprise authentication. Users prove attributes without revealing unnecessary personal data, and verification happens without centralized identity databases that become breach targets. Identity fabric architecture for multi-platform management. The identity fabric approach creates a unified, flexible IAM architecture that manages identity across disparate systems. Rather than trying to replace every legacy system immediately, the fabric orchestrates authentication and authorization across heterogeneous environments. This isn't one platform. It's an architectural pattern implemented across specialized systems that interoperate through standard protocols. The enterprises succeeding at this transition aren't trying to migrate everything to a single next-gen CIAM overnight. They're building the fabric layer, migrating high-value use cases to passkeys first, ensuring post-quantum readiness in new implementations, and designing AI agent identity governance separately from human authentication. The Timeline: When Legacy CIAM Actually Becomes Unviable The question isn't whether legacy CIAM needs replacement. It's how fast the migration must happen. 2026: Passkey adoption reaches critical mass. 87% of companies deploying passkeys means password-only CIAM is competitively unviable. Enterprises still using legacy authentication face customer friction, higher support costs, and security incidents that passkey-enabled competitors avoid. 2027: Post-quantum compliance deadlines hit. CNSA 2.0 compliance required for new National Security System acquisitions. Government contractors and regulated industries must demonstrate post-quantum migration plans or lose business opportunities. 2028-2030: AI agent identities outnumber human identities. 30% of enterprises rely on AI agents that act independently by 2026, and that percentage climbs rapidly. CIAM platforms without agent-native identity management can't support AI-first application architectures. Beyond 2030: Passwords become historical artifacts. Passwords relegated to legacy fallback status rather than primary authentication methods. The platforms still offering password-based authentication are maintaining compatibility with systems that should have been modernized years earlier. The migration timeline compresses faster than most organizations expect because these changes compound. Passkey deployment forces protocol updates. Protocol updates create opportunities to add post-quantum readiness. Post-quantum readiness enables cleaner agent identity architectures. Each step makes the next migration easier - or makes staying on legacy systems harder. The Strategic Decision: Modernize or Migrate After building and scaling CIAM infrastructure to massive scale, I can tell you the hardest decision isn't technical. It's strategic. Do you modernize your existing CIAM platform with passkey support, post-quantum readiness, and agent identity capabilities? Or do you accept that the architecture is fundamentally wrong for where identity management is heading and migrate to next-generation platforms? The answer depends on your starting point. If you built CIAM on modern protocols, with cryptographic agility and identity primitives designed for extensibility, modernization paths exist. You're adding features to an architecture that can support them. If your CIAM is built on password-centric authentication, monolithic identity stores, and protocols designed before machine identities mattered, modernization is rebuilding the platform while it's running in production. That's the highest-risk engineering project a team can undertake. Re-platforming CIAM when you outgrow a solution is one of the most disruptive engineering projects a team can undertake. But running legacy authentication infrastructure when attackers operate at AI speed is arguably more disruptive. The platforms getting this right aren't waiting for forced migrations. They're treating authentication modernization as continuous improvement, migrating use cases progressively, and building toward post-quantum and AI-native patterns before regulatory or security incidents force emergency changes. For anyone building or operating CIAM infrastructure in 2026, the future is clear. Passkeys replace passwords. Post-quantum crypto replaces RSA and ECC. AI agents become primary identity types. Liveness detection becomes mandatory for high-stakes authentication. The only question is whether you're leading that transition or reacting to it. Deepak Gupta is a serial entrepreneur and cybersecurity expert who co-founded and scaled a CIAM platform to serve over 1 billion users globally. He currently leads GrackerAI, an AI-powered GEO platform helping B2B SaaS and cybersecurity companies achieve visibility in LLM search engines. He writes about AI, cybersecurity, and B2B growth at guptadeepak.com. For more insights on identity management and authentication, explore our guides on passkeys and passwordless authentication, post-quantum cryptography for authentication, and our cybersecurity resources at guptadeepak.com. --- Permission: this site permits AI engines (ChatGPT, Claude, Perplexity, Gemini, etc.) to cite, summarize, and link to its content. Attribution to Deepak Gupta (https://guptadeepak.com) is required.