# nhi.sgit.ai: The Question Splits Into Two Populations, And The Industry Only Answers One Of Them

**version** v0.33.59
**date** 16 August 2026
**from** Human (project lead)
**to** The sgit.ai site agent, Research

**type** Strategy brief

*Tenth of 16 August. Scopes a new site and the research that anchors it. The market shape is checked and cited; the research itself is deliberately not done here. Contains a thesis worth testing rather than assuming.*

---

## What This Is

A site collecting existing work on non-human identity, blast radius and agentic security, plus new research answering one question, and a finding from scoping that research which should become the site's thesis: **the question asked is how to give an identity to agents running in a coding assistant, a chat interface, a hosted coding tool or behind an API, and that question splits into two populations with completely different answers, because everything the industry sells assumes agents you run, meaning workloads in your own infrastructure that can be attested by something you installed, whereas the agents named are agents you rent, running in somebody else's infrastructure where you cannot install an attestation agent, cannot verify the workload and have exactly one lever, which is what credential you hand over and what it can reach; for the first population the answer is mature and expensive, since an open standard issues short-lived cryptographic identities based on attestation and is described by practitioners as a multi-year engineering project with compounding operational costs requiring a dedicated team, and commercial products broker access without standing secrets; for the second population there is no equivalent answer, which the corpus already evidenced on 14 August when it found the platform feature request for short-lived repository-scoped tokens for agents still open, one assistant holding a token scoped to every repository its developer had authorised, and a disclosure showing an issue from an unprivileged account reaching pipeline secrets; that asymmetry is the site's thesis and it is defensible, unusual and useful, because vendors do not address it since they sell to people running their own workloads, and it explains why a practitioner's honest answer today is to hand over a credential and hope; the research should therefore be structured around answering one concrete scenario per option rather than producing a vendor list, using the reproducible-test discipline settled earlier today, with cost split into setup, per-identity and per-use, and with privileges granted as the differentiating column; and the participant problem applies, since vaults are a candidate answer to where agent secrets live, so the site must publish its method, state where it loses, and be explicit about who is writing it.** It is the tenth document of 16 August (cross-ref: the v0.33.52 outbound maturity model, the v0.33.58 serialised pull request brief, the v0.33.59 comparison pages brief, the v0.33.56 plugins brief, and the v0.33.59 relay pattern brief). New contributions: **the two-populations split as the site's thesis, the industry answer located against the wrong population, the research scoped as scenarios rather than a vendor survey, the cost axes, and the participant disclosure requirement.**

## The Thesis, Found While Scoping

The site needs a position rather than a collection, and scoping the research produced one.

The memo's question is concrete and worth quoting because its concreteness is what exposes the gap. The project lead: **"how do I give an identity to my agents, like the ones that I have running in Claude, the one I have running in Claude Code, Claude Web, the ones that run in Codex, the ones that I just run through an API."**

**Every one of those is an agent you rent, not an agent you run.** And the entire industry answer assumes the opposite.

| | Agents you run | Agents you rent |
|---|---|---|
| Where it executes | Your infrastructure | Somebody else's |
| Can you attest the workload | Yes, that is the mechanism | **No** |
| Can you install an identity agent | Yes | **No** |
| What you control | Everything | **The credential you hand over** |
| Industry answer | Mature, and expensive | **None** |

The mature answer for the first population is real: an open standard assigns each workload a cryptographic identity and issues short-lived certificates that rotate automatically, without long-lived secrets, and a major secrets product now issues those identities natively. A mid-2026 reference architecture pairs that identity layer with relationship-based authorisation and an enforcement layer for tool calls.

**It also costs what it costs.** Practitioner analysis describes the reference implementation as a significant multi-year engineering project with compounding operational costs, demanding a dedicated team to deploy, scale, maintain and secure, alongside datastores, certificate infrastructure, proxy configuration, policy and monitoring. The same analysis notes it does not solve the software-as-a-service access problem, legacy credential types, or agent identity specifically.

