Federated Search Meets the Context Layer: Organizational Context and Dynamic Lookup Tables

TL;DR

Vega’s federated search architecture makes organizational context queryable alongside telemetry. Identities, assets, cloud resources, sensitive data, ownership, and business metadata are all accessible in the same KQL flow.
Organizational Context turns each connected source into a queryable surface. Connect Okta and identities are available. Connect Axonius and devices show up. Same for Wiz cloud resources.
Dynamic Lookup Tables turn the most-used query logic into reusable, continuously refreshed assets. Define once, use everywhere: detections, investigations, dashboards, notebooks, AI workflows.

Federated search changed how security teams access telemetry. But searching logs is only half the problem.

To understand whether an event matters, the SOC also needs the context around it: the identity behind the action, the asset being touched, the sensitivity of the data, and the business meaning behind it.

Vega’s federated search architecture makes organizational context queryable by design. Teams can reach into the systems where truth already lives (identity, asset, cloud-security, and data-security tools) and combine that context with logs in one KQL-native flow.

But queryable context is only the first step. In a real SOC, the most important context becomes shared operational knowledge. It shouldn’t be recomputed every time a detection runs, an investigation starts, or an AI agent asks a question.

It should be defined once, continuously refreshed, and reused everywhere.

What are Organizational Context and Dynamic Lookup Tables?

Organizational Context makes external context sources queryable in Vega: users, assets, cloud resources, sensitive data, ownership, privileges, and business metadata can be accessed alongside logs through the same federated KQL experience.

Dynamic Lookup Tables turn the most important context definitions into reusable, continuously refreshed tables. Define them once, use them everywhere: detections, investigations, dashboards, notebooks, and AI workflows.

Together, they bring the context layer into Vega’s federated search engine.

The flow: build the detection, then add context

Say we want to detect suspicious MFA factor changes for executives.

Figure 1: KQL query against @Okta-System-Logs filtering MFA factor update, activate, and deactivate events.

We start with the telemetry. That finds MFA changes. But it does not answer the important question: did this happen to a user we care about? So we add Organizational Context.

In this case, @Okta-Users tells us whether the target is a senior management employee.

Query editor with autocomplete showing Okta Users organizational context. — Figure 2: Query editor with autocomplete showing Okta Users organizational context

KQL detection joining @Okta-System-Logs with @okta-users to filter MFA events for executives. — Figure 3: KQL detection joining @Okta-System-Logs with @okta-users to filter MFA events for executives

Now the detection is not just looking for MFA activity. It is looking for MFA activity against users that matter most - senior management-level users.

There is no separate onboarding flow for this context. Connect Okta and identities are available. Connect Axonius and devices show up. Connect Wiz and cloud resources become queryable.

Stop rebuilding the same context in every detection

There is still another question: is this actor normally allowed to perform these actions? In this case, we use Okta activity logs to identify known active Okta admins. We could add that logic directly to the detection query, but then every detection execution would rebuild the same Okta admin list.

Instead, we define a Dynamic Lookup Table that refreshes the admin list every 24 hours.

Figure 4: Create dynamic lookup table for Okta Active Admin Users with 24h refresh and 30d lookback.

Set the refresh schedule (for example, every 24 hours) and a lookback window. Vega materializes the result as a named table the whole platform can reference.

Use the Dynamic Lookup Table in the query

The analyst can search for the Dynamic Lookup Table directly from the query experience and add it into the detection flow as reusable context.

Figure 5: Detection query with Okta Active Admin Users lookup table selected from the asset library.

Figure 6: Complete detection excluding actors in @lookup_tables/Okta-Active-Admin-Users for executive MFA factor changes.

A detection can use it. An analyst can query it. A dashboard can visualize it. An AI agent can reason with it.

Key takeaways

Context is queryable. Organizational Context makes external business and security metadata available through Vega’s federated KQL layer.
Important logic is reusable. Dynamic Lookup Tables turn repeated KQL logic into continuously refreshed tables.
Detections can start with context. Rules reference Organizational Context and Dynamic Lookup Tables directly instead of waiting for enrichment after the alert fires.
Investigations stay in one flow. Analysts move from telemetry to organizational context without leaving the KQL experience.

FAQ

What is Organizational Context in Vega?

“Organizational Context” is Vega’s term for the external business and security metadata that becomes queryable alongside telemetry through the federated search architecture. Users, assets, cloud resources, sensitive data, ownership, privileges, and business attributes are all accessible from the same KQL flow as logs. Once a connector is established (Okta, Axonius, Wiz, or others), its context surfaces are available to query immediately.

What is a Dynamic Lookup Table?

A Dynamic Lookup Table is a continuously refreshed query result that’s saved as a reusable query source. Define the KQL once, set the refresh frequency and lookback window, and the table becomes available across detections, investigations, dashboards, notebooks, and AI workflows. The logic is maintained by the platform, not duplicated by every team that needs it.

What’s the difference between a static lookup table and a Dynamic Lookup Table?

A static lookup table is a snapshot. It captures the state of something at the moment it was created: a user uploads a CSV, and this CSV becomes a query source. The CSV is static, and so is the lookup table that captures it. A Dynamic Lookup Table is a live query result that the platform refreshes on a schedule you set. Detections, dashboards, and AI agents reading from it get current data without recomputing.

When should I use a Dynamic Lookup Table vs querying context directly?

Query context directly when the logic is one-off, exploratory, or specific to a single investigation. Use a Dynamic Lookup Table when the same logic repeats across detections, dashboards, notebooks, or AI workflows, or when the query is expensive enough that you do not want every detection execution to recompute it. Vega refreshes the table on a schedule, and downstream consumers simply read the latest result instead of rebuilding it each time.

What kinds of context sources work with Vega’s Organizational Context?

Identity providers, asset inventories, cloud security tools, data security tools, and business systems are all candidates. Connecting Okta makes identities queryable. Connecting Axonius makes devices queryable. The same pattern applies to other cloud-security and data-security tools in your stack. There’s no separate onboarding flow for context. Once the connector is live, the context surfaces appear in the query experience.

What’s next

Organizational Context and Dynamic Lookup Tables are available now. Book a demo to see them running against your environment.

If you’re working the broader architecture problem, Query Every Cloud at Once, Without Moving a Byte of Data is a companion read on how federation behaves across clouds.