Your agent can read the repo. That does not make every file publishable

Your agent can read the repository. That isn't a publishing policy.

A useful website agent may need product facts, private interviews, working notes, and examples of what good work looks like. A visitor needs a much smaller set of approved outputs.

Those sets can live close together. They still need a boundary.

“It's in the repo” doesn't tell you whether a file is shareable, whether the build reads it, or whether a stranger can fetch it. You have to follow the information from the source to what actually leaves the system.

Read, change, share, publish: four different permissions

“Read these sources and prepare a local draft” is a different assignment from “publish the reviewed guide and worksheet.” The same agent may have tools for both.

Tool access describes capability. The task establishes what the agent should do with it.

GitHub repository roles separate reading and pulling from pushing. Local write paths and deployment credentials have their own scope.

A read-only reference repository can inform work in another authorized workspace. It doesn't become writable because copying an idea would be convenient.

Disclosure needs its own decision too. Suppose a private interview helps the writer understand a problem, while only the approved product sheet is cleared for public claims.

The interview's names, quotes, numbers, and attachments don't become publishable because the agent found them useful. A paraphrase can disclose the same information as a quotation. Removing a name may leave an identifiable account story or an unreleased feature intact.

This is practical agent governance. Existing authority should carry through the work it covers. New material or a new audience deserves a specific scope decision.

Inventory what may leave

For a fictional guide project, the inventory might look like this:

Material	Intended use	Public output
Restricted interview	Internal understanding	No raw text or identifying detail
Working draft	Local editorial review	Excluded from public consumers
Reviewed guide	Authorized publication	Agreed guide route
Reviewed worksheet	Public download	Agreed download URL
Interface configuration	Application labels	Only selected public fields

Add an owner and current state. Editorial approval and completed publication are separate states, and folder names aren't evidence of either.

Include generated artifacts. Research notes can contain excerpts omitted from the final article. Backups can preserve private earlier versions. Screenshots can capture more than the paragraph under review.

Context strategy asks what the agent needs to do the job. This inventory asks what may leave that context. Both questions matter.

Git ignore rules don't run the website

Git ignore rules concern intentionally untracked files. They don't remove files already tracked, undo earlier pushes, or prevent a local program from reading an ignored file.

Inspect the tracked files and proposed commit. Then inspect how the build gets its inputs: checkout, copy scripts, uploads, generated files, and external fetches may all contribute.

A private repository limits one collaboration surface. It doesn't determine every response the application serves. Conversely, a file in a repository doesn't automatically have a public URL.

The interesting evidence is the path from that file to an artifact or response someone can receive.

Follow the consumers, not the reassuring labels

For a Markdown site, a draft flag helps only where code interprets it. Find every consumer: article listing, direct lookup, search data, feeds, exports, and previews.

A loader that reads only an approved directory is useful. A separate search script scanning every Markdown file can bypass the intended boundary.

Test direct access as well as the index

Removing a draft from the article list doesn't establish that its route rejects requests. Next.js documents configurations where paths omitted from generateStaticParams can render when requested.

The route configuration and lookup behavior decide what happens. The build-time list alone isn't a universal access gate.

Next.js Draft Mode is also distinct from a Markdown field. It uses an implemented preview handler and cookie, including an access-validation step.

A site can implement another draft policy. Someone still has to check that the relevant consumers honor it.

That's one reason a headless CMS isn't the whole content operating system. Correct source status can coexist with an integration exporting the wrong records.

A download is another publication

Next.js serves files in the public directory at paths relative to the site root. A worksheet placed under public/downloads can have a download URL without appearing in navigation.

Deployment controls may restrict access. An obscure filename doesn't provide that control.

Review the actual asset. A clean article can link to a PDF with unapproved notes, a spreadsheet with an extra tab, or an image showing more than the intended crop.

Approving the paragraph introducing the download doesn't inspect the download's bytes.

Check export templates too. They can append source material that the web page omitted. A route can read and return a file stored outside the static-assets directory.

Your content QA should check the approved page and attached outputs together. Include a positive case: the intended worksheet should work. Breaking every download isn't successful publication control.

Hidden on screen can still mean delivered to the browser

Next.js explains how Client Component imports, rendered output, and props cross into browser-facing artifacts and data.

Suppose a server reads a record containing an approved summary and internal commentary. It passes the entire record to an interactive component, which displays only the summary.

The private fields may already have crossed the boundary. Select public fields before returning them, then inspect the received data as well as the screen.

Next.js can also inline statically referenced NEXT_PUBLIC_ values into browser JavaScript at build time. Changing a later runtime setting doesn't rewrite the built bundle.

The absence of that prefix isn't a complete disclosure test either. Application code can return a server-side value in HTML, JSON, or another response.

Follow the actual value without printing real secrets into your reports. “Server-side” describes where code runs; it doesn't promise that everything the code reads stays there.

An unlisted preview still needs an audience

Who can open the review URL? Answer that for the exact host and sharing mechanism you're using.

Vercel Deployment Protection distinguishes protection methods and URL scope. Its documented Standard Protection excludes production domains, while All Deployments includes them; legacy scopes differ.

Inspect the actual project configuration. Then test an intended reviewer and an unauthenticated request without an existing session or bypass credential.

Someone already signed in can't establish what an anonymous visitor receives.

Check shareable links and protection exceptions too. A denied request without a sharing link doesn't prove the audience of the link you're about to send.

Keep access separate from discoverability:

Observation	What it does—and doesn't—show
Missing from navigation or sitemap	Not listed there; direct access may still work
Page has noindex	An indexing instruction, not authentication
Anonymous request denied	Evidence for that host, path, and request context
Authorized reviewer can open it	The intended access path works

Google's noindex guidance concerns search indexing. Google needs to crawl the resource to see the instruction; a robots.txt block can prevent that.

A page with noindex can still be read by someone who has the URL. Search-engine etiquette is not an access-control system.

Test a real boundary with harmless material

Use an invented source-only fixture with a distinctive marker. Pair it with an approved public fixture. Run the relevant consumers in an isolated setup.

The restricted marker should stay out of the excluded outputs. The approved example should remain available. Don't deploy actual private information to discover whether the restriction works.

Adapt the checks to the application's real surfaces:

• Article listing and direct route.
• Search data, feeds, and exports.
• Static assets and generated downloads.
• HTML, browser JavaScript, and returned data.
• Protected review destinations and their sharing paths.

Read the consumer code before interpreting the results. A string search can miss information that was summarized, encoded, or split across fields. A clean response says nothing about a consumer you never exercised.

A few expected 404s are useful evidence when you inspect their bodies too. They establish that those paths returned 404 without the tested restricted data, under those request conditions.

They don't establish that nothing private could ever be exposed. Other hosts, older deployments, and untested export paths remain separate questions.

Keep the evidence tied to the candidate revision. When a later change broadens a scan or adds an endpoint, rerun the affected check.

Hand off the approved artifacts

The release handoff should identify the reviewed guide and worksheet versions, destinations, applicable authority, and relevant verification. Keep restricted evidence in its proper review location; a public pull-request description is another publication surface.

If existing authorization covers those outputs, proceed through the release process. If a new attachment contains uncleared material, hold that attachment while finishing independent work.

The owner should be deciding on a concrete proposed disclosure, not approving “the repo” in the abstract.

A useful Context OS makes this inspectable. After release, check the actual destinations again.

If you can't trace what your website agent reads into what it publishes, start by mapping that path. Giving it more context should improve its judgment, not quietly enlarge the public website.