**And for the second population there is no answer at all.** The corpus established this on 14 August: the platform feature request for user-minted short-lived repository-scoped tokens for agents is open, one coding assistant held a token scoped to every repository its developer had authorised, and a disclosure showed an issue opened by an account with no repository privileges reaching pipeline secrets in three vendors' own repositories.

So the practitioner's honest position today is: **hand over a broad credential and hope.** That is worth saying plainly, on a site, with evidence, because nobody selling into this market has a reason to say it.

## Why This Is A Defensible Position

Three reasons it holds up rather than being a complaint.

**It is falsifiable.** The claim is that for rented agents there is no way to issue a scoped, short-lived, attested identity. Anybody who can show one refutes it, and the site improves.

**It is evidenced rather than asserted.** An open feature request, a documented over-broad token, and a public disclosure are all checkable.

**And it explains the failures people are already seeing.** Industry commentary from 2026 frames the gap as visibility not being enforcement, and surveys report low confidence in preventing identity-based attacks and a substantial share of organisations not tracking creation of agent-related identities at all. The two-populations split explains why: the tools that provide enforcement require a workload you control, and the agents causing concern are not.

## What The Research Must Answer

The memo asks for research and the risk is a vendor list, which is worthless and dates in weeks. **The research should answer one concrete scenario per option**, which makes it comparable, checkable and re-runnable.

The scenario, drawn from the memo:

> I have four agents. Each needs its own identity. Each needs access to a different vault, which means each needs a secret. One also needs access to one repository. Nobody should be able to use another's access. Show me how, what it costs to set up, what it costs per agent per month, and what each agent could reach if it were compromised.

Every option gets the same scenario and the same columns, which is the reproducible-test discipline settled earlier today:

| Column | Why |
|---|---|
| **Steps to working** | Countable, disputable on facts |
| **Prerequisites** | Accounts, subscriptions, infrastructure, a team |
| **Privileges granted** | What one compromised agent reaches. The differentiating column |
| **Setup cost** | Once, including engineering time honestly estimated |
| **Cost per identity per month** | The scaling axis |
| **Cost per use** | Where metered |
| **Runs where** | Their infrastructure, yours, or serverless |
| **Works for rented agents** | **The question the thesis turns on** |
| **Date verified** | Because this dates in weeks |

The last two are the ones that make this research worth doing rather than repeating what exists.

## Scope Boundaries For The Research

Five things get bundled under identity and they are different markets. Naming them prevents the research sprawling.

| Concern | The question |
|---|---|
| **Authentication** | How does the thing prove it is who it says |
| **Authorisation** | What may it then do |
| **Secret storage** | Where do its credentials live |
| **Audit** | What did it do, attributably |
| **Lifecycle** | Who created it, who owns it, when does it die |

The memo's scenario touches authentication, secret storage and authorisation. **Lifecycle and audit should be noted per option and not investigated in depth**, or the research becomes a market survey.

One finding from scoping worth carrying in: mature programmes are described as combining a discovery and posture layer, a secrets layer and a workload identity layer under one policy. So most options answer **part** of the question, and the research should record which part rather than scoring them as if they competed.

## The Participant Problem

The site is hosted on the sgit domain, and vaults are a candidate answer to where an agent's secrets live and how scoped access is granted. **So this is a participant publishing a comparison**, which the corpus addressed earlier today.

The answer is the same and it should be visible on the site rather than in a footer:

**State who is writing it.** A reader who discovers the affiliation later discounts everything; a reader told upfront judges the method.

**Publish the method and make it re-runnable.** An assertion from a participant is marketing. A dated test somebody else can repeat is evidence.

**And publish where our own approach loses.** Vaults do not solve attestation, do not provide lifecycle governance, and do not answer the rented-agent problem either, which is worth stating because it is true and because a site that only names other people's gaps is not read as research.

