# The Serialised Pull Request Is The Headline: Publish The Vaults, But Lead With The Workflow That Gives An Agent No Access At All

**version** v0.33.58
**date** 14 August 2026
**from** Human (project lead)
**to** Product, Engineering, Marketing

**type** Strategy brief

*Third of 14 August. The agent permissions problem is grounded and cited, including a disclosure from nine days ago. Contains one caution about a pattern that is safe here and unsafe if copied. Offered to be built on and challenged.*

---

## What This Is

A publishing plan for the sample vaults and, inside it, a workflow that deserves to be the site's strongest claim rather than one example among many: **the vaults already exist in quantity and can be published two ways at once, as downloadable archives and as browsable embeds using a read key, which the platform already supports through vault-in-vault loading, so this is wiring rather than building and it answers the requirement from yesterday's brief that sample vaults beat code samples because they are the thing rather than a description of it; but the item buried in the middle of the memo is worth more than the catalogue, because giving an agent write access to a repository is the ambient authority problem this corpus named on 6 August, and it is now documented at severity, with one agent holding a token scoped to every repository its developer had authorised, a practitioner assessment that agents use far more permission than a human would, and a disclosure at Black Hat nine days ago that an issue opened by an account with no repository privileges reached continuous integration secrets in the vendors' own repositories using their own default configurations; against that, the workflow the memo describes almost in passing is a clean answer, since an agent clones a public vault needing no credential at all, works, and emits a diff which a human imports, reviews and merges on another machine, so the agent never holds write access to anything and the reviewable artefact carries full provenance; that pattern is what security researchers independently recommend, in the form of running analysis in a read-only job with no publishing credentials and passing a constrained artefact into a separate privileged step, which is an unusually strong position to be in, namely having built the recommended control before the recommendation; it also corrects something written earlier today, because the absence of pull requests is not a gap when a serialised diff is a better fit for agent collaboration than a hosted review interface; and one pattern in the memo is safe in its stated context and dangerous if copied, since committing plaintext alongside ciphertext is right for public samples and is exactly the thing the corpus ruled out on 6 August for anything confidential.** It is the third document of 14 August (cross-ref: the v0.33.58 Why-section brief, the v0.33.56 plugins brief, the v0.33.56 git-and-sgit brief, the v0.33.55 vaults-as-substrate brief, and the v0.33.54 no-blank-prompt brief). New contributions: **the serialised pull request identified as the headline claim, external grounding for the permissions problem, the observation that the pattern matches independent security guidance, the correction on pull requests, the agent filesystem framing, and the plaintext-alongside-ciphertext caution.**

## Publish Them Both Ways

The mechanism is already built and the memo says so. The project lead: **"we'll put the read key, which means we don't put the read write key, and then we allow the vault in vault to be browsable, because we already support that. It's even simpler because we already support loading vaults from the vault apps, so this is literally reusing that technology."**

Two forms, and both are worth having because they serve different readers:

| Form | Reader | Value |
|---|---|---|
| **Downloadable archive** | Somebody who wants to inspect or fork | Runs locally, no service dependency, keeps working offline |
| **Embedded, read key published** | Somebody evaluating in thirty seconds | No install, no account, browsable in the page |

The second is the one that changes the site, because it converts every example from a claim into something a visitor can open. Yesterday's brief argued that a sample vault beats a code sample since it is the thing rather than a description of it; **an embedded sample vault beats a downloadable one for the same reason again**, because it removes the last step between reading and seeing.

It is also a live demonstration of the read key concept. A page that says a read key lets you read but not write is making an argument. A page where the read key is visible in the source and the vault is browsing in front of you has settled it.

## The Catalogue Is The Asset

The memo lists what already exists and the range is the point. Galleries from two trips, a full penetration test report, a data protection graph analysis, a standards browsing view, email and messaging systems with multiple agents collaborating through an inbox, a healthcare case with patients and doctors, and semantic knowledge graph work.

The project lead: **"the whole point of this is that the real power I have with the vaults is that I can really have a very effective workflow with agents."**

Two observations for how to publish them.

**Sort by shape, not by domain.** A visitor is looking for a workflow that resembles theirs, and the domain is usually incidental. Gallery, report, structured analysis, multi-agent collaboration and record-keeping are the shapes; healthcare and penetration testing are instances.

**Each one needs a stated evidence status**, which the site already does elsewhere. Some of these are production systems and some are demonstrations built in an afternoon, and a visitor who cannot tell will assume the wrong one in either direction.

