NEW AI & agent attack-surface fingerprinting is live
← Blog

Where are we using AI? Answer it from the outside.

June 10, 2026Resensor5 min read

Cover for the Resensor post 'Where are we using AI?' An AI usage register titled 'AI in use, external' lists five external-facing AI tools, the data each one touches, and a risk rating: a support assistant (customer chats, medium), an LLM API gateway (prompts and PII, high), site search AI (visitor queries, low), a docs Q&A bot (knowledge base and user input, medium), and a lead-gen chatbot (lead PII, high).

Most conversations about AI security start with the wrong question. They ask whether your AI is secure. The harder question, the one a board member or an auditor actually opens with, is simpler and worse: where are you using AI at all? Most organizations cannot answer it.

Our last post was about the AI you expose: the model servers, vector databases, and agent tooling left reachable on your perimeter. This one is about a different gap, the one governance teams are now on the hook for. Not where your AI is exposed, but where your organization uses AI in the first place. Resensor now builds that inventory too, passively, from the same external vantage point an attacker has.

Two questions, not one

There are two AI questions, and they have different owners. The security team owns the exposure question: is any of our AI infrastructure reachable and unprotected. The governance, risk, and compliance side owns the usage question: where are we sending data to AI, and did anyone sign off on it. Both matter. The second one is the one that suddenly has a deadline.

The reason is that the usage question stopped being academic. Regulators, customers, and insurers have all started asking it in writing, and the honest answer at most companies is a shrug.

Why "where are we using AI" became a board question

The EU AI Act, NIST's AI Risk Management Framework, and ISO 42001 are different documents, but they begin from the same place: an inventory of where AI is used. You cannot govern, risk-assess, or attest to a system you have not written down. Customer security questionnaires now ask which AI subprocessors touch their data. Cyber insurers have started asking too.

At most companies the list does not exist, because AI adoption does not run through one door. A marketing team adds an AI chat widget to the site. A product team wires up an LLM provider for a feature. Support switches on an AI agent inside the helpdesk. Each is a reasonable, local decision. Nobody is keeping the master list, and the result is the governance face of shadow AI: prompts, customer records, and source material flowing to AI vendors that never went through review, with no data-processing agreement and no entry on any inventory.

Four signals you can read from the outside

Here is the part that surprises people. You do not need access to anyone's cloud account to start answering the question. A real amount of AI usage is legible from the outside, in DNS, in host names, in page source, and in the one file that states your policy toward AI crawlers. Four signals, each with its own strength and its own blind spot.

  • SaaS providers in your DNS. When a team puts a vanity hostname in front of an AI service, the DNS record points straight at the provider. A CNAME to an Azure OpenAI, Hugging Face, or Vertex AI endpoint is a high-confidence statement that someone is using that service. This signal is precise and quiet. Its blind spot is that most SaaS AI is reached over the provider's own domain with no vanity record, so DNS shows you the deliberate integrations, not every API call.
  • AI in the names. Engineers name things for what they do. copilot., chat., rag., llm-gateway. A host named for an AI workload usually has one running on it. Naming is a hint rather than proof, so it is worth confirming instead of trusting, but it routinely surfaces internal AI projects nobody mentioned in the meeting.
  • Assistants in the page. The AI a company uses with its customers is usually loaded right into the homepage: a support assistant, a chat agent, a help bot. The vendor's loader script sits in the page source for anyone to read. Intercom's Fin, Drift, Ada, and a dozen others each leave a recognizable mark. What this proves is the platform; whether its AI answering is switched on is a question for the team that owns it, and the finding says exactly that rather than pretending to know.
  • Your AI-crawler policy. There is one file that states, in public, how you treat AI: robots.txt. It is where a site decides whether crawlers like GPTBot, ClaudeBot, CCBot, and Google-Extended may use its content for training and answer engines. Most sites have never updated it for any of them, which is itself the finding: your content is open to AI scrapers by default. A growing number of sites also publish an llms.txt to steer what models should reference. Present or absent, the posture is worth knowing before someone asks.

None of these four is the whole picture on its own. Together they turn "we are not sure" into a list with names on it.

From signals to an inventory

Resensor now runs all four passes on every scan and records each result as an entry in an AI usage inventory, sitting next to the exposed-AI-services list from our last release. A SaaS provider reached through your DNS, an AI-named host, an assistant embedded in a page: each becomes a row you can hand to whoever owns AI governance. These are not alarms. They are inventory, ranked as informational, because using AI is not a vulnerability. The point is to answer the question, not to cry wolf about it.

We widened the exposure side in the same release, so the two halves stay in step. Resensor now recognizes more self-hosted AI services, including the newer low-code agent builders, and one of them is exposed in a way that maps to a flaw sitting in CISA's Known Exploited Vulnerabilities catalog, so it surfaces with that exploit context already attached. One screen, two answers: where you use AI, and where that use is exposed. For the exposure half of the picture, see our post on shadow AI infrastructure.

Because teams adopt AI tools continuously, the inventory is rebuilt every scan, not once. A widget added to the marketing site this week, a new AI subdomain that went up for a pilot: they appear the next time we look, which for monitored estates happens on its own.

Do it yourself, or do not

None of this is secret, and that is the point. You can start this afternoon on a single domain. List your subdomains and read the names. Resolve their DNS and look for AI providers in the targets. Open your main pages and search the source for the chat vendors you recognize. Fetch your robots.txt and see whether it names a single AI crawler, then check for an llms.txt. You will learn something. For most companies, the first pass turns up at least one AI tool nobody had written down.

What you cannot easily do by hand is run that across every domain and subdomain you own, every week, and keep the results in one list that does not drift. That is the part we built. The question your board is going to ask is not going away, and it is a much better day when the answer is already sitting in a table than when you are assembling it under a deadline.

See your own AI usage

You are almost certainly using more AI, in more places, than your last inventory shows. Run your external surface through Resensor and get the list: the SaaS providers in your DNS, the AI-named hosts, the assistants embedded in your pages, and where your own crawler policy stands.