## The Collection Half

The memo's first request, and the material is substantial. The project lead: **"the combination or the collection of all the research and documents that I have been publishing around NHI and around blast radius and agentic security."**

The repository already carries a great deal: **121 documents mention non-human identity and 315 mention blast radius.** That is more than a site can present as a list, which makes curation the work rather than collection.

Three things to get right.

**Organise by question, not by date.** A reader arrives with a problem, not with an interest in chronology. What is an agent allowed to do, what happens when one is compromised, how do you bound spend, how do you attribute an action.

**Promote the named frameworks.** The outbound maturity model of 27 July, with its five preconditions and its finding that spend and time ceilings are the cheapest unimplemented controls, is the strongest single artefact in the collection and should be a page rather than an entry.

**And link the published infographics.** The memo mentions these are on a social platform and offers references. They are the most shareable assets in the set and they should point back to the underlying documents rather than standing alone.

## Same Pattern As The Other Site

The memo asks for this and it means the build is largely known. The project lead: **"it's a website that has both the code and the sgit files, so we basically have git and sgit on the same repo, which is quite a cool pattern."**

So the conventions carry over: the machine-readable index, the single-file concatenation, evidence status per claim, the honest limitations page, and the git-and-vault co-existence pattern with its documented ignore requirement.

Two additions specific to this site. Every research entry carries a **verification date and a re-run method**, per the comparison discipline. And the **thesis belongs on the front page** rather than being discoverable, because a collection without a position is an archive.

## What This Site Is For

Worth stating, because it determines what success looks like.

**It is not a vendor directory.** Those exist and date immediately.

**It is an answer to a question practitioners are actually asking and cannot currently answer**, with the evidence for why they cannot, and an honest map of what each available option does and does not cover.

The measure is whether somebody with four agents and four vaults can read it and know what to do next, including when the answer is that nothing available does what they want.

## Build Order

1. **The thesis page.** Two populations, why the industry answers one, what the evidence is. Short, and it is the reason to visit.
2. **The scenario and the columns**, published before any option is assessed, so the method precedes the findings.
3. **Three options assessed**, chosen to be different in kind: the open standard, a commercial broker, and the do-nothing baseline of handing over a credential.
4. **The collection**, organised by question, with the maturity model promoted to a page.
5. **The infographics**, linked to their sources.
6. **More options over time**, each dated, each re-runnable.

Step two before step three matters. **Publishing the method before the results is what makes a participant's comparison credible**, and it is cheap to do in that order and impossible to claim afterwards.

## What This Does Not Try To Be

- **Not a vendor list.** One scenario, answered per option, with a stated method.
- **Not neutral.** A participant, disclosed, publishing a re-runnable method.
- **Not a chronological archive.** Organised by the question a reader arrives with.
- **Not silent on our own gaps.** Vaults do not solve attestation or the rented-agent problem either.
- **Not the research itself.** This scopes it; the research is its own piece of work.

## Honest Tensions

| Tension | Note |
|---------|------|
| The two-populations thesis | It is sharp and defensible and it says the market's main answer does not fit the named use case, which invites correction from people who sell it |
| A participant comparing | Method and disclosure make it credible and some readers will discount it regardless |
| One scenario | It makes options comparable and it will not represent an enterprise with thousands of identities |
| Curating 400 documents | Curation is the value and it means most of the existing material will not appear |
| Estimating engineering cost | It is the largest real cost and the hardest number to defend |
| Publishing our own gaps | It is what makes the rest credible and it is a page competitors will quote |

## Open Questions

