APBSCPublication boundary & security closure 中文

APBSC · Integrated public edition · v1.0

AI Agents and the Public Boundary

APBSC — an integrated public edition of the research program

Version 1.0 · 2026-10-13 · Neo.K, EveMissLab

Program site: privacy.evemisslab.com · Algorithm, protocols, released features and reports: github.com/EveMissLab/apbsc-rbpm · 中文版:APBSC_Integrated_Public_Edition_v1.0.zh.md

This edition replaces the ten internal Phase I drafts (v0.1, 2026-09-21) as the program's public text. It was written with AI assistance (Claude) from those drafts and from the measurement reports, under the author's direction. Nothing in it is peer-reviewed.

Abstract

Coding agents work better when they are told more about the machine they run on: where the project lives, which runtime to use, how authentication is set up, which internal service to call. That context gets written into files such as CLAUDE.md, AGENTS.md, editor rules and agent configuration, and those files are committed with the project. The APBSC program asks what follows when they become public.

Its first phase (ten papers, September 2026) built a vocabulary and an argument. Passing every automatic check is not the same as respecting a publication boundary; the context an agent needs is itself a way for information to leave; secret scanning answers a narrower question than privacy does; and none of this can be studied honestly by reading other people's leaks. The phase ended with RBPM, a researcher-blind measurement algorithm in which the first and only observer of repository content is a sealed machine process that emits coded features.

The second phase (October 2026) ran that algorithm on fresh public samples: 236 repositories carrying agent instruction files, README and governance files, and 400 repositories owned by individual accounts created within two years. In every population the algorithm found publication-boundary signals. Among the individuals, 2.75% published .claude/settings.local.json, a file Claude Code itself keeps out of version control; 10.5% published an AI agent configuration file; and the most concrete findings were home-directory paths recorded inside those configuration files.

No person and no AI model working on the program read any measured repository. The numbers are what an algorithm reported, they may be distorted, and the study stops here by choice: going further would mean reading what people did not mean to publish.

1. The question

A delivery pipeline can generate code, pass its tests, pass a secret scanner, survive review and push successfully. Each of those is a separate proposition, and none of them is the proposition that the published result respects its privacy and security boundary.

The program started from one documented case. A delivery workflow had privacy rules and an automatic checker. The checker reported PASS. The excluded private value was still recoverable, stored inside the checker itself as separate string constants that a contiguous-string search could not see and simple concatenation could rebuild. Nothing in the pipeline was broken. The evidence simply did not cover the outcome that mattered.

The working question became: when AI agents take part in building and publishing software, what leaves the private workspace, through which surfaces, and how can that be measured without making the measurement one more leak?

2. The vocabulary

The information chain. A piece of information passes through five states: observed, authorized, persisted, published, externally obtainable. Each arrow is its own permission. The program's short form is: an agent may observe something without being allowed to persist it, and may persist something without being allowed to publish it.

Publication-boundary closure. A delivery is closed when there is evidence that what reached the public side is what was meant to reach it, and nothing more. Closure is a property of evidence and coverage, not of how many checks ran.

The green-light fallacy. Writing the checks as V₁ … Vₙ and the real postcondition as G: V₁ ∧ … ∧ Vₙ = PASS does not imply G = PASS unless G was mapped into their coverage. Checks that read the same source or share the same generated oracle are not independent, so more green lights can raise confidence without raising assurance. A check that could not see a surface returns NOT MEASURED, never PASS.

Agent context as an egress surface. Nine context classes make the question measurable rather than arguable: C1 workstation or local path, C2 runtime or tool topology, C3 authentication or session context, C4 private network or internal endpoint, C5 live operational security state, C6 organization or project relationship topology, C7 personal or identity context, C8 secret-like material, C9 generated diagnostic context. Sensitivity and risk are separate axes: a concrete path can be harmless, and an authentication reference can be necessary documentation.

Recoverability. Present or absent is too coarse for privacy. R0 not recoverable, R1 weakly inferable, R2 strongly inferable, R3 directly reconstructable, R4 literally present.

Warning levels. L0 generic; L1 operational, non-sensitive; L2 concrete context whose inappropriateness is not shown; L3 likely boundary incident, meaning concrete, public, of low necessity in its context, and independently confirmed; L4 critical, meaning a plausible credential or key, which is never validated.

