Talk to an expert

Protect

OSI AEGIS · Extended Detection & Response Protect across every layer.

AEGIS is the XDR product of Onion Super Intelligence. It is designed to unify security telemetry across endpoint, identity, cloud and network environments, so that security teams detect, correlate, investigate, hunt and respond to threats from a single security intelligence layer instead of a row of consoles.

Become a design partnerSee the architecture
Platform
OSI – Onion Super Intelligence
Product
OSI AEGIS
Role
Protect
Category
XDR · Extended Detection & Response
Status
In development
Access
Design-partner program open
  1. Research
  2. In development
  3. Available

01Why we are building it

Correlation across tools is still done by hand

Security teams run capable point tools that do not talk to each other. An intrusion generates an endpoint alert in one place, a sign-in anomaly in another and a cloud event nobody reviews. The connection between them is left for a person to find at 3 a.m. Correlation is the actual job, and it is still done by hand.

Most XDR platforms extend a single vendor’s agent outward and correlate best within their own ecosystem. Onion’s security operations service works across whatever stack an organization already owns, so AEGIS is being designed the way an operator needs it: source-agnostic, entity-centric and explicit about the cost of telemetry.

02Architecture

How it works

Fig. 01AEGIS: telemetry in, security operations out

Endpoint, Identity, Cloud, Network, Threat intelligence feed AEGIS, the security intelligence layer. From it come Detect, Correlate, Investigate, Hunt, Respond.

Telemetry

  • EndpointEDR telemetry and process activity
  • IdentityDirectory changes and sign-in events
  • CloudControl-plane and workload logs
  • NetworkPerimeter and internal traffic
  • Threat intelligenceIndicators, actors and context
Security intelligence layerAEGISOne schema, one entity model, one investigation surface

Security operations

  • DetectEngineered content mapped to MITRE ATT&CK
  • CorrelateRelated signals become one incident
  • InvestigateTimelines, entities and evidence
  • HuntHypotheses tested across every layer
  • RespondReviewable actions with an audit trail
AEGIS, 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. Detect

    Engineered detection content applied across endpoint, identity, cloud and network telemetry

  2. Correlate

    Related signals resolved into one scored incident on shared entities and time

  3. Investigate

    Timelines, entity context and evidence assembled before the analyst opens the case

  4. Hunt

    Hypotheses tested on one query surface over every layer

  5. Respond

    Reviewable, audited actions across domains, automated only where pre-approved

Detect

Detection across every layer, engineered as code

Detection content is engineered from adversary behavior and mapped to MITRE ATT&CK, then applied across endpoint, identity, cloud and network telemetry in one place. Threat intelligence enriches detections with the actors and indicators behind them, and coverage gaps are reported plainly rather than hidden.

Designed to

  • Endpoint detection and response on EDR telemetry
  • Identity threat detection on directory and sign-in activity
  • Cloud security monitoring of control-plane and workload events
  • Network detection on perimeter and internal traffic
  • Detection engineering as code, with MITRE ATT&CK mapping and gap reporting
  • Threat intelligence applied at detection time

Correlate

Related signals become one incident

Signals from every source are normalized into one schema, where a user is the same user whether the event came from an endpoint, a directory or a cloud audit log. Correlation then resolves related detections across layers and time into a single incident, scored by the real blast radius. The intended result is a queue of a few incidents instead of a long list of alerts.

Designed to

  • Security telemetry correlation on shared entities and time
  • Alert correlation into scored incidents
  • Security analytics over normalized, entity-resolved data
  • Risk scoring driven by asset criticality and privilege
  • Data-quality monitoring: a silent log source is reported as a finding

Investigate and hunt

The timeline is built before the analyst arrives

When an incident opens, the platform is designed to have done the first hour of work already: a chronological reconstruction across every telemetry source, entities enriched with history and criticality, and the evidence behind each step attached. The same query surface serves threat hunting, so a hypothesis can be tested across every layer at once.

Designed to

  • Incident investigation with automatic timelines and linked evidence
  • Entity context: what this user, host or application normally does
  • Threat hunting on one query surface over every source
  • Case state, notes and handoffs that survive shift changes

Respond

Response actions carry an audit trail

Containment actions across domains, such as revoking sessions, isolating hosts, removing application grants and blocking senders, are proposed with the evidence behind each recommendation. Analysts approve, or pre-approved playbooks execute automatically. Every action is logged, attributable and reversible where the underlying platform allows.

Designed to

  • Cross-domain response actions from one place
  • Automated response only where it has been pre-approved
  • Full audit trail of who or what acted, when and why
  • Incident response reporting generated from the investigation record

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.