| Question | Notes |
|----------|-------|
| Which three options first? | Different in kind rather than three of the same category |
| How is engineering time costed? | The dominant cost for the open standard, and the number most likely to be argued with |
| Does the do-nothing baseline get assessed properly? | It should, since it is what almost everybody is actually doing |
| Where do the infographics live? | Linked or mirrored, and mirroring raises a rights question |
| Who re-runs the assessments? | The dating discipline creates a queue that needs an owner |
| Is the thesis tested before publication? | Somebody should try to refute it first, and a wrong thesis on a front page is expensive |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 27 Jul | `v0.33.52__arch-brief__sg-send-agentic-outbound-maturity-model-aomm-reach-motive-freedom-silence-could-has-will-liability.md` | The strongest artefact in the collection, and the framework the site should lead with |
| 14 Aug | `v0.33.58__strategy-brief__sgit-serialised-pull-request-is-the-headline-publish-the-sample-vaults.md` | The evidence that rented agents have no scoped credential mechanism |
| 16 Aug | `v0.33.59__strategy-brief__sgit-comparison-pages-as-reproducible-tests-privileges-is-the-missing-column.md` | The method: dated, re-runnable, with privileges granted as the differentiating column |
| 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 underlying problem the whole site is about |
| 16 Aug | `v0.33.59__arch-brief__relay-pattern-encryption-signing-and-ordering-are-three-mechanisms.md` | Per-agent keys as one answer, and its stated limits |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The question splits into agents you run and agents you rent, and they have different answers |
| 2 | Every agent named in the memo is rented, running where you cannot attest or install anything |
| 3 | For agents you run the answer is mature: attested short-lived cryptographic identities from an open standard |
| 4 | It is also described as a multi-year engineering project with compounding costs and a dedicated team |
| 5 | For rented agents there is no equivalent, and the corpus already evidenced the gap on 14 August |
| 6 | The honest current practice is to hand over a broad credential and hope |
| 7 | That asymmetry is the site's thesis: falsifiable, evidenced, and unsaid by anybody selling into the market |
| 8 | It explains the reported failures, since enforcement tools need a workload you control |
| 9 | The research answers one concrete scenario per option rather than surveying vendors |
| 10 | Cost splits into setup, per identity and per use, with engineering time as the dominant and hardest number |
| 11 | Five concerns get bundled as identity, and the research should scope to three of them |
| 12 | The participant problem applies, so publish the method before the findings and state where our own approach loses |

---

## Sources

- The open workload identity standard assigning each workload a unique identifier and issuing short-lived certificates that rotate automatically without long-lived secrets, its reference implementation, and native issuance of those identities by a major secrets product for non-human workloads including agents: https://www.hashicorp.com/en/blog/spiffe-securing-the-identity-of-agentic-ai-and-non-human-actors and https://stack-archive.com/blog/hashicorp-vault-spiffe-ai-agent-identity-nhi-2026/
- Practitioner analysis describing the reference implementation as a significant multi-year engineering project with compounding operational costs requiring a dedicated team alongside datastores, certificate infrastructure, proxy configuration, policy and monitoring, and noting that it does not by itself solve software-as-a-service access, legacy credential types or agent identity: https://aembit.io/blog/everyone-wants-spiffe-almost-no-one-can-afford-to-build-it-right/ and https://aembit.io/blog/10-identity-security-vendors-for-ai-agents-strengths-tradeoffs-and-how-they-fit/
- The characterisation of mature programmes as combining a discovery and posture layer, a secrets layer and a workload identity layer under one policy, with the goal that every identity is known, least-privileged, short-lived and revocable: https://guptadeepak.com/top-non-human-identity-nhi-management-tools-2026/
- A mid-2026 reference architecture pairing the identity layer with relationship-based authorisation and an enforcement layer checking every tool call: https://stacklok.com/blog/agentic-identity-explained-how-to-apply-spiffe-and-relationship-based-authorization-to-ai-agents-in-2026/
- Reported figures on the governance gap, including low confidence in preventing identity-based attacks, a share of organisations not tracking creation of agent-related identities, identities lacking ownership linkage after their creator departs, and the framing that visibility is not enforcement: https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/

---

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