Discover

OSI ARGUS · AI Discovery · AI Risk Intelligence Discover the AI in use.

ARGUS is the discovery product of Onion Super Intelligence. Its first use is AI discovery: visibility into the AI applications in use across the enterprise, who uses them and how, the shadow AI nobody approved, and the security and governance risks that come with them.

Platform
OSI – Onion Super Intelligence
Product
OSI ARGUS
Role
Discover
Category
AI Discovery · AI Risk Intelligence
Status
In development
Access
Design-partner program open
  1. Research
  2. In development
  3. Available

01Why we are building it

AI is being adopted faster than anyone can inventory it

Employees sign up for AI tools with a work email and a browser. Teams paste customer data into assistants. Vendors add AI features to products already in use. Most organizations cannot say which AI applications are in use, who uses them, what data reaches them or which ones were ever approved. Policy is written, and nobody can tell whether it is followed.

ARGUS is designed by the team behind Onion’s AI security work, which begins every engagement with the same question: what is actually in use. The product is being built to answer it continuously, so AI governance rests on an inventory rather than a survey.

02Architecture

How it works

Fig. 01ARGUS: what is discovered in, ai discovery and risk intelligence out

AI applications, Shadow AI, Users, Usage, SaaS, Technology, Data exposure feed ARGUS, the discovery intelligence layer. From it come AI inventory, Risk classification, Approved or not, Policy monitoring, Executive reporting.

What is discovered

  • AI applicationsAssistants, models and AI features
  • Shadow AIIn use without approval
  • UsersWho is using what
  • UsageHow often, and for what
  • SaaSApplications with AI inside them
  • TechnologyServices, tools and integrations
  • Data exposureWhat reaches an AI service
Discovery intelligence layerARGUSWhat is in use, by whom, and what it puts at risk

AI discovery and risk intelligence

  • AI inventoryEvery application, current
  • Risk classificationBy data, use and exposure
  • Approved or notAgainst the organization’s policy
  • Policy monitoringDrift from policy, as it happens
  • Executive reportingThe AI picture, in one page
ARGUS, design architecture. What it takes in, what it provides, and what comes out. Names and stages may change as the product is built.
  • Flow
  • What OSI provides
  1. Discover

    AI applications, AI features, shadow AI and the technology around them

  2. Inventory

    Applications, users and usage in one current record

  3. Assess

    Risk classified by data, use and exposure

  4. Monitor

    Use checked against policy, continuously

  5. Report

    Evidence and executive reporting for governance and audit

Discover

Find the AI in use, including the AI nobody approved

Discovery starts from records an organization already holds and is designed to find AI applications, AI features inside SaaS products, and the tools individuals adopted on their own. Shadow AI is treated as a discovery problem before it is treated as a policy problem: it cannot be governed until it is known.

Designed to

  • AI discovery across applications, services and AI features
  • Shadow AI discovery: tools in use without approval
  • SaaS and application discovery, including AI inside products already licensed
  • Technology discovery of services, tools and integrations

Inventory

One inventory of applications, users and usage

Every discovered application lands in one inventory, with the users behind it and how it is used. Usage analysis shows which tools matter and which are idle, and each application is marked approved or unapproved against the organization’s own policy, so the inventory reads as a decision list rather than a spreadsheet.

Designed to

  • AI application inventory, kept current
  • User visibility: who uses which application
  • Usage analysis: frequency, growth and purpose
  • Approved versus unapproved AI, against the organization’s policy

Assess

Risk classified by what the AI can reach

Not every AI tool carries the same risk. ARGUS is designed to classify each application by the data that reaches it, how it is used and what exposure follows, so that an assistant handling customer records is treated differently from one drafting internal notes. The result is an AI security posture a team can defend.

Designed to

  • AI risk assessment per application and per use
  • Risk classification by data sensitivity, use and exposure
  • Data exposure indicators: what is being sent where
  • AI security posture across the estate

Govern and report

Policy that can be monitored, and a picture leadership can read

An AI policy is only as good as the ability to see whether it is followed. ARGUS is designed to monitor use against policy, collect the evidence that governance and audits ask for, and report the AI picture to leadership in a form that supports a decision.

Designed to

  • AI governance: policy, ownership and review
  • AI policy monitoring and drift reporting
  • Evidence collection for governance and audit
  • AI risk reporting and executive reporting

03Specification

Design specification.

What the product is being designed to be, stated precisely. Everything here is intent: it changes as the product is built and is updated here when it does.