Telemetry domains
Endpoint (EDR telemetry and process activity), identity (directory changes and sign-in events), cloud (control-plane and workload logs), network (perimeter and internal traffic), and threat intelligence. The ingestion layer is designed so that further sources are added by onboarding, not by rebuilding.
Data model
Entity-centric. A user, host, identity, workload or application is one entity whatever source the event came from, resolved across sources into one schema. Correlation, investigation and hunting all read the same model.
Detection content
Engineered as code: versioned, tested and peer-reviewed before it runs. Every detection is mapped to MITRE ATT&CK, and coverage against the framework is reported, including the gaps.
Correlation
Related detections are resolved into one incident on shared entities and time. Incidents are scored by the blast radius that asset criticality and privilege imply, not by a vendor default.
Investigation
When an incident opens, a chronological timeline across every source, entity context with history and criticality, and the evidence behind each step are designed to be ready before an analyst arrives. Case state, notes and handoffs survive a shift change.
Hunting
One query surface over normalized, entity-resolved telemetry, so a hypothesis is tested across every layer at once and a successful hunt can become a detection.
Response model
Approval-gated. Actions are proposed with the evidence behind them; analysts approve, or playbooks the organization has pre-approved execute. Every action is logged, attributable and reversible where the underlying platform allows.
Integration intent
Designed to consume the EDR, identity provider, cloud audit logs and network sensors an organization already runs, and to operate alongside an existing SIEM rather than replace it. Specific integrations are stated here as they are built.
Deployment intent
Hybrid and multi-cloud estates with mixed vendors. Storage tiering and cost visibility are part of the design, because security data is expensive to keep.
Record
A complete record of what was detected, what was concluded, and what acted, whether a person or an automation, so that an incident stands up to review after it closes.

04Designed for

The situations it is being built for.

  • Fewer consoles, one story

    A phished credential becomes a cloud persistence attempt. Endpoint, identity and cloud signals correlate into one incident while the intrusion is still in progress, instead of three alerts in three tools.

  • Alert volume that analysts can work

    Raw alerts are grouped into a small number of scored incidents, so the team works on stories instead of tickets.

  • Investigations that start at the decision

    The gathering is done on arrival. Analysts spend their time on judgment, and escalations arrive pre-investigated rather than raw.

  • Cloud control-plane visibility

    Role assumptions, application registrations and policy changes are monitored alongside endpoint telemetry, an area many tools leave uncovered.

  • Response that stands up to review

    Every action is proposed with evidence, approved or pre-authorized, and logged, so the record of an incident is complete when it closes.

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

    SOC analyst

    Opens an incident that already has its timeline, entities and evidence assembled, and spends the shift on decisions instead of data gathering.

    Detect · Correlate · Investigate

  • 02

    Detection engineer

    Writes, tests and versions detection content as code, sees coverage against MITRE ATT&CK, and turns hunt findings into new detections.

    Detect · Hunt

  • 03

    Threat hunter

    Tests one hypothesis across endpoint, identity, cloud and network at once, on one query surface over one data model.

    Hunt · Investigate

  • 04

    Incident responder

    Proposes or executes containment across domains from one place, with the evidence attached and every action on the record.

    Investigate · Respond

  • 05

    Security leader

    Sees incidents rather than alerts, coverage rather than claims, and a response record that survives an audit or a board question.

    Across the product

06Principles

Design principles

Correlation first
The platform exists to answer one question: are these signals the same attack. Everything else is built around that question.
Analyst-shaped
Designed with direct input from Onion’s security operations analysts, who review each workflow. Fewer clicks to context, and no moving between consoles during an investigation.
Explicit telemetry economics
Security data is expensive to keep. The architecture treats storage tiering and cost visibility as features, not afterthoughts.

07Questions

Questions we are asked

No. It is in development, and this page describes design intent. Organizations that need detection and response now can use our security operations service, which works with existing tooling. Our security operations specialists also advise the product team on what to build.

Yes. AEGIS is Onion Infosec’s XDR: extended detection and response that unifies endpoint, identity, cloud and network telemetry. If you are looking for XDR from Onion Infosec, this is the product.

The design goal is to consume the telemetry sources an organization already has, such as its EDR, identity provider, cloud audit logs and network sensors, and to integrate with an existing SIEM rather than replace it. Specific integrations are decided during design-partner work and will be stated here as they are built, not before.

It is not designed to. Where you have an EDR you trust, AEGIS is being designed to consume and correlate its signals. Where you have a SIEM, AEGIS is designed to work alongside it.

Yes. At this stage, design-partner conversations with security 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.

The rest of OSI

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

Trust & Security About the company