> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/capabilities/context-engine.md).

# Context Engine

## Overview

The Context Engine is the knowledge layer that every other Nullify capability reads from. It continuously builds a unified model of your environment — the code you ship, the cloud you run it on, the dependencies you pull in, and how all of it connects — so that detection, triage, and remediation can reason about real-world risk instead of isolated findings.

Where a scanner sees a single misconfiguration or vulnerable package, the Context Engine sees the application it belongs to, whether it is reachable from the internet, who owns it, and what data flows through it. That shared context is what lets Code Reviews, Cloud Audits, Pentests, and Security Program Management agree on what actually matters.

The Context Engine builds and serves five major bodies of context:

* **Asset Graph** — a unified, queryable graph of every cloud, cluster, repository, and application asset, with the relationships and reachability between them.
* **SBOM & Dependency Graph** — generated software bills of materials and a tenant-wide dependency graph with exposure windows.
* **Cloud Recon** — AI-driven reconnaissance of each cloud account: topology, IAM posture, network exposure, trust boundaries, and attack-path hotspots.
* **Dependency Exposure** — point-in-time and historical answers to "where is this package, at this version, deployed across my estate?".
* **Memory Vault** — durable agent memory plus a tenant document vault that grounds every agent in your organization's specifics.

## Asset Graph

The Asset Graph merges infrastructure and repository context into one connected model of your estate. Cloud accounts, Kubernetes clusters, repositories, and application groupings become nodes, and the relationships between them — deployment, network paths, ownership — become edges.

The graph powers the platform's asset explorer and is queryable end to end:

* **Landing & summary** give per-kind node counts and entry-point cards (cloud accounts, clusters, applications, repositories) for navigating the estate, plus presigned download URLs for the combined infrastructure and repo-context graphs.
* **Search & subgraph** let you find nodes by query string and extract a bounded subgraph around any starting node.
* **Reachability** computes whether a node is reachable from the internet by walking allowed edge types from a synthetic Internet node toward the target, returning the path(s) it found. When the graph is too large to fully enumerate, the result is explicitly marked as undetermined rather than falsely reporting "not reachable" — so consumers never mistake an incomplete search for a safe asset.

Reachability and ownership from the Asset Graph are what let other capabilities prioritize. A vulnerable dependency on an internet-facing service ranks above the same dependency buried in an internal batch job, because the graph knows the difference.

### Asset Inventory

On top of the graph, the Context Engine maintains a categorized **Asset Inventory** — a flat, filterable list of assets grouped into categories such as compute, container, cluster, serverless, network, connectivity, load balancer, CDN and DNS, storage and backup, database, messaging, data pipelines, identity, security, observability, CI/CD, pipelines, AI/ML, artifacts and artifact repositories, repositories, and projects. Each asset can carry tags and flags for routing and triage, and a dedicated public-asset view surfaces everything exposed to the internet.

{% hint style="info" %}
The Asset Graph is built automatically from your connected cloud accounts and repositories. There is nothing to configure per asset — connect a source and its assets flow into the inventory and graph. See the [connector guides](/connectors/aws.md) for setup.
{% endhint %}

## SBOM & Dependency Graph

The Context Engine generates a software bill of materials (SBOM) for every repository and project, then assembles those SBOMs into a tenant-wide dependency graph.

SBOM generation runs a full pipeline — clone the repository, classify each project, and resolve its dependency tree. Projects with their own lockfile are resolved precisely; projects without a lockfile fall back to the repository or workspace root, and the engine tracks which projects were resolved without a lockfile so you can see where dependency resolution is least precise. SBOMs are stored per repository, project, and commit, and the engine returns the latest SBOM for a repository, a specific repository/project SBOM, or a get-or-generate result that produces one on demand.

From the assembled graph you can:

* Browse the SBOM **tree** for the whole tenant.
* Resolve dependencies **by BOM reference** and list everything that **depends on** a given component (its dependents / parent chains).
* See which projects and repositories were **resolved without a lockfile**.

Generated SBOMs are the substrate for Dependency Analysis and the dependency-exposure queries below, and they feed the supply-chain context that Pentests and Cloud Audits draw on. SBOMs for a repository are also retrievable through the SCA API (`GET /sca/repositories/{repositoryId}/sbom`).

## Cloud Recon

Cloud Recon is the Context Engine's AI-driven reconnaissance of each connected cloud account. Nullify analyzes each account's infrastructure in parallel, then synthesizes the results — including cross-account IAM trust — into a single artifact per account and an organization-wide rollup.

For each account, Cloud Recon produces a structured synthesis covering:

* **Topology & overview** — the account's resource topology and a high-level summary.
* **Security boundaries & trusted services** — where the account's trust edges sit and which external services it trusts.
* **Network exposures** — internet-facing and over-broad network paths.
* **Traffic flows** — observed and inferred flows between resources.
* **IAM posture** — effective-permission resolution and privilege-escalation paths.
* **Cross-account relationships & tenant-wide trusts** — how accounts trust one another.
* **Hotspots** — a ranked list of attack-path concentrations.
* **Graph gaps** — places where the engine could not fully resolve the picture, surfaced honestly rather than hidden.

