Operational Security: Mission Domain Intelligence Guide

Investigations are compromised by their own footprint far more often than by adversary brilliance. A referrer header, a reused persona, or a document's metadata ends more cases than any counter-intelligence effort.

What Operational Security covers as a mission domain

Operational security in an intelligence context is the protection of the investigation, its personnel, its sources and its subjects from discovery and harm. It covers threat modelling for a specific piece of work, compartmentation of identities and infrastructure, data minimisation and retention, secure communication with sources, publication review for de-anonymisation risk, and post-publication monitoring. The mirror discipline is analytical: recognising where an adversary's own security practice breaks down, because those failures are frequently the strongest attribution leads available.

The domain applies differently by actor. Law enforcement operates under statutory authorisation with defined covert techniques. Journalists and non-governmental organisations rely on source protection and legal privilege. Corporate teams have contractual and regulatory limits but no special powers. All share the same technical exposures: research infrastructure that leaks organisational identity, personas that accrete history, documents that carry metadata, and analytics that report your interest back to the subject.

Why it matters

The consequences of a footprint failure are not abstract. A source in an authoritarian jurisdiction can be arrested. An activist named in a published dataset can lose asylum protection. A researcher can be targeted with commercial spyware or litigation. On the organisational side, a subject who learns they are being examined destroys evidence, moves assets and changes infrastructure, closing the collection window permanently.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Research personas reused across unrelated cases, accumulating a history that links investigations and identifies the employer
Corporate address ranges or organisational referrer headers appearing in a subject's web logs after a routine site visit
Documents published or shared with intact metadata: author names, internal file paths, revision history and geolocation in images
Adversary registration data reusing a personal email address, telephone number or payment instrument from a non-criminal identity
Consistent posting and commit hours across an adversary's accounts, narrowing plausible working timezones over long observation
Profile imagery that reverse-image matches to a stock library, a social account or another persona in an unrelated ecosystem
Subject behaviour changing shortly after a collection action, indicating the collection itself was detected
Targeted phishing, litigation threats or physical surveillance of staff following publication, indicating the investigation drew attention

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

EFF Surveillance Self-Defense — Practical, maintained guidance on threat modelling, secure communication and device hygiene for at-risk users
Access Now Digital Security Helpline — Direct incident support and rapid response for civil society organisations and individuals under threat
Citizen Lab research — Documented commercial spyware capabilities, targeting patterns and forensic indicators against civil society
Amnesty International Security Lab — Forensic methodologies and tooling for detecting mobile compromise in high-risk populations
Freedom of the Press Foundation — Source protection practice, secure drop workflows and newsroom-focused threat modelling
UK NCSC and equivalent national guidance — Baseline organisational security guidance, supply chain principles and incident response frameworks
Tor Project documentation — Accurate description of what anonymity networks do and, importantly, what they do not protect against

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Threat model the specific case — Name the adversary, their plausible capability and what they would do with knowledge of the investigation. Generic policy is not a threat model.
Compartment identities and infrastructure — Separate research personas, devices, payment methods and network egress per case, and never bridge them for convenience.
Minimise and time-bound data — Collect only what the requirement needs, set retention at the outset, and hold sensitive identifiers separately from analysis working files.
Secure source handling — Agree communication channels, code words for duress and contact schedules with the source, and record consent for what may be published.
Review before publication — Run a de-anonymisation review across text, images, metadata and datasets, assuming a determined adversary combines your product with what they already hold.
Monitor and respond after release — Watch for retaliation against staff and sources, keep an incident plan ready, and be prepared to move or support a source at short notice.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Practised with these disciplines

Attack Surface Intelligence — Your Own Exposed Attack Surface
Cyber Intelligence — Adversary Activity in Networks and Systems
Identity Intelligence — Resolving and Verifying Who Someone Is
Breach Intelligence — Exposed Credentials and Compromised Data
Certificate Intelligence — TLS Certificates and Certificate Transparency
Domain Intelligence — Domains, DNS, and Registration Intelligence

Worked in these data points