Knowledge states. Every proposition carries one: O observed, H hypothesis, E established, NM not measured. At the time of writing, nothing in the program is E.

3. The arguments of Phase I

The framework (paper 00). Delivery is judged by the state of the world it leaves behind, not by whether the program is correct. A hash proves the bytes are the bytes that were hashed and says nothing about what they reveal. A private repository is not a vault, and a clean current tree does not clean history.

The green-light fallacy (paper 01). Claimed assurance should not exceed demonstrated coverage. A correct implementation of an incomplete specification passes every test it was given, and generated tests share the blind spots of the code they were generated from. The paper separates a detector's false negative from a scope false PASS, in which the detector worked correctly on the wrong surface.

Agent context as an egress surface (paper 02). Project roots, local runtimes, browser profiles, internal endpoints and credential-loading conventions are written into instruction files, configuration, fixtures and generated documentation, and cross a boundary they were never written for once those files are published. Rule files and negative examples can expose the very values they are meant to guard.

From secret scanning to semantic privacy (paper 03). Pattern detectors answer whether a known secret form is present. A delivered artifact can still carry local identity, workstation paths, network layout or organization relations without a single literal match, or carry a value split across constants and files. The paper refuses the opposite mistake as firmly: a semantic AI detector is not an oracle, and its own explanations can leak. Pattern evidence, semantic evidence, policy context and independent falsification are combined, and UNKNOWN stays an answer.

Organizational propagation (paper 04, hypothesis). Shared rules, templates, skills and scanners are supply-chain roots. One context error can be inherited by every repository that copies it, a widely shared scanner's PASS carries more apparent authority than it has earned, and copies of a policy age at different speeds.

Build–attack asymmetry (paper 05, hypothesis). AI lowers the cost of building something that works faster than it lowers the cost of building something secure, and may also lower the cost of finding weak targets. The hypothesis is narrow, and the paper does not claim that current AI is a universal attacker.

Provider and platform responsibility (paper 08). Observation, execution, persistence and publication are four boundaries that cannot be merged: execution-safe is not publication-safe, and secret-safe is not semantically private. Platforms have built real controls for the first three. The review found no generalized semantic publication-boundary layer; not found in review is not the same as absent. Responsibility is layered across provider, platform, organization, repository and user.

4. Measuring without looking

Why the method matters (paper 06). Publicly accessible is not the same as ethically free to observe, aggregate, retain and republish. A researcher who reads leaked paths and identities to show that they leak becomes a second observer and a new point of aggregation, which is the failure being studied.

The algorithm (paper 09, RBPM). A repository's current public state passes through normalization, a detector ensemble, suppression of sensitive values, feature extraction and adjudication to a research-safe output: X → N → D → S → F → A → O. Everything before O runs inside a sealed process. What leaves it is a closed vocabulary of classes, levels, counts and bands.

The rules are not relaxed:

The study protocol (paper 07). A preregistrable design with matched controls, unique-repository sampling and preserved UNKNOWN states, built to answer prevalence and difference questions that pilots cannot. The program did not run that confirmatory design; section 7 explains why.

How Phase II applied it. Each round's protocol was committed before anything was fetched. Candidates came from GitHub code search. Repositories were screened, fetched and classified inside one sealed process that printed only counts. Each round received neutral identifiers, a lock record with the digests of its released files, a written reading of the locked data, and an independent auditor that imports none of the runner's code. Only then were group attributes such as owner type or AI-tool profile joined.

5. What the algorithm observed

All panels are exploratory and non-probability. Intervals are exact 95% (Clopper–Pearson). None of these figures is a prevalence estimate.

5.1 Phase I, September 2026

MeasurementWhat it showed
Code-search pilot, 2026-09-20Raw search ratios of files containing a /Users/ prefix: CLAUDE.md 3.55%, AGENTS.md 2.13%, .cursor/rules 1.45%. Search counts, not leak rates.
AI-native company check, N = 1211 had a public AI collaboration surface; 2 showed bounded context signals; no escalation.
Two tiny blind runs, N = 6 + 6The blind boundary held on real data twice.
60-repository bridge, three commercial strataL0 43, L1 15, L3 2; both L3 on agent instruction files of AI-native companies.
Same panel, three surfacesHigh warnings on 2 of 40 agent-instruction cells, 0 of 59 README cells, 0 of 51 governance cells.

