00 / Executive brief
Executive brief
Trust is granted at a point in time. Risk changes continuously.
A cleared employee passes through a personnel vetting process. A privileged administrator receives access to critical systems. An executive, developer, contractor, vendor operator, or other trusted person is authorized to reach sensitive areas, databases and holdings, and other information and capabilities that could materially affect the mission.
The trust decision may be sound when it is made. It does not freeze the identity in place, however.
New accounts appear. Credentials are exposed. A personal or corporate device is infected by information-stealing malware. An alias, email address, phone number, messaging identity, business entity, foreign affiliation, crypto wallet, criminal or regulatory record, or dark-web exposure becomes observable. A role changes. Access expands. An external actor begins targeting the person. Several weak changes accumulate into a pattern that did not exist at hiring, clearance, onboarding, or the last review.
Each development can matter. None should become an allegation simply because it was detected.
LightHouse is Silent Harbor's Identity Intelligence Engine. It gives authorized organizations a continuous insider risk monitoring layer for cleared and highly privileged workforces. The platform resolves each enrolled person across permitted internal, public, commercial, breach, malware-intelligence, and customer sources; establishes a baseline; detects material change; evaluates that change against the person's access and asset sensitivity; updates an explainable person-level risk score; and sends alerts to recipients designated in the platform.
Human review is required. LightHouse does not make clearance, employment, disciplinary, eligibility, or legal decisions.
The operating model is direct:
- Define the monitored population, protected assets, authorities, sources, review requirements, and designated alert recipients.
- Resolve each person and establish an approved identity, access, device, affiliation, and exposure baseline.
- Attach the sensitivity of the person's role, privileges, systems, information, facilities, and mission dependencies.
- Monitor authorized internal and external sources for relevant changes.
- Determine whether a new observation belongs to the enrolled person, another person, a shared identifier, or an unresolved candidate.
- Evaluate the signal by source reliability, corroboration, recency, change magnitude, policy relevance, compromise severity, and access criticality.
- Update the explainable risk score and create a material-change alert when configured conditions are met.
- Route the alert to designated recipients for investigation, mitigation, disposition, and required human review.
This is not continuous suspicion. It is continuous awareness around identities entrusted with consequential access.
The trust decision is a baseline. LightHouse shows when the facts around it materially change.
01 / Trust boundary
Trust is not static
Traditional vetting and access processes answer a necessary question: should this person receive a clearance, role, credential, or privilege now?
Continuous insider risk monitoring addresses the next question: has anything material changed since that decision?
The Defense Counterintelligence and Security Agency describes continuous vetting as regularly reviewing a cleared person's background to determine whether the person continues to meet clearance requirements and should remain in a position of trust. DCSA uses automated record checks to create alerts, then relies on investigators and adjudicators to validate the information, gather facts, and make determinations.
LightHouse applies the same continuous principle to a customer-defined trusted workforce and a broader identity intelligence environment. The monitored population can include:
- cleared military, government, and contractor personnel;
- privileged administrators and security operators;
- executives and other people with enterprise-wide authority;
- developers, engineers, and data personnel with sensitive production or repository access;
- finance, treasury, fraud, legal, and compliance personnel with high-impact capabilities;
- facility, laboratory, operations, and critical-infrastructure personnel;
- contractors, consultants, managed service providers, temporary workers, and vendor operators;
- other people whose role, access, or proximity to a protected asset creates consequential exposure.
The customer defines the operating boundaries:
The boundaries are parts of the security architecture. Continuous monitoring without defined purpose, source permissions, access controls, and review authority can become overcollection. A program that cannot explain why a signal matters can erode the trust it is intended to protect.
- Population
- Who is enrolled, why, and for which period?
- Protected assets
- Which systems, information, facilities, funds, technologies, data, people, or operations matter?
- Trust baseline
- Which identity, role, access, devices, accounts, affiliations, and known exposure are established at enrollment?
- Permitted sources
- Which customer, public, commercial, breach, malware, dark-web, and other sources may be used?
- Material change
- Which observations should affect risk, create an alert, or require review?
- Risk policy
- How do identity confidence, source quality, recency, privilege, asset sensitivity, and corroboration affect the score?
- Recipients
- Which people or teams receive each class of alert?
- Human authority
- Who investigates, mitigates, adjudicates, closes, or escalates the matter?
- Retention
- How long are baselines, observations, alerts, reviews, and dispositions retained?
Monitor material change around trusted access, not private life without limit.
02 / Why gaps emerge
Why current systems don't work
Organizations already operate background screening, access governance, endpoint security, identity protection, threat intelligence, data loss prevention, fraud controls, physical security, and insider risk processes. The gap often exists between them.
The baseline ages silently
A screening or access decision captures a moment. Days, months, or years later, the person's identity surface, device exposure, business interests, affiliations, credentials, role, and access may be different. Periodic review discovers some changes after the risk has existed for too long.
The same person is fragmented across systems
HR records, clearance identifiers, corporate accounts, aliases, personal contact information, devices, external accounts, business entities, wallets, and threat-intelligence records may not resolve cleanly to one person. A material observation can remain disconnected because the identifiers do not match exactly.
External compromise is separated from internal privilege
An infostealer log may expose a credential, browser session, device fingerprint, or account associated with a trusted employee. Endpoint or identity teams may see one part. Threat intelligence may see another. Access governance may not know that the affected person can reach a critical environment.
Alerts arrive without individual context
A new account, affiliation, record, or exposed credential is not equally consequential for every person. The same observation can have a different effect when the subject is a Tier 0 administrator, a cleared program employee, a developer with production access, or a user with limited privileges.
A change signal becomes a judgment
A newly observed Telegram account, Signal registration, crypto wallet, foreign contact, business entity, or adverse record may be relevant. It may also be benign, misattributed, historical, authorized, or unrelated. When detection is treated as proof, the program confuses awareness with adjudication.
Risk collapses into an unexplained score
A person-level risk score is especially useful when a reviewer can see what changed, which sources support it, how confidently the observation matches to the person, why the person's access matters, which rules affected the score, and what uncertainty remains.
Alert routing is improvised
Security, personnel security, counterintelligence, insider risk, HR, legal, privacy, fraud, and business leadership may require different alerts. If routing is handled through ad hoc email and manual forwarding, sensitive information reaches the wrong people, urgent signals wait, and disposition disappears from the evidence record. ---
03 / Monitoring sequence
How we solve these problems
LightHouse addresses these failures as one identity-centered operating problem. It keeps enrollment, baseline, protected access, observations, provenance, risk logic, alerts, recipients, human review, and disposition connected throughout the lifecycle.
LightHouse additionally organizes continuous insider risk monitoring as a controlled cycle. Autonomous Agents pursue bounded monitoring and enrichment tasks. Identity rules determine which person a signal may concern. Risk rules determine what changes. Human reviewers retain authority over action.
Enroll the trusted population
The customer defines the people, roles, contractors, vendors, and other trusted identities in scope. Each enrollment carries an authorized purpose, sponsor, monitoring period, protected assets, applicable policies, designated recipients, and required review.
Establish the baseline
LightHouse resolves the enrolled person across authorized customer and external sources. The baseline can include names, aliases, contact identifiers, accounts, messaging and social identities, devices, credentials, employers, business entities, affiliations, wallets, known exposures, role, access, and other customer-approved context. Known facts, self-reported information, customer records, external observations, and unresolved candidates remain distinct. The baseline is dated so later changes can be measured against what was actually known.
Attach privilege and asset sensitivity
The person is connected to the roles, entitlements, systems, data, facilities, technologies, funds, and mission dependencies the customer has designated. LightHouse can use customer Identity Access Management (IAM), Human Resources (HR), Endpoint Detection & Response (EDR), device, access, travel, case, and other permitted data to understand the potential consequence of identity or exposure change.
Monitor permitted sources
Mission-bound agents continuously check approved internal, public, commercial, dark-web, regulatory, legal, corporate, technical, and other sources, including novel and sensitive ones. Each observation retains its source, collection time, method, access restrictions, and relationship to prior observations. Source availability and monitoring cadence depend on customer authority, source rights, deployment, and configuration.
Resolve material change
LightHouse compares new observations to the baseline and tests whether they belong to the enrolled person to minimize false positives. It evaluates identifiers, chronology, device and account relationships, ownership, geography, co-occurrence, source quality, and conflicting evidence. A new observation may be accepted, rejected, linked as a candidate, or left unresolved. LightHouse does not quietly force records into the person's profile.
Update explainable risk
Configured risk logic evaluates the observation in context. LightHouse considers identity confidence, source reliability, recency, change magnitude, policy relevance, compromise severity, corroboration, cumulative pattern, access criticality, asset sensitivity, and any reviewed mitigation. The person-level score can rise, remain unchanged, or be adjusted after human disposition. Every score change retains an explanation.
Create and route the alert
When a configured threshold or material-change rule is met, LightHouse creates an alert containing the observation, identity match, risk contribution, protected-access context, supporting evidence, uncertainty, and recommended human review. The alert is delivered to recipients designated in LightHouse according to population, signal class, severity, program, geography, asset, and customer policy.
Review, mitigate, and learn
Authorized reviewers validate the identity and evidence, investigate as required, coordinate the appropriate functions, document the disposition, and determine action. Mitigation may involve credential reset, device isolation, access correction, employee engagement, further inquiry, additional training, monitoring, or closure. Validated learning is looped back in and returns to enhance still further identity rules, risk policy, alert routing, and evaluation cases. ---
04 / Identity intelligence
Identity intelligence is the engine
Continuous insider risk monitoring depends on knowing which changing facts belong to which trusted person.
The problem is not simply finding an email address or adverse record. The system must determine whether a new identifier is linked to the enrolled person, whether a credential exposure belongs to a corporate or personal device, whether an external entity is current or historical, whether two names represent the same individual, and whether an apparent change is material to the person's authorized access.
LightHouse builds a time-aware identity graph around nine classes of context:
The graph is not an allegation. It is the evidence environment in which new information can now be assessed and acted upon.
This distinction matters for communications platforms. LightHouse does not imply universal visibility into private or encrypted services, nor does observing an account imply access to private communications. A new Telegram, Signal, or similar account can enter the baseline only when the account or identifier is observable through an authorized customer, public, commercial, device, or other permitted source.
The identity engine then answers four questions:
- Is this observation actually new, or merely newly collected?
- Does it belong to the enrolled person?
- Is it relevant to policy, exposure, access, or a protected asset?
- What evidence and uncertainty should accompany the risk update?
- People and roles
- enrolled subjects, employers, sponsors, managers, teams, contractors, vendors, and other relevant actors.
- Names and identifiers
- legal names, aliases, usernames, emails, phone numbers, addresses, employee or clearance references, and customer-provided identifiers.
- Accounts and personas
- enterprise, social, messaging, developer, marketplace, forum, and other accounts observed through authorized sources.
- Devices and credentials
- managed and approved device context, technical identifiers, authentication methods, exposed credentials, sessions, browser artifacts, and malware-log observations.
- Access and assets
- roles, entitlements, privilege, approvals, systems, repositories, data, facilities, funds, technologies, and operational dependencies.
- Entities and affiliations
- employers, organizations, business interests, corporate records, professional relationships, foreign affiliations, and other mission-relevant associations.
- Wallets and financial interfaces
- crypto wallets, payment identifiers, financial records, or transactions where authorized and relevant.
- Adverse and exposure context
- criminal, civil, regulatory, sanctions, dark-web, credential, malware, and targeting observations available through permitted sources.
- History and provenance
- baseline date, first and last observation, change history, ownership windows, source, collection time, review status, and disposition.
Identity is the anchor. Change is the signal. Access determines consequence.
05 / Material changes
Material changes LightHouse can monitor & detect
The following signal patterns are illustrative. Their availability, weight, and handling depend on customer authority, source rights, program policy, and deployment. No single observation is necessarily an indicator of harmful intent.
New accounts, aliases, and communications identities
LightHouse can detect a newly observed digital footprint, such as a new email address, phone number, or username when that observation is available through an authorized source.
Infostealer, credential, and device exposure
LightHouse can monitor authorized digital indicators tied to an enrolled person or device. An appearance in a threat actor's logs can increase the person's risk score. It is not necessarily evidence, however, that the employee acted or is now acting maliciously. The appropriate response may be rapid credential rotation, session revocation, device isolation, threat hunting, access restriction, and human review. The distinction is operationally important: the person may be the victim while the organization's access remains at risk.
New personal and professional identifiers
Changes in names, aliases, phone numbers, email addresses, domains, addresses, professional profiles, and other identifiers can reveal a legitimate life change, a missed baseline fact, "identity collision," impersonation, or an emerging external persona. LightHouse preserves the source and chronology so the reviewer can determine whether the change is attributable, real, and relevant.
Business entities, outside employment, and affiliations
New companies, directorships, beneficial interests, consulting relationships, professional affiliations, counterparties, or foreign associations can matter for conflict of interest, disclosure, targeting, and access decisions. LightHouse can develop permitted corporate and identity context, but it does not treat association as disloyalty. Risk changes only occur under customer-defined policy and evidence rules.
Crypto wallets and financial interfaces
LightHouse can resolve newly observed wallets, exchange or payment identifiers, transactions, and related entities. The presence of a wallet is not inherently suspicious. The material question is whether the identity, transactions, timing, relationship, activity, or policy context creates a reason for review.
Criminal, civil, regulatory, and sanctions developments
New records may affect a customer's personnel security, suitability, fraud, legal, compliance, or access obligations. LightHouse can monitor permitted sources, resolve the subject, preserve record status and date, distinguish allegations from adjudicated facts, and route the observation under the applicable policy.
Dark-web and breach exposure
An enrolled person's identifiers, credentials, device artifacts, personal data, or accounts may appear in unlawful collections, criminal marketplaces, access-broker listings, paste sites, or other authorized intelligence sources. This exposure can indicate vulnerability, targeting, compromise, or a need for protective action. It does not necessarily establish participation where the data appeared.
Internal role, access, device, and travel changes
Customer IAM, HR, EDR, device, access, travel, and security telemetry can show privilege expansion, dormant access, unmanaged devices, role transitions, unusual authentication, policy exceptions, travel, and changes around sensitive systems or facilities. LightHouse connects those internal changes to the external identity and exposure environment so the reviewer can understand the whole risk surface around the trusted person. ---
06 / Explainable risk
From observation to explainable risk
LightHouse does not treat every new record as equal. Configured risk logic evaluates the observation, the confidence that it belongs to the enrolled person, the person's access, and the possible consequence to the protected mission.
An explainable score can incorporate:
Every score change should produce a reason record. This structure prevents the score from becoming an allegation generator. A reviewer should be able to see:
- what changed;
- when it changed and when it was collected;
- which person or identity it was matched to;
- the evidence supporting and contradicting that match;
- why the observation is relevant to the person's role or access;
- which factors changed the score;
- the prior and updated risk state;
- which alert rule was triggered;
- who received the alert;
- who reviewed it and how it was resolved.
- Identity confidence
- How strongly does the observation resolve to the enrolled person, account, device, or related entity?
- Source reliability
- Is the source authoritative, commercial, customer-provided, technical, self-reported, derivative, duplicated, or unresolved?
- Recency
- When did the change occur, when was it observed, and is it still current? Has anything like it occurred previously? Is there context surrounding the change?
- Change magnitude
- Is this a minor update, a new identity surface, a confirmed compromise, or a material shift from baseline?
- Policy relevance
- Does the observation intersect a customer-defined reporting, access, conflict, security, or personnel requirement?
- Privilege and asset sensitivity
- What could the trusted identity reach, change, disclose, transfer, approve, or disrupt?
- Compromise severity
- Does the evidence indicate exposed credentials, active sessions, device infection, adversary control, or another immediate technical risk?
- Corroboration and contradiction
- Do independent observations support the signal? Does other evidence weaken or refute it?
- Cumulative pattern
- Does the change stand alone, repeat, or combine with other reviewed signals?
- Mitigation and disposition
- Has the issue been resolved, explained, corrected, accepted, or placed under approved monitoring?
The score prioritizes attention. The evidence record supports the decision.
07 / Alerts and review
Alerts go to designated recipients. Decisions remain human.
LightHouse routes each material-change alert to recipients designated in the platform.
The customer can configure recipients by monitored population, program, signal class, source, severity, risk threshold, protected asset, geography, business unit, or other authorized policy. A credential-compromise alert may go immediately to identity security and the insider risk team. A new corporate affiliation may go to personnel security or compliance. A high-confidence change involving a cleared administrator may require counterintelligence, security, privacy, legal, and program leadership.
The alert can contain:
Human review is mandatory.
Reviewers determine whether the observation is correctly attributed, whether the source is reliable, whether policy applies, whether immediate mitigation is required, whether other specialists must participate, whether the score should remain changed, and whether the matter should be closed, monitored, investigated, or escalated.
The same evidence can support different actions:
LightHouse does not determine clearance eligibility, employment status, disciplinary action, criminal liability, or intent. It creates continuous, explainable awareness for the people designated to make those decisions.
- Protect
- rotate credentials, revoke sessions, isolate a device, narrow access, or protect the person from targeting.
- Clarify
- confirm an account, affiliation, role, travel event, or legitimate explanation.
- Investigate
- develop additional internal or external evidence under the approved mission.
- Mitigate
- correct access, remove exposure, address a conflict, apply support, or change a control.
- Monitor
- watch a defined condition for a defined period.
- Close
- record that the observation was false, benign, irrelevant, resolved, or insufficient.
- Escalate
- route a supported matter to authorized personnel security, counterintelligence, HR, legal, privacy, fraud, law enforcement, or leadership.
08 / Governance
Governance for continuous personnel monitoring
Monitoring trusted personnel is a high-consequence mission. The program must protect the organization without treating the workforce as suspects or unrestricted intelligence targets.
Every LightHouse deployment begins with an authorized purpose, defined population, protected assets, permitted sources, role-based access, risk policy, alert recipients, human review, retention, and oversight. Those controls should reflect the customer's applicable laws, regulations, clearance obligations, labor requirements, contracts, privacy commitments, civil liberties, and policies.
Practical controls can include:
LightHouse monitors the existence and security relevance of an observed account, not private message content unless the customer has separate lawful authority, access, and an expressly configured mission. It identifies a credential in an infostealer log as exposure rather than inferring that the employee participated in malware activity.
These distinctions are not footnotes. They are part of the evidence model.
The DCSA continuous vetting model provides a useful public example: automated checks generate an alert, the alert is validated, investigators gather facts, and authorized adjudicators make the trust decision. The US National Institute of Standards and Technology's (NIST) continuous monitoring guidance similarly emphasizes ongoing visibility aligned with organizational risk tolerance and a reporting structure that supports timely, data-driven decisions.
Practical controls
- written enrollment criteria tied to clearance, role, privilege, or protected-asset exposure;
- notice, consent, self-reporting, or workforce engagement where required;
- source permissions and prohibited-source rules;
- data minimization tied to material change and authorized purpose;
- separate handling for customer records, personal data, breach data, and malware intelligence;
- need-to-know access to identity, personnel, and alert information;
- logged monitoring, collection, scoring, routing, review, export, and disposition;
- explicit distinction between an observation, risk signal, assessment, and decision;
- safeguards against decisions based on protected characteristics or lawful protected activity;
- controls for identity collisions, stale data, duplicate sources, and disputed records;
- mandatory human review before consequential personnel action;
- retention, correction, appeal, legal hold, deletion, and unenrollment procedures;
- periodic testing for attribution quality, alert relevance, policy fit, and disproportionate effects;
- independent program oversight and documented change control for risk policy.
Continuous monitoring should make review earlier and evidence stronger, not make judgment automatic.
09 / Measurement
Measure continuous assurance
A continuous insider risk program should be evaluated against the protected mission, the relevance of its alerts, and the quality of its human decisions. The number of people monitored, records collected, or scores changed does not in and of itself establish value.
Start with a baseline from the current process and measure operational, evidentiary, security, and governance outcomes:
The program should reward correct closure as much as escalation. Establishing that a signal is benign, misattributed, or resolved is a security outcome when the evidence supports it.
- Coverage
- What share of the authorized cleared and privileged population has a current, resolved baseline?
- Detection latency
- How quickly is a material change observed after it becomes available through an approved source?
- Identity attribution
- How often are signals correctly matched, rejected, or left unresolved?
- Compromise exposure
- How quickly are infostealer, credential, session, device, breach, and dark-web signals connected to trusted access?
- Alert relevance
- What share of alerts require useful protection, clarification, investigation, mitigation, monitoring, or escalation?
- Incorrect escalation avoided
- How often does added context prevent a benign, false, historical, or misattributed signal from becoming a personnel matter?
- Explainability
- Can reviewers understand every material score change and reproduce the evidence path?
- Recipient performance
- Do alerts reach the platform-designated recipients within the required window, and is review completed?
- Mitigation time
- How quickly are exposed credentials, devices, access, or other correctable conditions addressed?
- Disposition quality
- Does every alert record why it was protected, clarified, investigated, mitigated, monitored, closed, or escalated?
- Proportionality
- Is collection confined to the enrolled population, approved sources, relevant changes, defined retention, and authorized purpose?
- Model quality
- Do identity rules, risk factors, thresholds, and routing improve against validated outcomes without hiding bias or overcollection?
10 / Deploy and operate
Deploy LightHouse around the mission
Continuous insider risk monitoring can enter an organization through three operating models.
Where to start if new to Continuous Monitoring - Start with one bounded population
The strongest pilot begins with a cohort whose access creates a clear consequence: cleared program personnel, privileged administrators, critical developers, executives, sensitive finance roles, contractor operators, or another customer-defined population.
The first objective is not monitoring everyone. It is proving that material change around one trusted population can be detected earlier, attributed correctly, explained clearly, and reviewed responsibly.
- 01
Define
Name the population, protected assets, authorities, permitted sources, risk policy, recipients, review, retention, and outcome.
- 02
Baseline
Resolve enrolled identities, accounts, devices, affiliations, exposure, role, privilege, and known context.
- 03
Connect
Integrate approved IAM, HR, EDR, device, access, travel, threat-intelligence, commercial, and other sources.
- 04
Evaluate
Run known, benign, compromised, malicious, ambiguous, historical, and identity-collision cases.
- 05
Operate
Monitor in a bounded production environment with mandatory review and named owners.
- 06
Learn
Improve identity rules, source quality, risk factors, routing, and controls from validated outcomes.
Selected references
Continuous assurance and responsible review.
- 01
Defense Counterintelligence and Security Agency, Continuous Vetting.
- 02
Performance.gov, Trusted Workforce 2.0.
- 03
National Institute of Standards and Technology, Information Security Continuous Monitoring for Federal Information Systems and Organizations, SP 800-137.
- 04
Cybersecurity and Infrastructure Security Agency, Insider Threat Mitigation Guide.
- 05
Software Engineering Institute, Carnegie Mellon University, Common Sense Guide to Mitigating Insider Threats, Seventh Edition.
- 06
Cyber Safety Review Board, Review of the Attacks Associated with Lapsus$ and Related Threat Groups.
- 07
Google Cloud Mandiant, UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion.
- 08
National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0).
Scope note: This paper describes a general operating approach, not legal, employment, clearance, or investigative advice. Monitoring populations, sources, signals, risk factors, and controls depend on the customer's authorities, deployment, source rights, mission design, and applicable obligations. LightHouse does not guarantee visibility into private accounts or communications and does not make clearance, employment, eligibility, disciplinary, legal, or law-enforcement decisions. Human review is required. Illustrative signals are not customer claims or promised outcomes.