Email Address — Electronic mail address tied to an individual or organization.
Username / Handle — Screen name or handle used across online platforms and services.
Password / Credential — An exposed password or credential pair from leaks or dumps.
Credential / API Token — An exposed secret — API key, token, or JWT — granting access to systems and data.
Subdomain — A host under a parent domain — often reveals staging, admin, and forgotten infrastructure.
SSL/TLS Certificate — A digital certificate binding a public key to an identity.
Device / Advertising ID — A mobile advertising or device identifier used in adtech data to track and locate devices.

Adjacent mission domains

Inside the platform: where Operational Security lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

domain.php?d=opsec — Operational Security dashboard
theater.php?d=opsec — Threat theater view
email-profile.php — Email Address profile
url-profile.php — Subdomain profile
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

Relevant playbooks

Of the 14 incident playbooks in playbooks.php, these apply directly to Operational Security:

Breach & Credential Exposure — a step-checked workflow with the pivots, sources and handling rules already wired in.
Insider Threat Review — a step-checked workflow with the pivots, sources and handling rules already wired in.
Infrastructure Pivoting — a step-checked workflow with the pivots, sources and handling rules already wired in.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Threat Hunt
Correlate Infrastructure
Run Alert Rules
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Threat model the specific case is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Minimise and time-bound data turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Monitor and respond after release feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Operational Security

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Operational security is doctrine in defence, applied here to the intelligence function itself: protecting collection methods, analyst identities, research infrastructure and the fact that a particular question is being asked. Analysts apply the classic cycle of identifying critical information, analysing threats and vulnerabilities, assessing risk and applying countermeasures. It supports force protection by controlling the indicators that deployment, exercise and procurement activity generate, and it governs what appears in unclassified products. Constraints include the requirement to reconcile operational security with mandated transparency, and the discipline that countermeasures must be proportionate or they will be quietly abandoned by the people expected to follow them.

🕵 National intelligence

For national services this is the protection of sources, methods and equities. It covers compartmentation, cover for collection activity, control of digital footprint, and the handling rules that stop a releasable product revealing how something was learned. The practical work is indicator analysis: what does our own activity emit, who can observe it, and what would they infer. Counterintelligence assessment of the adversary's collection capability drives the countermeasures chosen. Failures are usually cumulative rather than singular, arising from small conveniences repeated over time, which is why audit and periodic re-baselining matter more than one time hardening.

👮 Law enforcement

Policing applies this to covert operations, source protection and the integrity of investigations. Undercover identities, technical deployments and the existence of an operation all require protection, and disclosure obligations mean the methods will eventually be examined in court. Authorisations must be in place and documented, since covert activity without proper authority is both unlawful and fatal to a prosecution. Practical concerns include preventing an investigation being revealed by a records check, a vehicle registration, a badge access log or an ill considered social media post, and ensuring that protected source material is handled through the correct disclosure regime rather than inadvertently released.

🔍 Private investigation and corporate security

Private investigators face the same exposure with fewer protections and no covert powers. The realistic objectives are protecting the client relationship, the investigator's identity where lawful, and the integrity of evidence. This is not permission for deception: pretexting to obtain personal data, impersonating officials and unauthorised surveillance are offences in many jurisdictions regardless of client instruction. Sound practice covers segregated research infrastructure, avoiding footprint that alerts a subject, secure client communications and disciplined document handling. Reports and metadata should be sanitised before release, since embedded properties have repeatedly revealed a client's identity in litigation.

📰 Journalism and OSINT media

Newsroom security protects sources, unpublished material and the story itself. The threat model must include legal compulsion, device seizure at borders, targeted spyware, hostile platform reporting and simple observation of who a journalist meets. Practical measures include compartmented communications with sources, minimal metadata retention, encrypted storage, and deciding in advance what will be kept and for how long. Publication itself is an operational security event: detail included to demonstrate rigour can identify a source through timing, phrasing or access. Editors should run a source risk review before publication as a standing process rather than at the reporter's discretion.

🌍 NGO, humanitarian and human rights