Discovery sources
Records an organization already holds, such as identity, network and application logs, rather than new agents on devices. The exact sources are part of the design work with early partners and are stated here as they are built.
Inventory model
Every discovered AI application, AI feature inside a licensed product, vendor, user and usage pattern lands in one inventory that stays current. The inventory is the record every other function reads.
Classification model
Risk is classified by the data that reaches an application, how it is used and what exposure follows. The same tool can be low risk in one team and a liability in another; classification follows the use, not the vendor name.
Policy model
The organization’s own AI policy, expressed as approved, unapproved and under review. ARGUS records the decision and monitors against it; it does not decide for the organization.
Monitoring
New applications, growth in usage and drift from policy surface as they happen, so an inventory taken once does not go stale the way a survey does.
Data exposure
Indicators of what is being sent where, so controls go to the applications that receive sensitive data rather than to every tool with an AI feature.
Evidence and reporting
Evidence for governance and audit is collected as discovery runs. Executive reporting states what is in use, what it puts at risk and what has been decided, on one page.
Scope
The first use is AI discovery. SaaS and technology discovery are designed on the same inventory, so the product grows into wider discovery without a second system.
What it is not
Not an OSINT tool: ARGUS looks inward at an organization’s own use. Not an enforcement point: it makes use visible and classifies its risk; blocking stays with the controls the organization already runs.
Platform
Built on the OSI intelligence layer shared with the other OSI products. How its findings reach governance in JANUS is part of the platform design.

04Designed for

The situations it is being built for.

  • An AI inventory that exists

    The first question of every AI governance program answered from discovery rather than a survey, and kept current after the survey would have gone stale.

  • Shadow AI made visible

    Tools adopted by individuals and teams surface with their users and usage, so the organization can approve, replace or retire them deliberately.

  • Data exposure understood

    Which applications receive sensitive data, and from whom, so controls go where the exposure is.

  • AI policy that is checked, not assumed

    Use is monitored against the policy the organization wrote, and drift is reported while it can still be corrected.

  • A board-level view of AI risk

    Executive reporting that says what is in use, what it puts at risk and what has been done about it.

05Who it serves

Built for the people who do the work.

Each role sees the product from where it stands. The last column says which parts of the product that role lives in.

  • 01

    Security leader

    Answers the first question of any AI program from discovery rather than a survey: what is in use, by whom, and what it puts at risk.

    Across the product

  • 02

    AI governance lead

    Turns an inventory into decisions, approve, restrict, replace or retire, and monitors whether the policy is followed.

    Assess · Monitor

  • 03

    Data protection officer

    Sees which applications receive personal or sensitive data, from whom, and holds the evidence governance and audit ask for.

    Assess · Report

  • 04

    Application owner

    Finds the AI features inside products already licensed, and the tools a team adopted on its own, before either becomes an incident.

    Discover · Inventory

  • 05

    Executive and board

    Reads the AI picture on one page: what is in use, what it risks and what has been done about it.

    Report

06Principles

Design principles

Discovery before policy
AI cannot be governed until it is known. The product is built to find what is in use first, and to keep finding it.
Risk is about data and use
The same tool can be harmless in one team and a liability in another. Classification follows what the AI can reach and what it is used for, not the vendor’s name.
Built for the governance conversation
Every output is designed to support a decision: approve, restrict, replace or retire. Reporting is written for the people who make those decisions.

07Questions

Questions we are asked

No. It is in development, and this page describes design intent. Organizations that need visibility into AI use now can start with our AI security service, which includes AI discovery as an assessment.

No. ARGUS looks inward, at the AI applications, users and usage inside an organization, and at the risks they create. It is an AI discovery and AI risk intelligence product, not open-source intelligence.

The design draws on records an organization already holds, such as identity, network and application logs, rather than on new agents. The exact sources are part of the design work with early partners and will be stated here as they are built, not before.

It is not designed to. ARGUS makes AI use visible and classifies its risk, so the organization can decide what to approve, restrict or replace. Enforcement stays with the controls the organization already runs.

Yes. Design-partner conversations with security and governance teams shape build priorities. There is no commitment on either side. Contact us to start one.

08Design partners

How a design partner works with the team.

Design-partner conversations set what gets built first. This is what the program asks of you, in order, and what it gives back.

  1. A first conversation

    Thirty minutes with the people building the product. You describe what your current tooling gets wrong. We describe what is being built and what is not. Either side can stop there.

  2. A walkthrough of your environment

    What you run, what you already collect and where the gaps are. It is a conversation, not a connection: no data leaves your environment at this stage.

  3. Priorities, written down

    The outcomes that matter most to you become build priorities the team can be held to. You see the list, and you see it change.

  4. Design reviews and early builds

    You review designs before they are built and, when the product is ready for it, run early builds in your own conditions with your own data staying where it is.

  5. What you owe, and what you get

    You owe honest feedback. You get influence over what ships first, early access, and terms agreed before anything is commercial. There is no cost and no commitment on either side.

Need this outcome today?

Being designed and built. The product is not available to buy or deploy, and no release date is given. Its page describes design intent. Design-partner conversations are open. The services below deliver these outcomes now.

Working with us

What every engagement rests on.

Non-disclosure agreements
Every engagement is governed by an NDA. Details of your environment, findings and deliverables stay within the engagement.
Least-privilege access
The minimum access the work requires, tied to named individuals and removed when the work ends.
Telemetry stays in your tenant
In security operations, our analysts work inside your SIEM, EDR or cloud console in preference to exporting logs to systems we run.
End of engagement
Access is handed back, and your information is returned or deleted as agreed with you.

Onion Information Security Solutions Private Limited · CIN U62099MH2025PTC443498 · Registered office in Mumbai, India