The latest synthesis is available per account and at the organization level, alongside the latest scan metadata. Cloud Recon enriches the Asset Graph and gives Cloud Audits the infrastructure understanding it needs to separate real risk from benign configuration variation.

## Dependency Exposure

When a new CVE drops or a malicious package is disclosed, the first question is "do we use it, and where?". Dependency Exposure answers that against the dependency graph, with version-aware and time-aware precision.

* **Active dependencies** lists what is currently active across every repository and project, with an aggregate summary including counts and the oldest active dependency.
* **Exposure by version** returns the exposure windows — across the whole tenant or scoped to one repository/project — that intersect a version filter expressed as a semver range or a content hash. This is the "who is running log4j between 2.0 and 2.14.1" query.
* **Exposure history** returns the windows over which a given package (by ecosystem and name) was present, so you can answer "how long were we exposed?".
* **Point-in-time and diff** queries return the active dependencies at a specific commit, or the dependency delta between two commits, for a repository/project.

Because exposure is computed from generated SBOMs and stored as windows over commit history, answers reflect not just the present state but the full timeline of when a component entered and left your estate.

## Memory Vault

The Memory Vault is two complementary stores that keep Nullify's agents grounded in your organization.

**Agent memory** is a first-class, versioned store of what the platform has learned about your environment — durable facts, decisions, and context that agents accumulate over time. Memories are typed, can be associated with documents, retain version history, and are searched with **hybrid semantic + lexical search** so an agent can recall the most relevant prior context for the task in front of it.

**The document vault** lets you upload organization-specific files — architecture notes, runbooks, security policies, and other context — that ground agents in how your organization actually operates. Files are uploaded through presigned URLs, listed and retrieved on demand, and an onboarding step ingests them into the knowledge base so agents can draw on them during triage, planning, and remediation.

Together with the **organization context** — your classification, technology profile, and risk posture — the Memory Vault is how Nullify avoids generic, context-free advice. It is also part of the same knowledge model Pentests exploit and Security Program Management reasons over when assigning and sequencing work.

## How the Pieces Connect

The Context Engine is read by every detection and remediation capability:

* **Code Reviews** use repository context, ownership, and the dependency graph to prioritize and route findings.
* **Cloud Audits** use Cloud Recon and the Asset Graph to validate whether an infrastructure issue is a real risk in context.
* **Pentests** exploit the knowledge model — endpoints, reachability, and discovered credentials — to drive deep, application-aware testing.
* **Security Program Management** reads ownership, capacity, and organizational risk to assign the right work to the right people.

## API Access

The Context Engine's model is queryable for automation and reporting. Endpoints live under the `/context/*` namespace (with asset-graph queries at `/context/asset-graph/*` and infrastructure graphs at `/context/infrastructure/*`). Representative endpoints:

| Area                | Endpoint                                                         | Purpose                                                    |
| ------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------- |
| Asset Graph         | `GET /context/asset-graph/summary`                               | Unified summary of infrastructure and repo-context graphs. |
| Asset Graph         | `GET /context/asset-graph/reachability`                          | Compute whether a node is reachable from the internet.     |
| Asset Inventory     | `GET /context/asset-inventory/public`                            | List every asset exposed to the internet.                  |
| SBOM                | `GET /context/sboms/repository/{repositoryId}/latest`            | Latest SBOMs for a repository.                             |
| SBOM                | `GET /context/sboms/tree`                                        | Tenant-wide SBOM tree.                                     |
| Cloud Recon         | `GET /context/cloud-recon/accounts/{accountId}/synthesis/latest` | Full reconnaissance synthesis for an account.              |
| Dependency Exposure | `GET /context/deps/exposure`                                     | Tenant-wide package exposure by semver or hash.            |
| Dependency Exposure | `GET /context/deps/active`                                       | Active dependencies across all repositories/projects.      |
| Memory Vault        | `POST /context/memories/search`                                  | Hybrid semantic + lexical search over agent memory.        |
| Memory Vault        | `GET /context/vault/files`                                       | List uploaded organization documents.                      |
| Applications        | `GET /context/applications`                                      | The catalog of applications and their context.             |

All requests use a service-account token. See the [API Reference](/api-reference/api-reference.md) and the full [OpenAPI specification](/api-reference/api-reference/openapi-spec.md) for the complete contract.

## Configuration

The Context Engine builds itself from your connected sources — there is nothing to enable per asset. Connect your repositories and cloud accounts during [Onboarding](/getting-started/getting-started.md), and the asset graph, SBOMs, cloud recon, and dependency graph populate automatically as scans run. See the connector guides for setup: [AWS](/connectors/aws.md), [GCP](/connectors/gcp.md).