Human rights and humanitarian organisations often face state adversaries with far greater capability and staff who are not security professionals. Practice must be usable: simple, rehearsed measures that people will actually follow beat sophisticated ones they will not. Protecting the identities of witnesses, beneficiaries and local partners is the priority, including in datasets that appear anonymised but can be re-identified. Do no harm requires thinking about what documentation exposes if seized. Duty of care includes travel security, device hygiene at borders, and preparing staff for arrest or interrogation. Incident planning should include what to do when a partner is detained holding organisational data.

🎓 University and research

Researchers working on sensitive subjects need protective practice for participants, data and themselves. Ethics approval should address re-identification risk, secure storage, data transfer across borders and what happens if material is subpoenaed or a device is seized. Anonymisation is harder than it appears in small populations, so aggregation and controlled access archives are usually more protective than redaction. Fieldwork requires a documented risk assessment covering the researcher and local collaborators, who often carry the greater risk. Publication should consider whether method detail exposes participants, and pre-registration should not inadvertently reveal where fieldwork is taking place.

Playbook: working Operational Security end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Define what must be protected

Identify the critical information for this specific piece of work: the subject's identity, the fact of the investigation, source identities, methods, timing and the client. Be concrete rather than listing categories. Everything cannot be protected equally, so rank. A good output is a short list that an analyst can hold in mind, because a document nobody remembers protects nothing when someone is deciding whether to send one convenient message.

Phase 2 — Model the specific adversary

Ask who would want to know, what they can observe, and what they could do with it. A well resourced state, a criminal group with corrupt access, a litigious corporation and a determined individual present very different capabilities. Base the model on evidence about the actor rather than worst case imagination, because countermeasures calibrated to an imaginary adversary get abandoned. The output states the assumed capability explicitly so it can be challenged and revised.

Phase 3 — Enumerate your own indicators

List what your activity emits: queries against registries, visits to a subject's website, domain lookups, subscriptions, professional network views, travel bookings, meeting patterns and procurement. Include the indicators generated by colleagues and by the organisation itself. Most exposure comes from aggregation of individually harmless signals. A good output maps each indicator to who could observe it and what they would infer.

Phase 4 — Build compartmented infrastructure

Separate identities, devices, networks and accounts by workstream, so a compromise exposes one thing. Use dedicated machines or virtual machines, distinct egress, and no shared identifiers, payment methods or recovery contacts. Document the build so it can be reconstituted. The output is an infrastructure map showing which identity touches which system, which is also what you review when deciding whether a new task can safely use existing assets.

Phase 5 — Set handling rules before collection

Decide in advance where material will be stored, who may access it, how it moves, how long it is kept and how it is destroyed. Include the awkward cases: material that must be retained for evidence, material that is illegal to hold and must be referred, and material whose existence is itself sensitive. A good output is a handling annexe to the collection plan, agreed with counsel where the work may end up in proceedings.

Phase 6 — Control the human layer

Brief everyone involved, including support staff, on what may be discussed, with whom and where. Most exposure runs through people rather than technology: a conversation in an open office, a calendar entry with a subject's name, a helpful colleague answering a phone enquiry. Establish a cover story for routine questions and a single point for external enquiries. The output is a briefed team that behaves consistently under casual pressure.

Phase 7 — Sanitise products before release

Strip metadata, check embedded revision history, remove file paths and author names, and review images for identifying detail. Consider what the combination of facts reveals about how you learned them, since a single date or phrasing can identify a source to someone inside the organisation being reported on. A good output is a release checklist applied by someone other than the author, because authors cannot see their own footprint.

Phase 8 — Assess third party and vendor exposure

Every tool, subscription and cloud service knows what you searched for and when. Assess whether a provider is subject to disclosure demands, whether queries are logged and shared, and whether a subject could be notified. Some commercial data providers alert subjects to searches. The output is a register of which tools are safe for which sensitivity level, and a documented decision where you accept the residual risk.

Phase 9 — Rehearse compromise

Decide in advance what happens if an identity is burned, a device is seized, a colleague is detained or the investigation becomes public. Who is told, in what order, what is preserved, what is destroyed lawfully, and what support the affected person receives. Practise the notification path once. A good output is a one page plan people can follow while frightened, which is the only condition under which it will ever be used.

