Find the AI nobody registered.
Aribot reads your repositories and, if you connect them, your traffic logs. Every AI use it finds gets a provider, a location, a risk level and an owner, so your AI register matches what is running.
The AI you approved is a shorter list than the AI you run
Most organisations keep a register of the AI they have approved. The AI in production is a longer list. A developer adds a hosted model to summarise support tickets. A data team builds a vector database for a search prototype that later becomes the live service. An agent framework arrives as a dependency of a dependency. Somebody puts an AI key in a settings file to get a demo working before a meeting, and the file is committed.
None of this is malicious. AI services are a few lines of code away, so this is how software gets built. The trouble comes later, when someone asks which systems send customer data to an outside model, who owns them and what they cost. A policy document cannot answer that, and a survey of teams answers it from memory. Memory tends to miss the prototype that went live last spring.
Shadow AI discovery in Aribot starts from evidence: your code and, if you connect it, your network traffic. It lists each AI use it finds with the provider, the model where the code names one, the file and line, a risk level and a threat class. You decide what each one is, give it an owner, and keep the list current as new code arrives.
Who uses it
Shadow AI matters to several teams at once, and each needs something different from the same list.
CISO
You are asked which AI the organisation runs and where its data goes, and the answer has to survive an audit. You get an inventory built from code and network evidence, AI keys found in source with the file and line, and threat classes such as data exfiltration and excessive agency, so the items that carry the most risk are the first ones you look at.
AI lead
You want teams to keep building with AI and you want to know what they built. You get a list of the models, vector databases and agent frameworks in use, approval for a whole provider in one step, and a route to bring an unmanaged model under agent governance once it is ready for production.
Compliance lead
Every AI regulation and management standard starts from knowing which AI systems exist. You get that inventory with owners and decisions recorded, gaps shown against the OWASP Top 10 for LLM applications, the EU AI Act and the NIST AI RMF, and an export you can attach to an evidence pack.
Head of platform
You run the repositories, the pipelines and the shared network edge. You get findings tied to the repository and application they belong to, network evidence from the proxy, firewall or DNS logs you already keep, and a scan your engineers can start from their AI assistant.
What it looks for
Discovery recognises the kinds of AI that teams add most often. Besides the four below it also picks up retrieval pipelines, fine-tuning jobs, machine learning pipelines and custom models, each labelled with its service type so you can filter the list.
Model endpoints
Calls to hosted large language model APIs and cloud AI services, including embedding, speech and image services. Where the code names a model, the model is shown. Where it does not, Aribot gives the reason, for example that the model is chosen further along the call or held in a setting outside the captured lines.
Vector databases and retrieval
Vector stores and retrieval pipelines that index your documents for an AI system to search. This is often where customer records and internal files enter an AI system, which is why the sensitive read threat class exists.
Agent frameworks
Libraries that let a model call tools and take actions. The excessive agency threat class covers the risk that matters most here: an agent acting with more permission than its task needs.
AI keys in code
API keys for AI services written into source or configuration files. Each is marked as a hardcoded key with the file and line, so the owner knows exactly what to revoke and rotate.
Five threat classes
Each finding can carry a threat class that says what could go wrong. Data exfiltration is data leaving for an unapproved endpoint or a model provider abroad. Lateral reassembly is a leaked credential or token that lets an attacker move from one service to the next. Excessive agency is an agent acting with permissions nobody limited. Sensitive read is a retrieval or vector index that can reach personal data, keys or other sensitive stores. Tool misuse is a call to an outside model or tool with inputs nobody checked.
Two kinds of evidence
Code
Connect repositories on GitHub, GitLab, Bitbucket or Azure DevOps, or upload a zip or tar archive. A local git repository travels well as a zip. If a scan reads nothing, the page tells you so, which avoids an empty result being read as a clean one.
Network traffic
Upload logs from the tools you already run: a firewall, proxy, SIEM, NDR, CASB, DNS or WAF, in CSV, JSON, Syslog or CEF format. You can also connect a traffic source so evidence keeps arriving. Traffic finds AI that never appears in your own code, such as a browser-based tool staff signed up for themselves.
Each finding is marked with where it came from: code, network, or correlated when both point to the same service. A correlated item is usually the best place to start, because you know both where it lives and that it is in use.
From finding to decision
A new finding starts as unknown. From there you mark it under review, reviewed, approved or not approved. Every decision is saved with the finding. If the save fails you are told and the row is left as it was, so the list never shows a decision that was not recorded.
Give each finding an owner: a team, the application it belongs to and, if you want, the person who will follow it up. Linking a finding to an application puts it beside that application's threat model, which is where anything touching sensitive data should go next.
Most findings come from a few providers. The summary by provider lets you approve or block all findings for one provider in a single decision. A provider you rely on can also be tracked as a vendor, so the supplier review happens where your other suppliers are reviewed.
When an unapproved model is ready to be used properly, bring it under governance. It becomes a governed agent identity whose use and spend are measured. This step needs owner or admin rights.
A first month at Tallowmere Freight
Tallowmere Freight is a fictional logistics company with a customer support assistant it approved last year and a growing number of teams experimenting with AI. All figures here are illustrative.
Week one: the first scan
The head of security connects the company's forty repositories and uploads a week of proxy logs. The first scan lists sixty findings under five providers. Most of them sit in the support assistant's code, which was approved, so the AI lead approves that provider in one decision. Forty findings now have a status. The remaining twenty are what the month is about.
Week two: the riskier items
Filtering by risk puts a critical finding first: an AI key in the settings file of an internal reporting tool. The platform team owns it, revokes the key, moves the secret to their vault and rescans. The finding no longer appears. Next is a vector database in the route planning team's prototype, classed as a sensitive read because it indexes driver records. The routing team becomes the owner, the finding is linked to the route planning application, and it goes under review while they add it to that application's threat model.
Week three: what the code never showed
Network evidence shows two hundred calls a day to a transcription service with no code finding behind it. It turns out the finance team records meetings with a browser tool they found themselves. The compliance lead marks it not approved, records finance as the owner, and opens the conversation about an approved alternative. Without the traffic logs this one would have stayed invisible.
Week four: bring it under governance and report
The support assistant's model is brought under governance. It becomes a governed agent identity, and its use and spend are measured. The compliance lead exports the inventory to CSV for the audit committee, with every item owned and decided. The inventory also tells the company which AI systems its EU AI Act work must cover, and the company books a detailed assessment on Ayurak Trust to put evidence behind its answers.
What you see in Aribot
The page is called Unapproved AI (shadow AI) and sits under AI governance. The same discovery also appears as a tab in Code Security, so engineers and governance owners look at one list from two places. At the top you choose what to scan and see tracked spend for discovered models. Below that:
When something goes wrong
If results fail to load, the page says that nothing could be read and asks you to refresh. It never shows zero findings in that case, because zero would look like a clean bill of health. An empty inventory after a successful scan comes with directions: connect a repository, upload code or add traffic logs.
Your code stays yours
A company admin decides whether code snippets may be sent to an outside AI provider for deeper classification. With that switched off, classification runs inside Aribot and no code leaves your tenant. Results are visible only to your own company.
Where shadow AI fits in Ayurak
Discovery is usually the first technical step after the free AI readiness self-assessment, which covers the organisational side: policies, roles and oversight. Shadow AI covers the technical side, and what it finds carries into the rest of the platform.
- Agent governance takes over when a discovered model is brought under governance: scopes, watch-only and enforce modes, and the actions queue.
- AI audit trail and AI cost record what governed AI did and measure what it spent.
- EU AI Act readiness builds a dossier per AI system. The inventory tells you which systems that work must cover.
- Discovery and remediation follows a finding through to a fix, a ticket and proof that it was closed.
- Ayurak Trust is where the detailed assessment happens, with assessment templates by Aristiun and answers backed by evidence.
How it maps to the standards
Discovery does not make you compliant with anything on its own. It gives you the inventory and the decisions that these standards expect to exist.
Questions people ask
How does this differ from a CASB or a proxy block list?
Those tools see traffic once it leaves the network. Aribot also reads code, so it can find AI built into your own systems with the file and line, including services that have not been deployed yet. The logs from those tools are welcome too: upload them as network evidence and matching items are marked correlated.
Does Aribot send our code to an AI provider to classify it?
Only if a company admin allows it. A setting on the discovery screen decides whether code snippets may go to an outside AI provider for deeper classification. With it switched off, classification runs inside Aribot and no code leaves your tenant.
What happens when the code does not name the model?
The finding still appears under its provider and service type. In place of a model name you see why none was given, for instance that the code only sets up the client there, or that the file talks to several models. A model inferred from elsewhere in the file is marked as likely.
Does marking a finding as not approved stop the AI service?
The status records your decision and who owns the follow-up. To stop the service, the owner changes the system that runs it, revokes the key, or you bring the model under agent governance, where calls pass the gateway checks and can be blocked.
Which repositories and logs can we connect?
Repositories on GitHub, GitLab, Bitbucket and Azure DevOps, or a zip or tar archive of any codebase. Traffic logs in CSV, JSON, Syslog or CEF format from a firewall, proxy, SIEM, NDR, CASB, DNS or WAF tool, or a traffic source connected for ongoing collection.
What is in the export?
The CSV has provider, model or service, service type, threat class, status, risk level and score, whether a key is hardcoded, the file or network location, the line number and the detection date. A JSON download carries the full data.
Can our engineers run a scan from their AI assistant?
Yes. Connect Claude, ChatGPT, Gemini or an IDE to the Aribot MCP server and ask for a shadow AI scan of code already uploaded to Aribot. The tool is called discover_shadow_ai and runs in the background.
Does the page show what this AI is costing us?
It shows measured spend only where a discovered model matches one already under governance, and counts the rest as not tracked yet. No figure is estimated. Bringing a model under governance is how its spend becomes measured.
Do we need Ayurak Trust as well?
No. Shadow AI discovery is part of Aribot. Trust is where a detailed, evidence-backed assessment happens, with Ayurak's team. Existing Trust customers sign in; everyone else can start with the free AI readiness self-assessment and book a call.
Where you will find it once signed in
Demos and related pages
The overview: discovery, agents, audit trail, cost and the EU AI Act.
What happens after a model is brought under governance.
From a finding to a fix, a ticket and proof.
A conformity dossier per AI system.
A record of what AI did, and what it cost.
Use Aribot, including shadow AI scans, from your assistant or IDE.
Start with the free self-assessment. Go deeper with evidence.
- Step 1, free
Answer the AI readiness self-assessment online. You get a view of where you stand against the EU AI Act, the NIST AI RMF and related frameworks, in minutes.
- Step 2, with Ayurak's team
A detailed, evidence-backed assessment on Ayurak Trust: each answer supported by evidence, reviewed with our team, and reported in a form you can hand to a board or an auditor.
Start with what you can see
Connect a repository or upload a week of proxy logs and you will have a first inventory the same day. The free AI readiness self-assessment covers the organisational questions alongside it.
