Klarvant Digital Governance Analyst bronze
demo.nc.klarvant.com
“Tracks PQC migration, monitors supply-chain risk and surfaces external exposure across your namespace, backed by audit-ready compliance evidence, putting Digital Governance Intelligence at your fingertips. Agent-native, it requires zero integration and delivers results from day 1.
https://demo.nc.klarvant.com/.well-known/agent-card.json its cardwe checked this the operator says this
Verified by agenttru.st
Everything here is a check agenttru.st performed itself. Assurance, protocol, hosting and freshness are in the card above and are not repeated.
- Certificate
-
Issued by Google Trust Services
domain-validated
Valid until 8 Jan 2027 as of our check on 12 Nov 2026.Control of the hostname was checked; nothing about who operates it.Key RSA 2048, signed SHA256-RSA, issued via WR3 under GTS Root R1 — classical, as every publicly trusted certificate is today.
Names on this certificate (2)
demo.nc.klarvant.com,demo.api.klarvant.com. - Connection
- TLS 1.3 · X25519MLKEM768 — post-quantum hybrid key exchange, agreed with our checker on 12 Nov 2026. What this means
- DANE / TLSA
- Not verified (TLSA query returned RCodeNameError)
- Discovery
- Well-known document
- First seen
- 15 Oct 2026
View verification details
- Assurance
- bronze Bronze — agent card fetched over HTTPS with a valid certificate
- Protocols
- A2A verified by handshake or card fetch, not merely advertised
- Hosted in
- 🇺🇸 US · Google LLC (AS396982)
- Last checked
- 2d ago
What this agent says it can do
Declared in the agent's own card. agenttru.st has not tested whether it completes any of these tasks — the operator of demo.nc.klarvant.com controls every word below.
Brand exposure summary
USE THIS for any question about BRAND EXPOSURE OUTSIDE THE MANAGED ESTATE — "any brand threats?", "is anyone impersonating us?", "what lookalike domains are out there?", "which shadow assets look like ours?", "what is on the watch list?", "how many names have we claimed?". One call returns the summary the portal's External Discovery Dashboard shows: open cases by queue and priority band, the analyser's verdict distribution, the highest-scoring shadow-asset and impersonation candidates, the watch list and its capacity, the claimed and closed counters, and the monitoring coverage figures. DO NOT IMPROVISE THIS ANSWER from other surfaces. A dangling DNS record and a parked page are not brand findings, and answering a brand question from them reports a different dataset under the brand's name. TWO QUEUES, TWO QUESTIONS. The shadow queue asks "is this ours?" and is ranked by ownership_score; the threat queue asks "is this hostile?" and is ranked by threat_score. They are different scales on different questions
- Are there any brand threats?
- Which shadow assets look like ours?
- What is on our brand watch list?
Certificate posture
USE THIS to answer "what is our certificate posture?" or "which certificates are expiring / expired?". Returns a summary at the latest completed scan (org-wide, or narrowed to the org_units you pass) PLUS a worst-first list (soonest to expire, already-expired first). summary (ignores the LIST filters — cert_type, expiring_within_days, include_expired, issuer_contains — but IS narrowed by org_units, so summary and list always describe the same population): total, expired, expires_7d, expires_30d, expires_90d (CUMULATIVE — expires_30d includes the expires_7d cohort), valid, self_signed, wildcard. THE EXPIRY WINDOWS RUN FROM TODAY, OVER THE ASSESSMENT'S CERTIFICATES. expired, expires_7d, expires_30d, expires_90d and every days_to_expiry are measured against the current clock; the certificates they are measured over are the ones the latest completed assessment recorded. So say "counted today" for the countdown and "at your latest assessment" for the population — "of the certificates at your latest asses
- What is our certificate posture?
- Which certificates expire in the next 30 days?
- How many certificates have already expired?
CVE exposure summary
USE THIS FIRST for any question about the CVE feed — "how many CVEs were published today / this week?", "how many are known-exploited?", "what was matched to us yesterday?", "has anything landed against our vendors?". One call returns the per-UTC-day series and the organisation's all-time totals, so a week's answer needs no paging. THREE TIERS, AND THEY NEST. published is every CVE that reached the catalogue that day. screened is the band the linker evaluates — known-exploited, or CVSS 7.0 and above, or EPSS 0.36 and above, or not yet scored but rated high or critical by its publisher (Chrome, Drupal or Apache). linked names one of this organisation's suppliers, products or technologies. Everything below the screened band is never evaluated, so published minus linked is NOT "checked and cleared"; say which tier each figure is. "SO FAR" MATTERS. Date every figure by as_of (the catalogue head) and say "so far" on the day marked partial — published, screened and linked can all still rise as the day's ing
- How many CVEs were published today, and how many name our suppliers?
- What was linked to us this week?
- How many known-exploited CVEs name our technologies?
What changed since the previous assessment
USE THIS for any question about CHANGE OVER TIME on this organisation's estate — "what changed since the previous assessment?", "what has moved since the last scan?", "which findings opened or closed?", "how has the estate changed?". It is the only tool that windows THIS ORGANISATION'S OWN ESTATE: the CVE and dependency tools take windows too, but those window the global publication feed, not your assessments. The window it takes is an ASSESSMENT BOUNDARY rather than a calendar bucket, so an answer can say "since the assessment that completed on 26 August 2026" instead of "since August". IT CANNOT MEASURE A CALENDAR PERIOD. Every anchor — "previous_assessment", an identifier, even an RFC3339 timestamp — resolves to a completed assessment, and a timestamp snaps BACK to the newest assessment at or before it. So "what is new this week?" or "what changed in August?" is answered over the two assessment boundaries, which may be three days apart or ten. That is the right answer, and it is a DIFFERENT window f
- What changed since the previous assessment?
- What has moved since the last scan?
- Which findings opened or closed since we last looked?
Describe org
CALL THIS FIRST in a fresh session — before any other tool. Returns a rich one-call overview of the organisation: name, last scan timestamp, domain count, org-unit names, active supplier count, live gap category vocabulary, live finding-type vocabulary, canonical enum lists (criticalities, statuses, evidence types), per-surface row counts, your entitlement scopes, and static caveats about data coverage. This single free call tells you everything you need to make well-formed subsequent tool calls — particularly the LIVE categories[] and finding_types[] for ncc_search_gaps, and the surfaces_with_data map so you know which inventory surfaces are populated before running ncc_list_inventory. For resolved or state="all" gap searches, ALSO use resolved_categories[] and resolved_finding_types[] — the active-only categories[]/finding_types[] do not cover vocabulary seen only in resolved findings (e.g. a resolved-only category like Web or finding type like CONTENT). Fields are scope-gated to your key's read sco
- Describe my organisation
- What does this platform monitor for us?
- How big is our estate?
Email security posture
USE THIS for EVERY question about mail posture — "how many of our domains handle mail", "how many are fully protected", "are we enforcing DMARC", "what share of our mail domains enforce", "do we publish MTA-STS or TLS reporting", "who provides our email", "which registrations are defensive only". It returns the Email Security dashboard's OWN aggregate in one call, at the latest completed assessment, org-wide or narrowed to the org_units you pass. NEVER BUILD A MAIL FIGURE BY PAGING ncc_list_inventory kind="email_spf" / "email_dmarc" / "email_mx". Those return ONE PAGE of rows (25 by default) and no population total, so a count taken from them is the page size wearing an estate's name — that is a measured failure on this surface, not a hypothetical one. Read the totals here and use the inventory only to NAME domains. THREE DENOMINATORS RIDE IN THIS PAYLOAD AND THEY ARE NOT INTERCHANGEABLE. Say which one every figure is on: - funnel.any_email_signal — the EMAIL UNIVERSE: every current domain carrying
- How many of our domains handle mail, and how many are fully protected?
- Are we enforcing DMARC?
- Who provides our email?
Explain dependency relevance
USE THIS to answer "why is this domain / estate relevant to this dependency event?" for YOUR organisation. Returns the typed eligible PATHS behind the touchpoints: for each path the subject, the operational class, the touchpoint_count, and the eligibility_reason (the exact policy rule that admitted it) — plus the graph_generation vector so the calculation is reproducible. Relevance is a union of typed, policy-eligible paths, each admitted only by the event's explicit scope and the eligible relationship kinds — NEVER by a shared vendor name (no vendor→product transitivity). If the estate has no eligible path the answer is empty with coverage_note "no observed dependency in monitored evidence" ("closed: the source withdrew or rejected the advisory" when the source has withdrawn or rejected an advisory that was relevant). This is the claim-safe "why is this here" explanation — it never says you are affected or vulnerable. Requires scope read:cve-exposure. Pass event_id. Deterministic invocation: send a
- Why does this advisory matter to us?
Gap resolution metrics
USE THIS for any question about REMEDIATION PROGRESS or the SHAPE of the finding backlog — "are we getting better?", "how fast do we fix things?", "what has changed since the last assessment?", "how many findings are ageing?", "what is our resolution rate?". It returns the platform's own dashboard aggregate in one call, so on any organisation with open findings it agrees with the portal's gaps dashboard exactly. One deliberate difference, on an estate with NOTHING open: risk_posture_pct, critical_coverage_pct, resolution_rate_30d_stock and severity_health_pct read 100 here, where the page leaves all four at 0 — see the clear_estate basis entry. NOT a way to list findings. It returns counts and rates, never rows. To name the individual findings behind any figure here, call ncc_search_gaps with the matching filters. POPULATION: every headline figure counts OPERATIONAL findings only (findings on live assets — the population every portal gaps page and the posture rating show). Parked and defensive registr
- How are we doing at fixing findings?
- What is our mean time to resolve?
- How many findings appeared since the last assessment?
CVE record
USE THIS to read ONE CVE by identifier: title, description, publication and update dates, the effective CVSS score with its source, the exploitation signal, EPSS, the CISA known-exploited block with its due date labelled as US federal guidance, the weakness ids, the products the record names, each with the status the record gives it, and the references. PRODUCTS THE RECORD NAMES. products_named_by_source lists the vendor / product entries of the record, whatever the record says about them: a record also names products it states "unaffected", so never report a product as affected because it is in the list. Each entry's status is what the record itself states about that product — never a verdict of the platform and never a statement about this organisation (in_your_estate answers that, and a subject can be linked through another product of the same record): "affected" (the record states at least one version "affected"; versions carries the ranges), "unaffected" (the record states the product "unaffected" for
- What is CVE-2026-12345?
- Is CVE-2026-12345 known to be exploited?
- Does that CVE name anything we run?
Get dependency event
USE THIS after ncc_list_dependency_events to read one dependency event in full: the header (type, title, summary, lifecycle axes, exploitation + source + as_of, severity + source), its EXACT subjects, its members (the CVEs / KEV entries / advisories it clusters, capped), and its revision history (capped). A GLOBAL source fact — never an assertion about your organisation. Pass event_id from a list row. Deterministic invocation: send a message whose single part is application/json data shaped {"tool": "ncc_get_dependency_event", "args": {…}} to execute this skill directly without the LLM; the reply is a structured data part.
- Tell me more about that advisory
Get gap
USE THIS after ncc_search_gaps to read one finding's full evidence. Wire fields: long_description, vulnerability_description, remediation_description, non_technical_description, and raw_evidence (structured JSON the platform captured at scan time — NOT stringified); terminal-status rows additionally carry resolution_notes (on accepted-risk rows: the acceptance justification; NEVER on dismissed rows — the dismissal justification stays in the portal's Activity Ledger), accepted_at (Accepted Risk rows), dismissed_at (False Positive rows, 4.10.0), resolved_at (resolved rows — exactly one of the three per terminal row), status_changed_by (who made the transition — a display name or "platform") and review_due_at (Accepted Risk rows: the re-review date, default acceptance + 12 months; a past date = review overdue, but the platform never auto-reopens). Pass gap_id from a ncc_search_gaps row. IDENTIFIER — READ THIS. gap_id is the per-INSTANCE UUID carried on every ncc_search_gaps row (also in that row's nex
- Tell me more about that finding
- Show me the detail for this gap
Web page detail
USE THIS to describe ONE web page — "describe www.example.com", "what is on that page?", "tell me about https://login.example.com/". It returns that page's inventory row (the analyser's reading of the page, its classifications, rating, capture state and metadata) plus whatever you expand with include. NAME THE PAGE ANY OF THREE WAYS, and you must pass exactly one: page_id, the hex SHA-256 carried on every ncc_list_inventory kind="web_pages" row and the id in GET /web/pages/{page_id}; host, an FQDN; or url, one exact page address. You will usually hold a host and not an id — an id can only come from a listing. A host that carries SEVERAL live pages is not resolved to one of them: the reply lists the pages it holds so you can ask again for the one that was meant. Report that list, never pick from it silently. detail="summary" (the default) carries every classification the platform placed on the page, each with its confidence and its is_primary flag, plus the rating and the capture state — so a "what is
- Describe the page at www.example.com
- What is on https://login.example.com/?
- Tell me about that page
Impact search
USE THIS FIRST when the user names a supplier, vendor, product, cloud or DNS provider, certificate authority, analytics tag, hosting provider, third party, or any single term and asks where the organisation is exposed. Examples: "where are we exposed to Google?", "do we use Cloudflare?", "find AWS", "show Microsoft dependencies", "search for Okta", "are we running Stripe?". Extract the BARE term — for "where are we exposed to Google?" pass query="google", NOT the full sentence. The server matches case-insensitive substrings across multiple resource families and groups the hits by SURFACE and EVIDENCE TYPE so the user can see exposure channels at a glance. Surfaces (pick a subset to narrow): suppliers, dns_records, certificates, ip_infrastructure, web_technologies, web_content, web_headers. Evidence types are the platform's own labels for what kind of hit it is — MX/SPF/NS/SOA/TXT for DNS records, ISSUER or SUBJECT for certificates, ASN/HOSTING for IPs, TECHNOLOGY for JavaScript, PAGE_TITLE/AI_SUMMARY/CO
- Where are we exposed to Cloudflare?
- Do we use Okta anywhere?
- Which of our assets touch this vendor?
Ip footprint
USE THIS for any question about WHERE the organisation's IP addresses are — by country, by hosting provider / ASN, or for data-residency. It returns the platform's own aggregates rather than a tally of rows: the totals and the two rankings are the IP Inventory dashboard's own figures, measured on its own sample pin, and residency{} is the Sovereignty dashboard's own query — which also supplies the country rows' latest-assessment counts wherever that pin cannot answer, countries_latest_scan_basis saying which of the two gave them. Both read the SAME completed assessment and, at rest, the same addresses within it. So an unfiltered answer here agrees with both pages it came from — but org_units narrows everything here, so a filtered answer is not comparable with an unfiltered page. NEVER answer a distribution question by tallying rows from ncc_list_inventory kind="ips". That is a page — 25 rows of a footprint in the hundreds — and counting it produces a plausible table of the wrong thing — a ranking
- Which countries are our IP addresses in?
- Who hosts our infrastructure?
- What is our IP footprint?
Pages in a layout cluster
USE THIS to open ONE visual-layout group returned by ncc_list_page_clusters and see the pages in it. Pass the cluster_id from that reply VERBATIM together with the SAME similarity — a cluster identifier is only meaningful at the threshold it was computed at, so drilling at a different threshold answers about a different grouping under the identifier you were shown. Per page: url, host, namespace, category, rating, thumb_url, screenshot_url and last_seen_at. READ total, NOT the length of pages[]. total is the group's FULL membership; the served list is capped by the platform and truncated says the two differ. "How many pages look like this" is total, always. For the groups themselves use ncc_list_page_clusters; for one page's full detail use ncc_get_web_page. Deterministic invocation: send a message whose single part is application/json data shaped {"tool": "ncc_list_cluster_pages", "args": {…}} to execute this skill directly without the LLM; the reply is a structured data part.
- Which pages are in that cluster?
- Show me the pages that look like that one
- List the members of the biggest visual cluster
CVE subjects
USE THIS for "which vendors / technologies / products carry the most CVEs?", "who has the most known-exploited?", "which of our subjects has nothing linked?". Returns this organisation's own footprint of suppliers, products and technologies, each with the published CVEs LINKED to it in exclusive severity bands. COUNT UNITS DIFFER BY KIND and the tool says which on every row: a supplier's estate_count is primary domains (for a vendor group, its largest member's count — a lower bound), a technology's is fully-qualified names, a product's is hosts. Never present all three as "domains", and never add subject counts together — the same software can appear as both a supplier and a technology, and the organisation-wide totals in ncc_cve_exposure_summary count distinct CVEs and are never the larger figure. ONE ROW PER VENDOR AND PER DEPLOYED PRODUCT. A vendor's supplier domains are one subject, keyed by the vendor group; a product the organisation also holds as a technology is listed as that technology. A suppl
- Which of our vendors have the most CVEs?
- Which technologies carry known-exploited CVEs?
- Which suppliers have no CVEs linked at all?
List dependency events
USE THIS to browse the GLOBAL Dependency Response catalogue: clustered supplier / service dependency events (advisories, incidents, outages, campaigns) about an EXACT product, service, or organisation. These are typed source facts and NCC-observed clusters — NOT vulnerability findings and NOT claims about your organisation. Each event carries: event_type, title, summary, the three lifecycle axes (attention_state new/elevated/quiet/archived · source_state published/updated/withdrawn/… · remediation_state, always source-attributed), exploitation (exactly known_exploited / poc_reported / exploitation_signal_unknown — never "active"/"none"), severity_max (+source), the EXACT subjects (product/service/component), member_counts, and timestamps. Filters: attention_state, event_type, exploitation, updated_after (RFC3339). limit + cursor page the list. This is the org-INDEPENDENT catalogue (scope read:cve). To see which of these touch YOUR estate use ncc_list_dependency_reviews — it answers for the whole e
- What advisories affect our software?
- Show me critical dependency events
List dependency reviews
USE THIS FIRST for "do we have any CVE matches", "which advisories touch us", "what should we review" — it answers in ONE call. Returns THIS organisation's MATCHED dependency events: relevance state, review state, the source's severity_max, exploitation (the three source-attributed values), attention_state, when the match opened, and touchpoint_counts broken down by class. Filters: min_severity (the source's score, e.g. 9), exploitation, state (open/closed), matched_since (RFC3339). The result is SUMMARY-FIRST: open_total, counts_by_severity_band, count_known_exploited and count_matching_filters come before the rows, so a filtered query that matches nothing still tells you how many remain open — "nothing today" must never read as "nothing at all". SAY THE BAND BY ITS OWN NAME. counts_by_severity_band keys the SOURCE's score band, and each band is one severity, not a pair: 9.0_and_above is Critical, 7.0_to_8.9 is High, 4.0_to_6.9 is Medium, below_4.0 is Low, and unscored means the source published no sco
- What is in our review queue?
- Which advisories are still open for review?
List dependency touchpoints
USE THIS to list YOUR organisation's typed dependency touchpoints for one event: the locations to review — an MX host, a CNAME, a nameserver, a certificate authority, a detected product — where the monitored estate meets the event's exact subject. A touchpoint is a LOCATION TO REVIEW, never a vulnerability finding, a compromise finding, or a patch-state verdict. Each touchpoint carries: the operational class (runtime_delivery / dns_control / mail / administrative_control / trust_lifecycle / detected_software / client_content), the subject, the eligibility_reason (which policy path admitted it), first/last observed, freshness (current/recent/historical), a stable edge_id, and provenance. The result also carries counts_by_class (always broken down — never one undifferentiated number), completeness (complete/partial/stale/failed — a store read failure is reported, never rendered as empty), the graph_generation vector, and data_as_of. When the estate has no observed dependency on this event's subject th
- Where in our estate does that advisory apply?
- Which assets should we review for this?
List inventory
Page through a named inventory surface to enumerate all records of a specific kind. Use this after ncc_describe_org (to see surfaces_with_data) or after ncc_impact_search (to drill into a surface that had hits). Required argument: kind — one of: domains, dns_records, certificates, tls_endpoints, ips, suppliers, web_pages, email_spf, email_dmarc, email_mx. Each kind maps to the platform's live inventory for that surface. VOCABULARY — kind is THIS tool's name for an inventory surface, and it is a DIFFERENT vocabulary from ncc_impact_search's surfaces[]. The two do not interchange. When an impact hit hands you next_arguments, pass those through unchanged rather than translating by hand. The full translation: suppliers → suppliers, dns_records → dns_records, certificates → certificates, ip_infrastructure → ips, web_technologies → web_pages, web_content → web_pages, web_headers → web_pages (impact search splits web evidence three ways; inventory has one web surface). The three email kinds are N
- List our monitored domains
- Which pages look suspicious?
- Which domain registrations are due for renewal?
Web content keywords
USE THIS for "what is our web content about?", "which words appear most across our pages?", "is anything unexpected being published?". It returns the analyser's keyword population for the live pages at the latest completed assessment — the same set the portal's AI keywords page (/discover/content/keywords/) renders. QUOTE summary, NEVER A LIST LENGTH. summary.unique_keywords, summary.total_occurrences and summary.rare_keywords are computed over the WHOLE population; keywords[] and rare_examples[] are both capped, twice over — once by the platform's own window and again by limit — so a list that arrives shorter than limit can still be hiding thousands. truncation says exactly what each list left out. Deriving a counter from a served list is the specific defect that made an estate with the most rare keywords report that it had none. keywords[] is the most frequent keywords, largest first. rare_examples[] is an ALPHABETICAL SAMPLE of the tail — keywords appearing on at most a couple of pages — not a
- What topics does our web content cover?
- What are the most common keywords across our pages?
- Are there any unusual words on our pages?
Web layout clusters
USE THIS for "which of our pages look alike?", "is one template repeated across many domains?", "what do our parked or error pages look like?". It returns the platform's own visual-layout groups — live captures grouped by perceptual hash — the same groups the portal's Content gallery (/discover/content/gallery/) renders. Per cluster: cluster_id, primary_category, size (member PAGES), domain_count and namespace_count (how many hosts and registrable estates those pages span), avg_rating, category_breakdown, http_statuses, sample_domains, cluster_phash and a representative page (url, host, thumb_url, screenshot_url, rating). A large size over ONE domain is a template; a large size over MANY domains is a fleet — say which, because domain_count is what distinguishes them. similarity is a perceptual-hash distance and the platform SNAPS it to a precomputed threshold. The reply carries both similarity_requested and the similarity_threshold the clusters were actually computed at — quote the threshold, never
- Which pages look the same?
- Do we have a page template repeated across many domains?
- Show the visual clusters in our web estate
CVEs linked to one subject
USE THIS to list the published CVEs linked to ONE supplier, product or technology this organisation holds — after ncc_cve_exposure_summary or ncc_list_cve_subjects has named it. Pass kind and key exactly as those tools returned them. A key that belongs to a wider subject still works: a vendor's member domain opens its vendor group, and a product key opens the technology it is listed under. The subject block names the subject actually opened. FOOTPRINT-GATED, and honestly so. A subject this organisation does not currently hold comes back with not_in_footprint true and no rows: that is a statement about the footprint, NOT that no CVE names the subject. Say it that way — the global per-subject list is deliberately unreachable without holding the subject. Narrow by published_on (one UTC day as YYYY-MM-DD, or "undated" for CVEs the source gave no publication date), or window_days for a rolling window ending today; published_on wins when both are given. severities[] and kev_only compose with them, and known-e
- Which CVEs were published against that vendor this week?
- What was published against our web server on 2 September?
- Show the known-exploited CVEs linked to our CMS
Security posture rating
USE THIS FIRST for any question about the organisation's SECURITY RATING or overall standing — "what is our security rating?", "how are we doing?", "how would you summarise our posture for the board?", "what would move our grade from C to B?", "which business unit is weakest?", "are we compliant?". It returns the whole posture surface the portal's Cyber Posture — Strategic Dashboard shows, in ONE call, computed by the platform: it does not re-derive a grade. THE HEADLINE. final_grade is the grade to lead with. It is the lower of posture_grade (the letter the 0-100 posture_score earns) and the worst fail-band ceiling, so a high score beside a lower grade is not a contradiction — say which is which. A BLANK grade is WITHHELD, never an F: rating_state insufficient_evidence means the platform declined to rate the estate, and reporting that as a failure is worse than reporting nothing. WHAT MOVES THE GRADE is deterministic, not an estimate. what_moves_the_grade.blocking_bands are the policy fail bands actu
- What is our security rating?
- What would move our grade from C to B?
- Which business unit is weakest?
Vulnerability catalogue search
USE THIS to browse the GLOBAL vulnerability catalogue (the CVE list and the EU Vulnerability Database) — every published CVE, whoever it names. This is the whole feed, NOT this organisation's subset: linked_subjects on a row are the CVE's own links across every organisation and say nothing about this footprint. For the organisation's own figures use ncc_cve_exposure_summary, and for one subject's list ncc_list_subject_cves. NO TOTAL, DELIBERATELY. The view is cursor-paginated over hundreds of thousands of rows and this tool returns no total for it. Never present the row count as a total and never say "N were published this week" from these rows — that figure comes from ncc_cve_exposure_summary. DEFAULTS ARE STRICT: lens new, window 7d, min_cvss 9.0, and a threat gate that hides every record that is not listed as known exploited, has an EPSS below 0.10 (or none), and is either below CVSS 7.0 (or unscored), published more than twelve months ago or without a publication date. So a default call answers "the
- What critical CVEs were published this week?
- Which known-exploited CVEs landed in the last 24 hours?
- Search the vulnerability catalogue for Apache
Search gaps
USE THIS to find the organisation's live cyber findings ("gaps") with rich filtering and current facets. Replaces a separate list/get split — one call answers questions like "what HIGH-criticality DMARC findings are open?", "show gaps on example.com", "list resolved cert-expiry findings from the last month", "new DMARC gaps this week", "Email gaps in remediation". NOT the page-classification surface. Questions about what a PAGE IS — suspicious, flagged, parked, error, unclaimed-service, login, API — are answered by ncc_list_inventory with kind="web_pages" and page_categories, never here. This tool holds security findings raised against assets; it will happily return findings for a page-classification question, and the reader cannot tell they were not what was asked for. Flagged, parked, unclaimed service and default server pages do also raise findings here (ref_codes flaggedcontent, page_parked, page_unclaimed_service, page_default): use those to ask what needs acting on, never to count pages, because
- What security findings do we have?
- Show me our high severity gaps
- Which DNS findings are open?
Data sovereignty footprint
USE THIS for any EEA / non-EEA, data-sovereignty or "which countries are we in?" question. It returns the platform's own Digital Sovereignty aggregate — the same numbers the portal's Sovereignty Dashboard (/discover/jurisdiction/dashboard/) shows — with all three jurisdiction-bearing layers pinned to ONE completed assessment, named in sample_id. Three layers, three DIFFERENT populations, never summed: domains (analysed domains whose TLD maps to a country), ip_addresses (distinct addresses the platform geolocated) and vendors (register entries carrying a declared jurisdiction). Each carries unit, total, eea_count, non_eea_count, eea_share_pct, unique_countries, top_countries[] and a basis{} block. country_union is the distinct countries across all three — a count of COUNTRIES, not of assets. THE PAGE'S HEADLINE EEA CARD IS NOT IN THIS PAYLOAD, deliberately. That card adds the three layers together; this tool does not, because the layers count domains, addresses and vendor entries — three different th
- How much of our estate is outside the EEA?
- Which countries does our estate touch?
- What is our data sovereignty position?
Supplier exposure
USE THIS to answer "who are our suppliers / third parties and how exposed are we?". Returns a supply-chain summary PLUS a highest-concentration-first supplier list, at the latest completed scan. CONFIDENCE — READ THIS. artifact_only=true means the vendor's supply-side evidence is only artifact mentions in page content, scripts, or TXT verification tokens (lower-certainty); a confirmed supplier has at least one DNS / MX / CNAME / certificate / WHOIS binding. Deployed-product (PRODUCT) detections carry no supply-side weight: a vendor seen through artifact mentions plus product detections is still artifact_only=true (the product signal is in surfaces[]/products[]), while a product-only vendor reads artifact_only=false — its relation_class carries the story. Treat artifact-only links as leads, NOT confirmed supply-chain dependencies. A row with relation_class="deployed_product" is a product-only vendor: EVERY observation is a product of theirs detected running on one of the org's own hosts — via technology
- Who are our top suppliers?
- How exposed are we to our biggest vendor?
- How many third-party services do we depend on?
Technology mix
USE THIS for any question about WHAT THE ORGANISATION RUNS — "what technologies do we use?", "which web servers?", "which CDN is in front of us?", "what JavaScript is on our sites?", "which TLS versions and key algorithms are deployed?", "how much of the estate is post-quantum ready?". One call returns the whole technology surface the portal's Technologies Dashboard shows: the headline totals, the ranked web-server, CDN, TLS-version, cipher-suite, key-algorithm, HTTP-feature, JavaScript-developer and certificate-issuer breakdowns, and per-technology domain prevalence with its share. THIS IS THE RIGHT TOOL FOR "what do we run". Do NOT answer that from the supplier register: a supplier row is a commercial or hosting relationship, and a fronting CDN or an HTTP server banner detected on the page itself is not one. Inferring a stack from supplier names silently drops everything detected only on the page — Google Frontend and Google Cloud CDN among them. EVERY COUNT IS DOMAINS. Not pages, not TLS endpoints, n
- What technologies do we run?
- Which web servers and CDNs are in front of our sites?
- Which TLS versions and key algorithms are deployed?
Tls posture
USE THIS to answer "how good is our TLS?" or "which endpoints accept weak or legacy TLS?". Returns a KPI summary PLUS a bounded endpoint list, scoped to the latest completed scan. summary (scoped by endpoint_type AND org_units ONLY — the security-class filters below narrow the LIST alone, so with one of them set the list is a subset of the summary population and matched_count is the size of that subset): total_endpoints with web_endpoints and email_endpoints, which partition it into HTTPS endpoints and SMTP/STARTTLS endpoints — GIVE THE SPLIT WHENEVER YOU GIVE THE TOTAL ("402 endpoints, 379 web and 23 email"), because the two are different populations with different risks and a single number leaves the reader to guess the mix; on a call already scoped to one endpoint_type the other count is a measured zero for that scope and not an estate figure. Then tls13, tls12_only, legacy_tls10_11 (endpoints that still accept TLS 1.0 or 1.1), weak_ciphers_accepted, broken_ciphers_accepted, no_tls, self_signed (endpo
- What is our TLS posture?
- Which endpoints still accept legacy TLS?
- Do we have any weak ciphers?
- What are our broken ciphers?
- Which endpoints accept broken ciphers, and which suites are they negotiating?
Web content summary
USE THIS for any WHOLE-ESTATE question about web content — "how many pages do we have?", "what are they classified as?", "how many return errors?", "is the estate growing?", "how accessible are our pages?". It returns the platform's own aggregate, so it agrees with the portal's Content dashboard and Content inventory (/discover/content/dashboard/, /discover/content/inventory/) exactly. NEVER answer a distribution or a total by tallying rows from ncc_list_inventory kind="web_pages". That is one page of a listing, and counting it produces a plausible table of the wrong thing. Returns, each block with the basis that makes it quotable: pages (total, domains_with_a_live_page, domains_seen_all_scans, with_screenshots, unclassified), status (by_series and by_code), categories (primary[], any[] and previously_seen[]), mobile (differs, not_captured, differs_threshold_phash), velocity (new/removed over 7 and 30 days, baseline_import_pages, first_assessment_at), accessibility (avg_pass_pct, total_violations, impact[
- How many web pages do we have?
- What is the mix of page classifications?
- How is our web estate changing?
Security KPIs dashboard
Open the Security KPIs dashboard: a Klarvant-branded side panel with your key security KPI numbers, trend charts and most urgent gaps. Available to organisations with the A2UI projection enabled; requires a client that renders A2UI (such as Gemini Enterprise). Deterministic invocation: send a message whose single part is application/json data shaped {"tool": "ncc_security_kpis", "args": {}}.
- Show my security KPIs dashboard
New supplier report
List the suppliers first observed in your estate since a baseline — by default the previous completed analysis; also "since" a date or RFC 3339 timestamp, or the last 24 hours — grouped into vendor companies, worst risk first and then newest first, with each one's category, risk, footprint (the domains and subdomains that use it), headquarters country and hosting countries and networks. "Hosted suppliers only" keeps the suppliers your domains resolve to in at least one hosting country, plus those rated Fail or Warn whose headquarters country is known. Answered in one turn without a language model: a markdown table plus the same data as JSON, and errors as a JSON error object. Ask in words ("New supplier report") or send a message whose single part is application/json data shaped {"tool": "new_supplier_report", "args": {"since": "previous_completed_analysis", "limit": 25, "include_existing_vendors": false, "hosted_only": false}}. Requires read:suppliers; hosting and the hosted suppliers only filter also re
- New supplier report
- New supplier report since the previous completed analysis, limit 25
- New supplier report since the previous completed analysis, hosted suppliers only, limit 25
- New supplier report since 2026-09-23T09:00:00Z
- Which new suppliers appeared in the last 24 hours, with their footprint and hosting countries?
Analyst Q&A
Conversational security analyst. Ask questions in plain language about your organisation's attack surface — certificates and their expiry, TLS endpoint posture and weak ciphers, exposure to a technology or vendor, security gaps and remediation, supplier and supply-chain dependencies — and about supplier / service dependency events and where they touch your estate. The agent plans and executes the deterministic skills above and answers with evidence drawn only from the tool results (your scan data, and the global dependency-event catalogue). Supplier links that are artifact-only (seen solely in page content, scripts or TXT records) are reported as lower-certainty leads, never as confirmed dependencies. Dependency touchpoints are reported as locations to review, never as vulnerabilities; it never claims you are affected or not affected — the negative is 'no observed dependency in monitored evidence'. Answers are drawn from the organisation's last completed analysis and carry its timestamp; where something
- Which certificates expire in the next 30 days?
- How many security gaps do we have, by severity?
- Who are my top vendors, and which services do they deliver?
- Which pages look suspicious?
- What should we fix first?
What kind of listing
- Test or staging name: Its hostname carries the label “demo”, a name commonly given to test and staging sites.
Checked by agenttru.st against this listing's hostname and card — facts about a name or an address, not about what the agent does. How kinds are decided.
Technical agent card
Copied from the agent's card. The operator controls these values; agenttru.st has not verified them.
- Provider
- Klarvant — what this agent says about itself; other agents claiming the same provider are not thereby related
- Protocol
- a2a
- Version
- 4.64.5
- Auth schemes
- nccApiKey oauth2
- Extensions
-
https://a2ui.org/a2a-extension/a2ui/v0.9Renders answers as A2UI components — KPI dashboards, charts, tables and page captures — in clients that support them.https://cloud.google.com/marketplace/docs/partners/ai-agents/setup-dcrGoogle Cloud Marketplace agent registration: an agent platform acting for a marketplace buyer posts its signed software statement to target_url and receives the OAuth client credentials for that subscription.A2A protocol extensions the card declares. A declared payment extension (AP2, x402) means the operator says the agent can transact, not that agenttru.st has seen it do so. - Card completeness
- complete all eight fields required by a2a.proto v1.0
View all card details
- Capabilities
- extensions streaming
- Agent card
- https://demo.nc.klarvant.com/.well-known/agent-card.json
Operate this agent and would rather not be listed? Request removal.