Knowledge Exposure Audit

What can an AI agent legitimately learn about your organization today – without breaching anything?

Part of the Sovereign Stack.

The question traditional security doesn’t ask

Standard security tools ask a defensive question: can an attacker get in? They check for vulnerabilities, misconfigured servers, exposed databases, unpatched software.

The Knowledge Exposure Audit asks a different question:

If an AI agent or researcher crawled everything publicly accessible on your domain today, what confidential, proprietary, or strategically sensitive knowledge could it assemble?

These are two different problem spaces. An AI crawler doesn’t need to breach a network to extract value – it only needs public endpoints, an unlinked staging path, a stray PDF, an exposed API route, or a piece of client-side JavaScript carrying more than it should. Standard vulnerability scanners don’t look for this. Nobody is checking whether an AI model can reconstruct proprietary IP, internal documentation, or strategic detail from what’s already sitting in plain sight.

The governing principle: most public information is supposed to be public. A finding only exists where a pattern suggests no obvious legitimate reason for that specific content to be served to an anonymous visitor. Public is not the same as vulnerable – the audit is built to tell the two apart, not to flag everything it finds.

What gets audited

Every finding answers four questions:

1. Is the information publicly served?
2. What type of information is it? – credentials, internal infrastructure references, filesystem paths, usernames, configuration, proprietary documents, document metadata, technical fingerprints, and related categories.
3. Is there evidence it should not be publicly served? – deliberately published, versus accidentally exposed, versus information with no legitimate reason to reach an anonymous visitor.
4. Where exactly is it served? – the precise URL, the surrounding context, and the evidence itself.

Findings are classified into three tiers:

Critical – information that should almost never be publicly served: live credentials, API keys, private key material, hardcoded authentication values.

High – potentially proprietary or operational exposure: internal or staging infrastructure referenced from public pages, administrative endpoints, source or configuration files, enumerable usernames, documents whose filenames suggest they were never meant to be public.

Medium – information that may be entirely intentional but is worth a second look: software version fingerprints, internal path fragments, document metadata, email addresses, authorship data.

Deliberately public information – the normal, intended footprint of a working website – is not reported as a finding at all. The goal is a small number of things worth acting on, not a long list of things that were already fine.

How a finding is documented

A finding is evidence, not a warning. Each one is structured the same way:

• Evidence – the exact source URL
• Detected value – the specific string that triggered the finding
• Exposure type – what category of information this is
• Why flagged – the concrete reasoning, not a generic alert
• Public necessity – whether there’s any legitimate reason for an anonymous visitor to receive this
• Recommended action – a specific next step, not a vague suggestion to “review”

Example, illustrative:

High – Staging or internal hostname reference Source: example.com/app.js
Detected value: staging-api.example.internal
Why flagged: The hostname is referenced directly in client-side JavaScript and contains indicators of a non-public environment.
Public necessity: No obvious functional requirement for an anonymous visitor to receive this value.
Recommended action: Remove from the client-side bundle or replace with server-side configuration.

How an engagement works

1. Scope and written authorization. Every engagement is defined by only a written request naming the exact domain in scope – never a verbal go-ahead. The audit stays inside that domain only; it never follows a link off it.

2. Collection. A live crawl of the authorized scope, following internal links, examining pages, linked documents, and client-side code as an anonymous visitor would see them – not as an authenticated user, and not as a search engine with special access.

3. Processing and classification. Every page is parsed for the categories above and each match is scored against the Critical / High / Medium taxonomy.

4. Synthesis. A grounded review of what’s been collected, modeling what a competitor, journalist, or AI system could plausibly infer – strictly from what was actually found, nothing invented beyond it.

5. Delivery. A single confidential report, delivered directly to the named recipient. Nothing is retained afterward – collected content is not stored beyond the engagement, and the report itself is the only artifact that persists.

The audit is run personally, on request, under a written engagement – not offered as self-serve software. Findings of this kind are sensitive by nature; how the audit is delivered is part of what makes it trustworthy.

Who this is for

Organizations for whom the public-facing footprint carries real strategic weight: enterprises with proprietary methodology or roadmap exposure risk, and government and institutional bodies where the cost of an assembled knowledge leak extends beyond any one document into policy, personnel, or diplomatic exposure.

This sits alongside AI Visibility Inspector and NovaX as a third, distinct layer of the Sovereign Stack. Inspector and NovaX are built to help AI systems find and understand an organization correctly. The Knowledge Exposure Audit is the inverse discipline: making sure AI systems don’t learn things that were never meant to be found at all.

Data sovereignty asks where your model runs. Knowledge sovereignty asks whether your public footprint lets an outside system reconstruct what you never intended to package together.