5.2 Phase II: organizations and individuals, three surfaces (N = 236)

Four rounds of repositories that carry a root AGENTS.md or CLAUDE.md, a README and a governance file, so that no surface is structurally absent. Rule as frozen for the first round.

SurfaceHigh-warning cellsShare95% intervalL3
README8 of 2333.4%1.5–6.7%2
Agent instruction file7 of 2363.0%1.2–6.0%4
Governance file2 of 2350.9%0.1–3.0%1

Sixteen of the 236 repositories (6.8%, 3.9–10.8%) had at least one high-warning cell. Between rounds of about 60 repositories, high-warning cells ranged from one to nine.

5.3 Phase II: individuals with AI-collaboration markers (N = 400)

Two rounds of 200 public repositories owned by individual accounts, created within two years, drawn equally from five AI-instruction files: CLAUDE.md, AGENTS.md, GEMINI.md, .github/copilot-instructions.md and .cursorrules. 292 of them have no stars. The AI-collaboration profile of each repository (tool families in its tree, AI co-author trailers on its current head commit, declarations in its README) was recorded inside the sealed process and joined only after label lock.

ObservationRepositoriesShare95% interval
.claude/settings.local.json is public11 of 4002.75%1.4–4.9%
An AI agent configuration file is public42 of 40010.5%7.7–13.9%
An agent conversation history file is public0 of 4000%0–0.9%
At least one high-warning cell, individual-era rule34 of 4008.5%6.0–11.7%
At least one high-warning cell, organization-era rule17 of 4004.25%2.5–6.7%

.claude/settings.local.json is the file in which Claude Code stores a user's personal project settings, including "don't ask again" permission approvals, and Claude Code keeps it out of git when it creates it. Its publication is a boundary crossing defined by the tool's own documentation, not by this algorithm's judgment. Among the 192 repositories with any Claude marker, 11 (5.7%) published it.

By surface, agent-state files had the highest high-warning share (6 of 66 cells, 9.1%, 3.4–18.7%), against README (21 of 360, 5.8%) and the instruction file (12 of 400, 3.0%). Five of the six agent-state high warnings were L3: a concrete home-directory path recorded in .cursor/mcp.json (two), .gemini/settings.json (two) or .vscode/mcp.json (one). Repositories with no stars had the highest any-high share (30 of 292, 10.3%).

The rule written for individuals found about twice as many repositories with a high warning as the rule written in the organization era, because the earlier rule cannot see personal email addresses outside contact wording, private network addresses on operational lines, or paths inside configuration files.

5.4 Reproduction

The frozen Phase I package was re-executed: its 212 tests passed (one skipped), all six of its independent auditors passed, and the surface-matrix headline above was recomputed from its released cells alone.

6. What held, what did not, and what the algorithm got wrong

Held. Agent-related publication-boundary signals appeared in every population measured: companies, organizations and individuals. Files that tools themselves treat as private were published by individuals. Agent configuration files carry concrete local paths.

Did not hold. The Phase I concentration of high warnings on agent instruction files did not recur on the balanced Phase II panel; README was as high. After the first individual round suggested that people using three or more AI tools leak more, that was written down as a prediction before the second round was opened, and the second round did not support it. Owner-type differences stayed inside overlapping intervals.

Defects found and handled in the open.

Three cells matched the shape of a credential. They were never tested. Their locator records stayed sealed, were never opened, and were deleted on 2026-10-13. No person or organization was contacted at any point.

Knowledge states after Phase II. Existence across all three populations is O. Every comparative and causal statement (AI-assisted against non-AI repositories, organizational amplification, build–attack asymmetry, transition risk) remains H. Prevalence and governance lag remain NM. Nothing is E.

7. Ethics, and why the study stops

We did not look at their GitHub ourselves; an algorithm did. The data may therefore be distorted, and I have to admit that. But I will never look at what people do not want seen, not for the sake of complete data and not for the sake of complete information. — Neo.K

The program set out to show that the problem exists for individuals, organizations and companies, and that a researcher-blind algorithm can show it. Both are now observed. The next natural step, sampling directly on agent-state files to see what published configurations and conversation histories contain, would mean reading what people did not mean to publish. Many of them may already have fixed it themselves. The program therefore stops at indirect observation.