## The Permissions Problem Is The Real Story

The memo raises this in the middle and it should be at the top of the site. The project lead: **"I don't like the fact that I have to have an agent with full access to my vaults, my repos. We don't have a lot of granularity on the permissions. I have to give full access to Claude or ChatGPT or any agent to a repo to read-write, which can be very dangerous, and it's far more than they need, because they're just making surgical changes."**

That is the ambient authority critique the corpus named on 6 August, arrived at again from practice, and the external evidence has become severe since then.

**The scope is real.** One coding agent held a token scoped to **every repository the developer had authorised**, and a practitioner assessment puts the general case plainly: an agent uses far more permissions than it should have, more than a human would. The recommended principle is that an agent acting on your behalf should never hold more privilege than you do.

**The exploitation is documented.** Research disclosed at Black Hat on 5 August, nine days ago, found that a **GitHub issue opened by an account with no repository privileges** was enough to reach continuous integration secrets in the vendors' own repositories, for three leading agents, running each vendor's own default unmodified workflow configuration. Separate work describes a class in which a single comment or issue can cause credential exfiltration into publicly visible logs with no maintainer interaction at all.

**And the tooling gap is acknowledged.** A platform feature request from June 2026 asks for exactly what is missing: a way to mint a short-lived, revocable, least-privilege token for a single repository, on the grounds that personal access tokens are long-lived and application installation tokens require administrative setup. The request is open, which means **the capability does not exist**.

So the memo is describing a genuine and currently unsolved problem, and the next section is a solution to it.

## The Serialised Pull Request

The memo's own description of the workflow, which should become the site's lead technical claim. The project lead: **"I got Claude to clone a vault, a public repo, and I didn't need any permissions. Then Claude made a bunch of changes, then I got Claude to create commits and give me a diff. On another machine I cloned that vault, imported the diff, saw the changes, and then I merged them."** And the property that matters. The project lead: **"we actually had a really good provenance of all the changes made, because I had the diff of every single one. Fundamentally, it's like a serialised pull request."**

```
   AGENT SIDE                         HUMAN SIDE
   clone public vault                 clone the vault
   (NO credential required)                |
        |                                  |
   make changes, commit                    |
        |                                  |
   emit a diff  -------------------->  import the diff
                                           |
                                       review the changes
                                           |
                                       merge, and push

   The agent holds no write access at any point.
   The artefact is reviewable before it lands.
   Provenance is per-commit, not per-session.
```

Four properties, each of which addresses something in the section above:

**No credential is issued at all**, which is stronger than a short-lived scoped one. There is nothing to steal, nothing to expire and nothing to revoke.

**The artefact is inspectable before it takes effect.** A diff is reviewed; a write is discovered.

**Provenance survives.** Each change is a commit with its own record, rather than a session summary asserting what happened.

**And it is capability-shaped rather than trust-shaped**, which is the discipline the corpus argued for on 6 August: a component holds only the authority explicitly granted, and here the granted authority is read.

## Security Research Independently Recommends This Pattern

Worth stating explicitly, because it converts an anecdote into a position.

Guidance published in response to the disclosures above describes the secure arrangement as: **run analysis in a read-only job with no deployment or publishing credentials, then pass a constrained artefact or an explicitly reviewed result into a separate privileged job**, and specifically warns against running an agent in a job that both consumes untrusted input and can publish.

That is the serialised pull request, described by somebody who arrived at it from incident analysis rather than from building it.

**Having built the recommended control before the recommendation is an unusually strong position**, and the site should say so plainly rather than leaving a reader to notice. It is also a better claim than any feature comparison, because it is about a problem the reader already has.

## This Corrects Something Written Earlier Today

The Why-section brief written this morning stated that pull requests are absent from sgit, being a hosting-platform construct layered on merge. That is accurate and incomplete.

**A serialised diff is not a missing pull request. It is a different and, for agent collaboration, better one.** A hosted pull request assumes both parties have accounts on the same platform and that the proposer has write access to a fork. The serialised form assumes neither, works between a command line agent and a person on another machine, and produces an artefact that can be moved by any means at all.

So the boundary table from this morning should be adjusted: **pull requests as a hosted review interface are absent; proposing reviewable changes without holding write access is present and is a differentiator.**

## The Agent Filesystem Framing