Phase 10 — Protect subjects and sources deliberately

Where the work involves human sources, victims or vulnerable subjects, their safety outranks the investigation. Agree what they consent to, what will be published, and what could identify them indirectly through detail, timing or the small size of the population they belong to. Provide a way to withdraw. The output is a documented consent and risk position for each person, revisited before publication rather than assumed to hold.

Phase 11 — Audit and re-baseline

Operational security decays through convenience: a quick search on the wrong machine, a reused password, an identity kept past its useful life. Schedule periodic reviews that check actual behaviour against the plan, not stated intentions. Rotate identities before they are burned. A good output is a review that finds and fixes real drift, which requires a culture where reporting a mistake early is rewarded rather than punished.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
Berkeley Protocol on Digital Open Source Investigations	Open	Standards covering method, preservation, security and welfare for open source investigators in accountability work.	Framework for protective practice where investigations may support legal proceedings. Also covers analyst welfare, which most security guidance omits.
Citizen Lab research	Open	Technical documentation of targeted surveillance, spyware and threats to civil society organisations.	Evidence based threat modelling for organisations facing state linked surveillance. Reports include indicators that individuals can check on their own devices.
Access Now Digital Security Helpline	Open	Support service and guidance for civil society organisations and individuals facing digital threats.	Referral route and practical guidance for at risk staff, partners and sources.
Electronic Frontier Foundation Surveillance Self-Defense	Open	Practical guidance on threat modelling and protective tools for a range of adversary capabilities.	Accessible baseline material for briefing non technical staff and partners. Written for non specialists and translated into several languages.
Committee to Protect Journalists safety resources	Open	Physical, digital and psychological safety guidance developed for reporters in hostile environments.	Practical measures for journalists and for organisations sending staff into risky settings.
Reporters Without Borders safety guidance	Open	Country risk information and protective guidance for journalists and media organisations. Includes an annual index of press freedom conditions by country.	Country level context when assessing threat to staff, sources and partners. Useful when planning travel and deployment for at risk staff.
NCSC UK guidance	Open	National technical guidance on device hardening, secure communications and organisational security practice.	Authoritative baseline controls for research infrastructure and staff devices. Written for organisations rather than for specialists alone.
NIST Cybersecurity Framework and SP 800 series	Open	Control catalogues and risk management guidance applicable to research and investigative infrastructure.	Structuring protective controls in a form auditors and clients recognise. Also useful when a client or insurer asks for a control framework.
Tor Project documentation	Open	Technical documentation on anonymity properties, limitations and correct configuration of the network.	Understanding what anonymity tooling does and does not protect against for a given adversary.
Front Line Defenders protection resources	Open	Security planning material for human rights defenders including risk assessment and incident response.	Protective planning with partners and local defenders who face the highest exposure.
Amnesty International Security Lab	Open	Forensic research on targeting of civil society and guidance on detecting device compromise.	Referral route and method reference where staff or sources may have been targeted.
Data protection authority guidance	Open	Regulatory guidance on lawful basis, minimisation, retention and security of personal data in investigations.	Ensuring protective practice also satisfies legal obligations around personal data. Also defines retention limits for material gathered during investigations.
OSSTMM and open testing methodologies	Open	Structured methodologies for assessing security controls, including operational and human factors. Covers testing of physical, human and process controls as well as technical.	Framework for testing whether protective measures work as intended rather than as documented.
Have I Been Pwned	Open	Index of credentials and accounts exposed in known breaches, searchable by address or domain.	Checking whether identities or staff accounts used for research are already exposed.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Operational Security. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