The same reasoning shaped the release. Per-repository attributes joined after label lock (owner type, AI-tool profile, star band) are published only as aggregates, because a rare combination could point to a specific repository. The cost is that two pooled computations cannot be fully re-run from the public release, and that cost was accepted.

Why the numbers may be distorted.

  1. No human checked any finding, so both false positives (an intended example, a published contact address) and false negatives remain.
  2. Secret-like means a shape; nothing was tested.
  3. The frames are not random samples: code search ranks results, exposes at most a thousand per query, and each frame required specific files.
  4. The instrument has known defects, and the later rules that repair some of them are heuristics without human validation.
  5. Rounds of 60 repositories swing widely.
  6. One AI system designed the later rules and read their outputs; no independently written instrument has been run on the same frame.
  7. Each repository was observed once, at its current state, and may have changed since.
  8. File totals from code search are index approximations, not counts of leaks.

8. What this suggests

These follow from the observations without depending on any prevalence figure.

For people who use coding agents. Treat tool-local files as never-commit: .claude/settings.local.json, CLAUDE.local.md, local agent histories. If a tool created the file, it may already be excluded; if you created or copied it by hand, add it to .gitignore yourself. Write MCP and editor configuration with environment variables or project-relative paths rather than your home directory. Before publishing, look at the exact files that will leave, not only at a scanner's verdict.

For teams. Keep local and shared agent context in different files. Describe how authentication works, never where a token or session lives on one machine. Read back what reached the remote: a local PASS is not remote evidence. Record NOT MEASURED where a check cannot see.

For tool and platform makers. The tool that defines a file as local is best placed to notice when that file is about to be committed or published. Secret detection that only matches key = value misses quoted key–value shapes in JSON configuration. Execution sandboxes and secret scanning protect real boundaries; publication of agent context is a further boundary of its own.

9. Limits

This edition is a synthesis, not a peer-reviewed paper. The Phase I drafts it draws on remain internal. Its measurements establish existence at exploratory strength in specific frames and nothing about prevalence. The confirmatory study designed in Phase I was not run, by decision. The instrument's rules beyond the frozen v0.8.3 core were written during the study and are documented, versioned and frozen before each round, but not externally validated.

10. Availability, authorship and license

Appendix A. Proposition ledger after Phase II

IDStateProposition
O1OAI collaboration files can themselves become publication surfaces.
O2OIn at least one documented workflow, a checker reported PASS while recoverable excluded information sat inside the checker itself.
O3OPublic AI collaboration files can contain concrete workstation, runtime, session and internal-network context.
O4OReal public files can be reduced to bounded research features without exporting repository identity or source text.
O5OIn a frozen 60-repository company panel, both high-warning results were on agent instruction files.
O6OIndividuals publish files that their own AI tools treat as local, such as .claude/settings.local.json.
O7OPublished agent configuration files can carry concrete home-directory paths.
O8OAgent-related publication-boundary signals appear among individuals, organizations and companies alike.
H1HAI-assisted repositories disclose more than matched non-AI repositories.
H2HShared organization context amplifies one disclosure pattern across many repositories.
H3HMultiple AI reviewers sharing evidence roots overstate the independence of verification.
H4HConventional secret-scanning statistics undercount semantic privacy leakage.
H5HAI-assisted building grows low-maturity targets faster than defensive automation shrinks them.
HTHOrganizations in transition into AI are a higher-risk band than AI-native ones. Not supported by the bridge; not rejected.
NM1NMPopulation prevalence of any disclosure class, and its trend.
NM2NMGovernance lag between context surfaces and the controls around them.

Appendix B. The Phase I papers

All v0.1, 2026-09-21, internal research drafts. Summaries are on the program site.

No.Title
00Agentic publication boundary and security closure: the integrated framework
01The green-light fallacy: when agent verification succeeds and the real postcondition does not
02Agent context as an egress surface
03From secret scanning to semantic privacy
04Organizational agent context propagation
05AI build–attack asymmetry
06Researcher-blind privacy measurement
07An empirical study protocol: sampling, matched control and prevalence estimation
08Provider and platform responsibility: publication-boundary governance for AI coding tools
09The researcher-blind publication-boundary measurement algorithm