The memo's clearest articulation of why any of this matters, and it is a good line for the site. The project lead: **"it's kind of like having access to the file system of an agent. Right now, whenever an agent is working on a file, you don't have access to the internal file system. If they create a file, they have to give it to you, and then you have to download it. If you want to give that to somebody else, that doesn't work very well, so the whole collaboration doesn't really work."**

That is a problem every reader has experienced and few have named. An agent's working directory is ephemeral, private, and reachable only through the conversation, so anything it makes has to be carried out by hand and cannot be handed on.

The extension workflow is the tidiest illustration. The project lead: **"Claude is working on a Chrome extension, pushes the changes to a vault, and then locally I pull the changes from the vault and just run the extension directly."** Agent writes, person pulls, thing runs. No download, no copy, no re-upload.

## The Site's Own Build Is A Live Instance

Worth recording, because it validates a position the corpus took on 2 August with a production example. The project lead: **"the workflow that we use for the main sgit website is super powerful, because you basically have four or five agents all working together, collaborating using an inbox. They actually use multiple vaults: one for the data, one for the publishing, one for coordination, one for the publishing data, and one for the messaging."**

That is the blackboard architecture described on 2 August, running in production: several agents with distinct responsibilities, communicating asynchronously through encrypted folders, with no agent addressing another directly. The 2 August brief argued that the authorisation, audit and update of shared state is where the published literature leaves an open question and that an encrypted versioned vault answers it by construction.

**This is that argument with a running instance behind it**, and a site that is itself built this way is the strongest available evidence for it. Worth documenting as a case study rather than mentioning in passing.

## One Caution: Plaintext Alongside Ciphertext

The memo describes a pattern that is right in context and would be wrong if copied without the context. The project lead: **"we commit all the encrypted files, and then you also commit the unencrypted files, so they become easy to read and see in GitHub. So you can do issue tracking, you can do all sorts of stuff with it."**

For **public sample vaults this is exactly right.** The content is meant to be read, GitHub's tooling becomes available, and the encrypted store rides along to demonstrate the mechanism.

For anything confidential it is exactly what the corpus ruled out on 6 August, where the co-existence work concluded that what git holds decides whether the vault is still zero-knowledge, and that a private repository restricts who may clone while doing nothing to stop the host reading.

**The site should state the condition rather than the pattern.** Publishing both is a choice available when the content is not secret, and a vault whose whole purpose is that the host cannot read it must publish ciphertext only. Written without that qualifier, this is a recipe somebody will follow into a leak.

## Move The Vaults, And Note What It Demonstrates

The memo carries a task. The project lead: **"a task for me here is also to move the vaults using the new deployment mode that we have into sgit.ai."**

Worth doing for a reason beyond tidiness. The site is already served from a vault, and hosting the samples the same way means the examples, the documentation and the site itself all run on one mechanism. **A visitor who notices that has been given a stronger argument than any page could make.**

It also connects to yesterday's access report: a site whose content is assembled client-side is exactly the shape that struggles to be indexed, and adding more client-rendered content makes that finding more urgent rather than less.

## What This Does Not Try To Be

- **Not a catalogue with a workflow attached.** The workflow is the claim; the catalogue is the evidence.
- **Not a request for better agent permissions.** The point is that no credential is issued at all.
- **Not a missing pull request.** A different one, better suited to agents than a hosted interface.
- **Not a general recipe for committing plaintext.** Right for public samples, ruled out for confidential vaults.
- **Not a demo.** The site's own build is a production instance of the pattern being sold.

## Honest Tensions

| Tension | Note |
|---------|------|
| Publishing sample vaults | Every published example is a maintenance commitment, and a stale sample is worse than none |
| Read keys in page source | It is the correct demonstration and it means anybody can read those vaults forever, so the content must be genuinely public |
| The serialised pull request as the headline | It is the strongest claim and it requires a human to review, which is the friction agents are usually adopted to remove |
| Claiming an anticipated control | The pattern does match published guidance, and saying so needs care to avoid sounding like a retrofit |
| Plaintext alongside ciphertext | Right here and a leak elsewhere, and the qualifier is what most readers will skip |
| More client-rendered content | It demonstrates the product and it worsens the indexing problem reported yesterday |

## Open Questions

