Skip to main content

NHI Governance

Your agents are identities, not API keys.

A service account that calls models, a cloud workload that triggers MCP tools, a cron job that runs a LoRA training sweep — these are Non-Human Identities (NHIs). Traditional API-key auth treats every bearer the same. That works until an agent is compromised, or drifts beyond its intended scope, or racks up a five-figure bill overnight. At that point, you need the same identity controls you already have for humans: tiers, ownership, risk scoring, revocation that cascades.

Trinitite's NHI Governance surface federates external identity providers, mirrors their agents as first-class NHIs, assigns privilege tiers, binds Guardians per-agent, and anchors every tool call to the ledger with the NHI's identity context attached.

Federate Every Provider You Already Use​

IDENTITY PROVIDERSAWS IAMRole ARN / IRSAGCP Workload IDService Account JWTK8s ServiceAcctOIDC bound tokenAstrixNHI discoveryAembitWorkload federationOIDC / SAMLCustom IdPNHI LAYERNon-Human IdentitiesMirrored IdentitiesImmutable NHI recordsTier SystemT0 → T3 privilegeRisk ScoringARS · nhi_postureConcentration RiskGuardian load spreadUNGOVERNED NHILiability surface · premium surchargeauto-routeGUARDIANAssigned bindinginput governanceoutput governancebidirectionalGLASS BOX LEDGEREvery verdict · every NHICryptographic · non-repudiationGOVERNANCE OUTCOMES

Register a provider once and Trinitite mirrors its identities as federated NHIs. Supported providers: AWS IAM (role ARN / IRSA), GCP Workload Identity (service-account JWT), Kubernetes ServiceAccounts (OIDC-bound tokens), Azure Managed Identities, Astrix, Aembit, and any OIDC or SAML provider.

Three modes of engagement per identity:

  • Observed — risk-scored, posture-tracked, surfaced in analytics. No governance binding yet.
  • Linked — mirrored to a Trinitite NHI. Observable and governable.
  • Auto-imported — newly-discovered identities from the provider are linked automatically and acquire a tier-default Guardian binding.

Observed-but-unlinked identities are your shadow NHI inventory — the agents your organization already runs but your governance stack hasn't caught up with. Federation surfaces them so the unknown unknowns become knowns.

Privilege Tiers, Not Role Sprawl​

NHI Privilege Tier Ladder

T0T0 — Read-only / SandboxedBLAST RADIUSSmallest blast radiusACCESSRead-only models · no tools · no spendT1T1 — Scoped ToolsBLAST RADIUSBounded blast radiusACCESSCurated tool allowlist · capped spend · no destructive opsT2T2 — Privileged OperationalBLAST RADIUSPer-action approval gatesACCESSWrite access · higher budgets · some destructive opsT3T3 — Break-Glass AdminBLAST RADIUSHighest privilege · heaviest auditACCESSFull tool surface · attested identity · every action logged

Every NHI request carries a tier claim. The Guardian, the tool allowlist, and the spend session all key off the same tier. Promotion from T1 → T2 is a controlled operation with a governance event, not a configuration tweak.

Four tiers. Not four hundred roles. Promotion is a governed operation with an audit event, not a config tweak. Every Guardian, every tool allowlist, every spend session keys off the same tier claim carried in the NHI JIT token.

This makes the blast radius of a compromised NHI quantifiable. A leaked T0 token gets you read-only chat. A leaked T3 token is the event that triggers your org's break-glass IR runbook.

One Guardian Per NHI Per Tool​

Guardian Binding Resolution — Per Request

NHI REQUEST{nhi_id, tier, tool, payload}1Explicit binding?(nhi_id, tool) → Guardian→ Use bound Guardian2Tier default?tier → Guardian for tool class→ Use tier-default3Org default?org → Guardian baseline→ Use org baseline4Otherwiseno binding resolves→ Deny · 403 + audit eventmissmissmissRESOLVED GUARDIAN → EVALUATE → PASS / CORRECT / BLOCKAll four steps + verdict written to the Glass Box LedgerGLASS BOX LEDGERnhi_id · binding_source · guardian_id · verdict · hash_chain

When a tool call arrives, Trinitite resolves the Guardian to use in this strict order:

  1. Explicit binding for this exact (nhi_id, tool) pair — the sharpest, most specific control.
  2. Tier default — the Guardian configured for this NHI's tier and this tool class.
  3. Org default — the Guardian configured for the whole organization for this tool class.
  4. Otherwise — deny with a 403, and emit a governance event. No silent pass-through.

All four steps are written to the Glass Box Ledger. A regulator asking "which Guardian made this decision for this agent at 02:13 UTC on Tuesday?" has one answer, cryptographically chained to every decision before and after it.

Risk Scoring and Anomaly Detection​

Every NHI carries real-time risk signals:

SignalWhat it catches
Action velocityAgents that suddenly 10× their normal call rate
Privilege escalationAttempts to use tools outside the tier's allowlist
Anomalous destinationsCloud resources, external hosts, or queries the agent has never touched before
Credential ageNHIs running on tokens past their recommended rotation window
MFA / attestation gapsFederated NHIs from providers that haven't attested identity in the expected cadence
ConcentrationToo much of the organisation's traffic flowing through a single NHI (blast-radius hotspot)

Aggregated into the Agentic Risk Score (nhi_posture dimension). A CRO or CISO can see the quartile distribution of NHIs by risk across the whole organisation and drill down to individual agents.

The /v1/proxy/nhi Surface​

For applications that want to register and manage NHIs directly (not via federation), Trinitite exposes a first-class NHI lifecycle API:

POST /v1/proxy/nhi/identities
{
  "external_id": "svc-agent-prod-01",
  "tier": "T1",
  "workload_origin": "k8s://prod/ns/agents/pod/xyz"
}

In response you get back a Trinitite-native NHI record. Agents then request short-lived JIT tokens via POST /v1/proxy/nhi/identities/:id/token and present them on the X-Trinitite-Nhi-Token header for every proxy / gateway / firewall call.

Spend sessions, emergency shutdown, and bulk revocation all flow through the Governance Controls surface and apply equally to federated and native NHIs.

What You Get​

CapabilityWithout NHI governanceWith Trinitite
Agent inventoryScattered across IAM, K8s, Astrix, and API-key tablesUnified federated registry
Privilege model"API key → everything"T0 / T1 / T2 / T3 with tier-aware tool allowlists
Blast radiusUnknown until incidentQuantifiable per-agent, per-tier
Risk signal"The account has been used a lot"Multi-signal ARS with anomaly heuristics
Forensic answerHand-stitched from logsSingle Guardian resolution trace in the ledger
Shadow NHIsInvisibleObserved-but-unlinked queue ready for triage

Tier Attestation​

Tier escalations are never unilateral configuration changes. An NHI cannot move from T2 → T1 without a fresh, signed Guardian verdict that the next-tier rubric still passes.

The escalation request runs the simulation, captures a guardian_approval_hash, and only the L2 control layer is willing to apply the new tier when that hash is fresh, signed, and bound to the requesting NHI. Stale or replayed hashes are rejected.

This makes a tier ladder enforceable rather than aspirational: the system itself refuses to let a privilege increase happen without a passing Guardian decision recorded against it.

Next Steps​

→ Identity & RBAC — the human-principal and API-key counterparts.

→ LLM Proxy — where NHI JIT tokens authenticate chat requests.

→ Governance Controls — the L0-L6 hierarchy that enforces tier decisions.

→ MCP Gateway — where per-tool Guardian bindings actually fire.

Last updated on