Action depends on truth. Truth is hard to come by.

There’s an old trope: “You can’t protect what you can’t see.” This burning need for total visibility has led to an abundance of security data across every domain. But abundance doesn’t equal clarity. One tool says a device is patched, another says it’s vulnerable. HR says a user is terminated, the IdP shows them as active. SaaS spend reports light up apps no one in IT has ever heard of. The contradictions pile up as fast as the alerts.

Today’s AI inflection point has changed our perspective towards the art of the possible – both in what we can build and what we have to defend against. As security professionals, we can also learn from the ways the AI ecosystem has matured in terms of getting good outputs from focused, relevant, and accurate inputs. And that’s the systematic practice of context engineering.

Humans have always worked within a context window to make security decisions. But that window is often cluttered with incomplete and inaccurate information. As a result, analysts often waste cycles reconciling dashboards, chasing owners, and second-guessing whether the data is current. Machines face the same challenge at a different scale, but AI doesn’t pause to question whether fields are stale or ownership is missing – it acts instantly on whatever it’s given. AI is a force multiplier in whichever direction it’s aimed at.

As more teams adopt AI for proactive security, context engineering will become a required discipline to execute effectively with trust and within guardrails. Just as AI developers refine agents with techniques like memory and retrieval, security teams need their own methods for handling asset, security, and business context, whether for manual playbooks or agentic workflows.

A question then comes up – what is the source of truth? As it stands across the tech stack of any enterprise, multiple tools will make that claim – the SIEM, the CMDB, the IdP. They can make that claim, but only within their respective domain. The reality is that context engineering must be performed at the aggregate to achieve complete, accurate, and up-to-date information across the entire environment.

Asset Intelligence is a methodology for aggregating security, business, and threat context across domains. It requires a carefully executed data pipeline to engineer decision-grade output at the scale, depth, and breadth required for proactive cybersecurity operations.

The Principles of Asset Intelligence

Asset Intelligence is the supporting technology designed to transform raw, fragmented system data into decision-grade output. The following principles come from our learnings in building asset intelligence across thousands of customer environments. It’s never one-size-fits-all – environments differ, naming conventions are unique, and business priorities change. The key to unlocking actionability is making your asset intelligence dynamic, not a static inventory.

Discovery is a Collection of Control Planes

Across any enterprise, it takes a select number of control planes in the IT stack to reveal the full picture of the environment. An MDM agent, an IdP, a vulnerability scanner, a SaaS app – somewhere in the stack, every asset leaves a signal. Aggregation is the only way to complete that picture.

Gaining visibility isn’t the end state, rather the baseline that every downstream action depends on. Without a total view of the environment, workflows start on shaky ground.

This is hard because it requires persistent touchpoints into many systems, running continuous discovery cycles, and adapting as APIs change or new tools are adopted. The challenge isn’t whether the data exists, but maintaining the connections and cycles to collect it continuously.

Correlation Resolves Conflicts

Raw system data is messy. Correlation is the process of resolving which data actually represents a unique asset across tools, timestamps, and identifiers.

Context engineering requires named, authoritative objects. A device, a user, or an application can only be trusted when its identity is reconciled across conflicting sources.

It’s a precise effort – correlating too aggressively merges distinct assets into one. Undercorrelating leaves duplicates that fracture context. The balance is critical and difficult to maintain at scale.

No two environments handle identifiers the same way. We’ve had to build correlation engines that weigh confidence across fields and sources rather than relying on a single “golden” identifier—because at scale, there is no such thing.

Normalization Creates Consistency

Every source has its own schema. One calls it “username,” another “userID.” Normalization is what makes data interoperable, so queries return consistent results.

Context engineering is about bringing as much determinism to non-deterministic workflows as is allowed. Normalization provides the consistency that lets complex queries run reliably across the entire environment.

Without normalization, even the simplest query – like “all Windows 11 devices” – becomes a brittle exercise in translation.

Schema drift is inevitable. Every new tool or API version brings renamed or retyped fields. We’ve learned normalization can’t be a one-off mapping exercise, it has to be a continuously updated, versioned schema applied across every connection.

Enrichment Makes Context Real-Time

There will always be external forces at play. Vulnerabilities emerge, software goes end-of-life, SBOM disclosures surface hidden dependencies. Enrichment attaches this dynamic context so every asset profile reflects the current state of the environment.

Think of enrichment as giving the system the ability to perform “deep research,” gathering external intelligence that transforms stale records into decision-grade context.

This requires continuous feeds from vulnerability databases, software lifecycle data, threat intel, and reinforcement learning.

The most accurate internal data can still go stale without external context. We’ve learned enrichment isn’t just about adding intel feeds, it’s about layering them in carefully, so signals like CVEs or EOL dates sharpen decisions instead of creating noise.

Relationships Define the Exposure Paths

The global attack surface is best understood as a living knowledge graph. Assets connect in many ways: users to devices, services to networks, applications to identities. Attackers exploit these relationships to find paths; defenders must model them to close them.

Proactive security depends on these relationships. Relationships transform asset context into a focused, relevant defense strategy. With relationships mapped, a single remediation can cut off multiple attack paths at once.

Real-world environments never fit into a single schema, however. Modeling relationships across domains requires traversal awareness and must scale to millions of links without becoming brittle.

Relationship modeling is a critical layer of inference that helps transform asset intelligence into intelligent action. By continuously deriving and validating these relationships, security teams can move beyond point-in-time inventories to a living model of the global attack surface. That’s what makes it possible to take action with confidence.

Transform Asset Intelligence into Intelligent Action

If the result of Asset Intelligence is decision-grade output, what does that output unlock? Consider the things holding cyber teams back from taking proactive action – a fragmented attack surface, more issues than capacity, and missing data dependencies.

Much of the AI discourse in security is focused on a single domain – vulnerability management, identity security, and phishing protection. The innovation there is real, but the actions are still only as strong as the context underneath. Without full visibility into relationships, ownership, and criticality, even the best AI will misfire.

Actionability comes from taking action at the aggregate. Asset Intelligence enables the right levels of context engineering to work around a single living model of the entire environment.