nhi.sgit.ai / method

The method, published before the findings

The risk in this research is producing a vendor list, which is worthless and dates in weeks. Instead, every option answers one concrete scenario in the same columns — which makes the options comparable, the claims checkable, and the whole thing re-runnable by anybody. Publishing the method before any option is assessed is what makes a participant's comparison credible, and it is impossible to claim afterwards.

The scenario

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 this scenario — no substitutions, no "in the enterprise case" escapes. An option that cannot express the scenario says so in its assessment.

The columns

ColumnWhy it is there
Steps to workingCountable, disputable on facts
PrerequisitesAccounts, subscriptions, infrastructure, a team
Privileges grantedWhat one compromised agent reaches. The differentiating column
Setup costOnce, including engineering time honestly estimated
Cost per identity per monthThe scaling axis
Cost per useWhere metered
Runs whereTheir infrastructure, yours, or serverless
Works for rented agentsThe question the thesis turns on
Date verifiedBecause this dates in weeks

The last two columns are what make this research worth doing rather than repeating what exists.

Scope boundaries

Five things get bundled under "identity" and they are different markets. Naming them keeps the research from sprawling:

ConcernThe questionIn scope?
AuthenticationHow does the thing prove it is who it says?Yes — the scenario touches it
AuthorisationWhat may it then do?Yes — the scenario touches it
Secret storageWhere do its credentials live?Yes — the scenario touches it
AuditWhat did it do, attributably?Noted per option, not investigated in depth
LifecycleWho created it, who owns it, when does it die?Noted per option, not investigated in depth

One finding carried in from scoping: mature programmes combine a discovery-and-posture layer, a secrets layer and a workload-identity layer under one policy. Most options answer part of the question — so the assessments record which part, rather than scoring options as if they competed head-on.

The reproducible-test discipline

The participant problem

This site is hosted on the sgit domain, and vaults are a candidate answer to where an agent's secrets live. So this is a participant publishing a comparison. The treatment, visible rather than buried:

Build order

  1. The thesis page — done: two populations.
  2. The scenario and the columns — this page, published before any option is assessed.
  3. Three options assessed, chosen to be different in kind: the open standard, a commercial broker, and the do-nothing baseline. Currently preliminary: sourced from published analysis, not yet re-run hands-on. Each page says so.
  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.

One question, several scenarios

The four-agents-four-vaults scenario above is the anchor, but the discipline generalises: any concrete scenario, answered per option in stated columns, with a verification date. The first additional scenario is published: shared drives for agents — two sessions sharing a file area — where three requirement rows (per-agent identity, agent-level attribution, encryption to a specific agent) came back empty across the surveyed market. That research is the thesis's first concrete instance, and its empty rows are standing refutation targets.