Asset Intelligence Concepts

Assets, exposure, signals, and how to interpret the product over time.

This page explains the main concepts behind Asset Intelligence so the product can be read consistently across assets, pages, events, and findings.

What counts as an asset

In Asset Intelligence, an asset starts as a monitored domain or public IP address. These are the primary external targets used to define what is in scope.

From that starting point, Kantoku can build a broader picture that includes:

  • ports and externally observable services
  • pages and web application surfaces
  • HTTP behavior and browser-observed context
  • DNS records and trust-related resolution details
  • certificates and TLS context
  • ownership or registration context
  • related organization context, where Kantoku can associate the asset to an organization
  • similar-domain intelligence

The goal is to keep these elements connected so an asset can be understood as a whole rather than as separate, unrelated facts.

Core concepts

Assets

Assets are the monitored domains and public IP addresses that define the primary scope of observation.

Exposure

Exposure describes how an asset presents itself externally. This can include open ports, HTTP services, DNS signals, TLS material, and browser-observed page behavior.

Pages

Pages are the web surfaces discovered for an asset. They help answer what is actually being served, not just what is theoretically reachable.

Page monitoring can capture multiple kinds of evidence, each useful for a different reason:

  • screenshots show what the user-facing page looked like at the time of observation
  • technologies help identify frameworks, analytics tooling, CDNs, widgets, and other building blocks
  • HTTP headers help explain caching, security policy, redirects, and other server behavior
  • cookies help explain state, tracking, consent handling, and session behavior
  • resources show which external assets the page loads in practice
  • console logs help surface client-side warnings, runtime errors, and implementation clues
  • page services help surface durable third-party service usage without requiring teams to interpret every raw cookie or resource change

Depending on the page, Asset Intelligence can also help teams reason about redirect behavior and content change over time, so a page can be understood as an evolving surface rather than a one-time capture.

These signals are useful together because they describe both presentation and behavior. A page may look stable in a screenshot while the underlying resources, headers, or cookies changed in a meaningful way.

Reading page evidence

A page view is most useful when it is read as layered evidence rather than a single screenshot.

Technologies

Technologies help explain what is powering the page. They can reveal application frameworks, analytics providers, consent tooling, chat widgets, tag managers, and other dependencies that shape how a page behaves.

HTTP headers

HTTP headers help explain how the server presents the page. They can provide clues about cache policy, redirect behavior, security controls, content policy, and other trust-relevant behavior.

Cookies

Cookies help explain how state is created and maintained in the browser.

They can indicate:

  • session handling
  • login or application state
  • analytics and measurement behavior
  • advertising or third-party tracking behavior
  • consent-state handling

The difference between cookies before consent and cookies after consent can be important.

Before consent, the page is observed in its initial state. After consent, the page is observed again after the consent interaction is attempted.

This helps answer questions such as:

  • which cookies are present immediately on first load
  • which cookies appear only after consent is accepted
  • whether analytics or marketing-related cookies were delayed until after consent
  • whether non-essential cookies appear before the consent flow is completed
  • whether the consent action materially changes the browser state at all

This does not by itself make a legal or policy determination, but it gives teams evidence for understanding how consent behavior affects page state in practice.

This distinction also matters when reading change over time. Some runtime changes are meaningful only in one consent phase, while others are recurring marketing or tracker churn that should not be treated as a major shift in page behavior. Asset Intelligence is designed to preserve the useful evidence without forcing teams to interpret every repeated runtime fluctuation as a new issue.

Resources

Resources show which external scripts, stylesheets, images, fonts, APIs, and third-party assets were loaded by the page.

This is useful for understanding external dependencies, hidden integrations, changes in third-party footprint, and the practical difference between what a page contains and what it pulls in at runtime.

Page services

Page services are a higher-level view of durable third-party usage inferred from page behavior.

This helps answer questions such as:

  • which external services appear to be materially present on the page
  • whether a third-party service was newly adopted or removed
  • whether recurring vendor-specific runtime noise should be interpreted as meaningful change or as background churn

This is useful because a page can load many changing resources without meaningfully changing its external service footprint. Page services help preserve the durable signal without making teams read every low-level browser diff.

Console logs

Console logs help surface client-side runtime behavior. They can reveal JavaScript errors, failed network calls, warnings, deprecations, and implementation clues that would not be visible from the screenshot alone.

Organization context

Some assets can also be understood in the context of a related organization. In those cases, organization profile information, trust pages, and security incidents help explain the broader entity behind the observed domain or IP surface.

Signals

Signals are observed facts about an asset or its related surfaces. A signal can describe current state, change, or context.

Examples include:

  • a newly observed port
  • a changed TLS configuration
  • a changed content hash for a page
  • a new similar domain candidate
  • a changed DNS record

Reading change over time

Asset Intelligence is designed to help teams understand change over time, not just capture isolated observations.

The same condition can mean different things depending on whether it reflects continuity, drift, emergence, or resolution rather than simple presence alone.

For example, a long-standing DNS record may simply be part of the baseline. A new DNS record may indicate operational change that deserves review. A persistent condition may reflect continuity. A disappeared condition can be just as relevant as a newly introduced one if it affects trust, ownership, or expected exposure.