Dedicated virtual machines or hardware per workstream — Isolates identities and reduces cross contamination. Limitation: discipline collapses when analysts move between machines under time pressure.
Tails or Whonix — Amnesic and Tor forced environments for high risk collection. Limitation: usability friction encourages fallback to convenient but unsafe setups.
Password managers with per identity vaults — Prevents credential reuse across compartmented identities. Limitation: a single compromised master vault collapses the entire compartmentation model.
Metadata scrubbing utilities — Removes author, revision and location data before documents or images are released. Limitation: does not address content that identifies a source by inference.
Encrypted messaging with disappearing messages — Protects source communication content and limits retained history. Limitation: metadata about who contacted whom may still be visible to the platform or network.
Full disk encryption and hardware security keys — Protects data at rest and hardens authentication against phishing. Limitation: offers little protection against a live compromised device or legal compulsion.
Search and browse isolation services — Prevents research activity revealing organisational identity to visited sites. Limitation: some providers log queries and may be compelled to disclose them.
Mobile device forensic support services — Detects targeted spyware on devices of staff or sources. Limitation: negative results are not proof of safety, and specialist labs have limited capacity.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
Run Alert Rules — Evaluates saved rules against new data so a first sighting raises a notification rather than waiting for review.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Aggregation is the real exposure. Individually harmless signals such as a registry query, a website visit and a travel booking combine into a clear picture of what you are investigating and when you started.
Countermeasures that are hard to follow do not exist. Choose the simplest measure that defeats the modelled adversary, because a rule people quietly abandon is worse than a weaker rule they actually apply.
Publication is an operational security event. The detail added to demonstrate rigour is frequently what identifies a source, since only a handful of people had access to that particular fact on that particular date.
Your tooling is a witness. Commercial data providers log queries, some notify subjects, and several are subject to disclosure demands, so assess each tool against the sensitivity of the work before use.
Rotate identities before they are burned rather than after. An identity kept past its useful life becomes the link that connects unrelated workstreams when someone eventually investigates you.
Rehearse the compromise, not just the prevention. People perform badly when an identity is exposed or a colleague is detained, and the difference between a bad day and a disaster is a one page plan that was practised once.
Reward early reporting of mistakes. Most serious exposures develop from a small error that was concealed for a week, and no technical control compensates for a culture that punishes admitting one.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Operational Security is producing anything, and they are worth baselining before you change process or tooling.

Proportion of workstreams with a documented threat model and compartmentation plan completed before collection began.
Findings per periodic audit of actual behaviour against the plan, trending down as drift is addressed rather than concealed.
Time from an operational security incident occurring to it being reported internally, which measures culture more reliably than incident counts.
Percentage of published products that passed an independent sanitisation check before release. Checks performed by someone other than the author of the product.
Identity lifespan against planned rotation schedule, with reasons recorded for any identity retired early. Early retirement for cause is a healthier signal than long lifespans.
Number of source or subject safety reviews completed before publication, as a proportion of products involving human sources.
Staff completion and retention of security briefings measured by practical exercise performance rather than course attendance.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Assuming a virtual private network provides anonymity, when it relocates trust rather than removing identifying behaviour
Reusing a persona or infrastructure because rebuilding is inconvenient, which links every case it has ever touched
Over-collection creating a liability store: data you did not need, cannot justify holding and must disclose if compelled
Publishing detail that seems innocuous alone but uniquely identifies a source when combined with what the adversary already knows
Treating the source's risk as ending at publication, when consequences for them typically begin there
Inconsistent legends: a persona whose stated location, language register and activity hours contradict each other invites scrutiny

Legal and ethical considerations

Deception has different limits for different actors. Covert techniques and undercover engagement are statutorily regulated for law enforcement and generally unavailable to private organisations, and breaching platform terms is not automatically a criminal matter but can undermine both evidence and reputation. Data minimisation and purpose limitation are practical protections as well as legal obligations. Where a source may face criminal or immigration consequence, duty of care and legal advice should precede collection rather than follow it.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Operational Security, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 6 intelligence disciplines, 7 data points, 4 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

How much operational security is proportionate for a routine investigation?

Match the measures to a modelled adversary rather than to anxiety. For a corporate due diligence subject with no investigative capability, segregated research infrastructure and metadata hygiene are usually sufficient. For a subject with state backing, corrupt access to official records or a history of retaliating against reporters, the requirement rises steeply and includes compartmented identities, controlled communications and a compromise plan. Write the assumed adversary capability down so the level of protection can be reviewed and justified, and revisit it if the investigation turns out to involve someone more capable than expected.