| Question | Notes |
|----------|-------|
| Which samples ship first? | Chosen for how different their shapes are, not their subject matter |
| What is the evidence status of each? | Production, demonstration or sketch, stated per sample |
| Is the diff format documented? | If the serialised pull request is the headline claim, its artefact needs a specification |
| Who maintains the samples? | A published example is a commitment, and stale ones undermine the rest |
| How is the plaintext condition stated? | Prominently enough that somebody skimming does not copy it into a private vault |
| Is the site's own build documented as a case study? | It is the best evidence available and is currently mentioned rather than shown |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 14 Aug | `v0.33.58__strategy-brief__sgit-why-section-is-a-boundary-map-scenarios-not-features-protocol-not-product.md` | The boundary table this corrects on pull requests, and the sample-vault argument this supplies the material for |
| 6 Aug | `v0.33.56__arch-brief__sg-send-plugins-are-capability-grants-ambient-authority-is-the-injection-root-cause-instrument-before-enforcing.md` | Ambient authority as the root cause, of which agent repository access is the clearest live example |
| 6 Aug | `v0.33.56__arch-brief__sg-send-git-and-sgit-in-one-folder-what-git-holds-decides-everything-ignore-file-is-the-blocker.md` | What git holds decides whether the vault is zero-knowledge, which the plaintext caution restates |
| 2 Aug | `v0.33.55__arch-brief__sg-send-vaults-as-substrate-asynchronous-agent-collaboration-through-encrypted-folders.md` | The blackboard paradigm, of which the site's own build is a production instance |
| 14 Aug | `v0.33.58__cross-team-brief__sgit-ai-agent-access-report-markdown-is-excellent-site-is-not-indexed.md` | The indexing finding that more client-rendered content makes more urgent |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The samples already exist and can be published as archives and as browsable embeds, which is wiring rather than building |
| 2 | An embedded sample removes the last step between reading and seeing, and demonstrates the read key by using it |
| 3 | Samples should be sorted by workflow shape rather than domain, with a stated evidence status each |
| 4 | Giving an agent repository write access is ambient authority, and the external evidence is now severe |
| 5 | One agent held a token scoped to every repository its developer had authorised |
| 6 | A disclosure nine days ago showed an issue from an account with no privileges reaching secrets in the vendors' own repositories |
| 7 | The capability to mint a short-lived single-repository token is an open feature request, so it does not exist |
| 8 | The serialised pull request issues no credential at all, which is stronger than a scoped one |
| 9 | Security guidance independently recommends the same shape: read-only analysis, then a constrained artefact into a privileged step |
| 10 | Pull requests as a hosted interface are absent; proposing reviewable changes without write access is present and better for agents |
| 11 | The site's own multi-agent build is a production instance of the blackboard paradigm and should be a case study |
| 12 | Committing plaintext alongside ciphertext is right for public samples and is a leak recipe without the qualifier |

---

## Sources

- Reporting that one coding agent held a repository token scoped to every repository the developer had authorised, the practitioner assessment that agents use far more permissions than a human would because of speed and scale, and the recommended principle that an agent acting on your behalf should never hold more privilege than you do: https://venturebeat.com/security/six-exploits-broke-ai-coding-agents-iam-never-saw-them
- The disclosure at Black Hat on 5 August 2026 that a repository issue opened by an account with no repository privileges was sufficient to reach continuous integration secrets in the vendors' own repositories for three leading agents under their own default unmodified workflow configurations, and the observation that removing the human from routine triage also removes the checkpoint that would catch a request from an untrusted source: https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-coding-agent-cicd-secrets-20260808-csa/
- The recommended secure split of running analysis in a read-only job with no deployment or publishing credentials and passing a constrained artefact or explicitly reviewed result into a separate privileged job, with the warning against a single job that both consumes untrusted input and can publish: https://windowsforum.com/windows-news.4/github-actions-ai-agents-remove-write-tokens-from-pr-jobs.441917/
- The documented attack class in which a single comment or issue causes credential exfiltration into publicly visible logs with no maintainer interaction, and the identification of excessive credential scope in workflow permissions as a principal cause: https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-github-actions-security-20260503-csa-st/ and https://labs.cloudsecurityalliance.org/research/csa-research-note-claude-code-github-action-prompt-injection/
- The open feature request from June 2026 for user-minted short-lived repository-scoped tokens for AI agents, noting that personal access tokens are long-lived and that application installation tokens require administrative setup, establishing that the capability is absent: https://github.com/orgs/community/discussions/200185
- Analysis finding that in each studied incident the attack succeeded because the agent held credentials it did not need for the task it was performing: https://www.cequence.ai/blog/ai/ai-agent-least-privilege-access/

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).