Does using a virtual private network make research anonymous?

No. It relocates the visible network origin and nothing more. The provider sees the traffic and may log it, browser and device fingerprinting still identify a returning visitor, account logins immediately deanonymise a session, and behavioural patterns such as timing and language give a great deal away. Against a capable adversary a VPN offers weak protection; against a website owner checking who visited, it helps. Treat it as one control within a compartmented setup that also addresses accounts, browser profile, payment method and behaviour, not as a solution in itself.

What should we do if an investigator's identity is exposed?

Follow the rehearsed plan. Stop activity on that identity immediately, preserve what is needed, and assess what the exposure reveals about other workstreams and about sources. Notify affected sources and subjects if their safety is implicated, which usually outranks the investigation. Consider whether the individual faces a physical or legal risk and provide support, including relocation or legal advice where warranted. Then conduct a review that identifies how the exposure occurred without punishing the person who reported it, since punitive handling guarantees that the next exposure is concealed.

Is anonymised data actually anonymous?

Frequently not, particularly in small populations. Combinations of location, date, role and demographic detail re-identify individuals with surprising ease, and published datasets have been re-identified repeatedly. For investigative and human rights work, prefer aggregation, controlled access archives and deliberate coarsening of detail over field level redaction. Test re-identification actively by asking whether someone with local knowledge could name a person from what remains. Where a dataset concerns people at risk, the safe default is not to publish the underlying data at all and to publish findings with a documented methodology instead.

How do we protect sources from being identified through the story itself?

Run a source risk review before publication as a standing step. Ask which facts only a small number of people had access to, whether timing narrows the field, whether phrasing reflects a particular person's role, and whether the sequence of enquiries you made already pointed at them. Consider deliberately blurring detail, delaying publication, or attributing to a broader category. Discuss the residual risk with the source honestly, including that you may not be able to protect them entirely, and record their informed decision before proceeding.

What is the most common failure in practice?

Convenience under time pressure. A quick search on a personal machine because the research environment was slow, a message sent on a normal channel because the secure one was awkward, an identity reused because creating a new one takes an afternoon. These are not knowledge failures; the person knew better. The corrective is to make the secure path the fast path, to build in enough capacity that people are not choosing between security and a deadline, and to audit actual behaviour rather than surveying stated practice.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

Berkeley Protocol on Digital Open Source Investigations, covering security, preservation and welfare for investigators.
ISO/IEC 27001 information security management, providing the control framework for organisational research infrastructure.
NIST Cybersecurity Framework, used to structure and communicate protective control maturity.
GDPR and equivalent data protection regimes, governing lawful basis, minimisation, security and retention of personal data held during investigations.
Regulation of Investigatory Powers style frameworks, which define what covert activity requires authorisation and who may conduct it.
Do No Harm principles in humanitarian practice, requiring assessment of the consequences of documentation and publication.
Traffic Light Protocol version 2.0, governing how sensitive material is shared and redistributed.
Professional codes on source protection in journalism, including the legal protections and their limits in each jurisdiction.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Berkeley Protocol on Digital Open Source Investigations — UN Office of the High Commissioner for Human Rights. Standards for secure and rigorous open source investigation.
Surveillance Self-Defense — Electronic Frontier Foundation. Practical threat modelling and protective guidance for individuals and organisations.
Targeted surveillance research — Citizen Lab, University of Toronto. Technical documentation of spyware targeting civil society and journalists.
Digital Security Helpline — Access Now. Support service for civil society facing digital threats and device compromise.
Journalist safety resources — Committee to Protect Journalists. Digital, physical and psychological safety guidance for reporters.
Security guidance for organisations — National Cyber Security Centre UK. National technical guidance on device, network and organisational security.
Security Lab research and support — Amnesty International. Forensic investigation of targeted surveillance against civil society.
Guidance on personal data in investigations — Information Commissioner's Office. Regulatory guidance on lawful handling of personal data.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: hardens research infrastructure and reviews products for footprint and de-anonymisation risk before release. Explore the platform, or browse the rest of the library by following any tag above.