Non-Human Identity (NHI) Governance

1. The Problem

For every person in your organization, there are 45 non-human identities: service accounts, API keys, OAuth clients, CI/CD tokens, and machine-to-machine certificates (Astrix Security, 2024). Every one of them can access data, invoke services, and take actions. Unlike human users, they don't have managers who notice when something changes. They don't take vacations. They never stop running.

When a breach investigation asks "which service accounts had admin access to the production database on March 15th?", most organizations cannot answer with certainty. The identity provider's logs may show the answer -- or they may have been rotated, modified, or deleted. There is no independent record.

This is the core problem: the identity provider is both the actor and the record-keeper. It issues credentials, manages their lifecycle, and produces the only evidence that any of this happened correctly. If the IdP is compromised, both the credentials and the audit trail are compromised together.

The consequences are showing up in audits and incidents:

• Privilege escalation goes undetected. A service account's scope quietly widens from read:users to read:users write:admin. The change sits in an IdP log that nobody reviews until something breaks.
• Rotation compliance is self-reported. Your policy says "rotate keys every 90 days." Your evidence? The IdP's own assertion that rotation happened. An assessor has no way to independently verify that claim.
• Delegation chains become invisible. A parent service account delegates to a child, which delegates to a grandchild. When the parent is revoked, did the cascade propagate? Who has proof?
• Regulators are paying attention. NIST 800-53 IA-4/IA-5 require auditable credential governance. NIS-2 mandates cybersecurity risk management for identity infrastructure. The EU AI Act requires record-keeping for AI agent credentials. Five-Eyes guidance calls machine identity sprawl a top risk vector.

Organizations do not lack identity providers. They lack an independent witness -- someone outside the system who can confirm what happened, when, and whether it matches what was supposed to happen.

2. What SWT3 NHI Witnessing Is

Think of it as a notary for credential governance. Your identity provider (Entra ID, Okta, CyberArk, HashiCorp Vault, AWS IAM) continues to do its job. SWT3 independently records that specific governance events occurred, when they occurred, and what the state of the credential was at that moment.

This creates value in three scenarios:

1. Audit independence. When an assessor asks "prove that service account X was rotated on schedule," you produce both the IdP log and the SWT3 witness anchor. Two independent sources. If either is compromised, the other still stands.
2. Cross-platform correlation. A credential may traverse Entra ID, Vault, and a custom secrets manager. Each system logs in its own format. SWT3 provides a unified, cryptographically consistent record across all of them.
3. Tamper evidence. SWT3 anchors are SHA-256 fingerprinted. If anyone modifies the record after the fact, the fingerprint breaks. This is not possible with application logs.

SWT3 NHI witnessing complements your existing identity stack. It adds an evidence layer. It does not add an identity layer.

3. Six NHI Procedures

The SWT3 Universal Control Taxonomy defines six procedures in the NHI namespace. Each procedure corresponds to a specific governance event in the credential lifecycle.

4. Quick Start (Python)

Five lines to create your first NHI witness anchor.

from swt3_ai import Witness

witness = Witness(
    tenant_id="acme-corp",
    api_key="axm_...",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Witness the scope granted to a service account
witness.witness_nhi_scope(
    credential_id="svc-account-xyz",
    scope="read:users write:logs",
    ttl_seconds=3600
)

# Witness a lifecycle event (credential issued)
witness.witness_nhi_lifecycle(
    event_type="issued",
    credential_id="svc-account-xyz",
    issuer="Entra ID"
)

5. Quick Start (TypeScript)

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
  tenantId: "acme-corp",
  apiKey: "axm_...",
  endpoint: "https://sovereign.tenova.io/api/v1/witness"
});

// Witness the scope granted to a service account
witness.witnessNhiScope({
  credentialId: "svc-account-xyz",
  scope: "read:users write:logs",
  ttlSeconds: 3600
});

// Witness a lifecycle event (credential issued)
witness.witnessNhiLifecycle({
  eventType: "issued",
  credentialId: "svc-account-xyz",
  issuer: "Entra ID"
});

6. Credential Lifecycle Chain

A credential moves through a series of states over its lifetime. Each state transition is a governance-relevant event that should be witnessed independently.

Each witness_nhi_lifecycle call records the event type (issued, activated, suspended, expired, or revoked), the credential identifier, and the issuing system. Because every anchor includes the credential identifier in its fingerprint, the full chain of state transitions for any credential can be reconstructed from the ledger.

# Python: witness the full lifecycle of a credential
witness.witness_nhi_lifecycle(event_type="issued", credential_id="svc-account-xyz", issuer="Entra ID")

# ... credential is activated ...
witness.witness_nhi_lifecycle(event_type="activated", credential_id="svc-account-xyz", issuer="Entra ID")

# ... credential is suspended for investigation ...
witness.witness_nhi_lifecycle(event_type="suspended", credential_id="svc-account-xyz", issuer="Entra ID")

# ... credential is permanently revoked ...
witness.witness_nhi_lifecycle(event_type="revoked", credential_id="svc-account-xyz", issuer="Entra ID")

7. Rotation Tracking

Credential rotation is a core compliance requirement (NIST IA-5, every major framework). The challenge is proving that rotation actually happened and that the old credential was properly decommissioned.

The witness_nhi_rotation method creates a cryptographic link between the old and new credential identifiers. Both identifiers are included in the anchor's fingerprint, so the rotation event is bound to both credentials.

# Python: witness a scheduled key rotation
witness.witness_nhi_rotation(
    old_credential_id="svc-key-v1",
    new_credential_id="svc-key-v2",
    reason="scheduled"
)

# Rotation after a compromise
witness.witness_nhi_rotation(
    old_credential_id="svc-key-v2",
    new_credential_id="svc-key-v3",
    reason="compromise"
)

// TypeScript: same rotation events
witness.witnessNhiRotation({
  oldCredentialId: "svc-key-v1",
  newCredentialId: "svc-key-v2",
  reason: "scheduled"
});

witness.witnessNhiRotation({
  oldCredentialId: "svc-key-v2",
  newCredentialId: "svc-key-v3",
  reason: "compromise"
});

Four rotation reasons are supported:

8. Delegation and Cascade Revocation

Delegation Trees

In agentic AI systems and microservice architectures, one credential often delegates authority to another. A parent service account creates a child token, which may create a grandchild token. The delegation tree can grow deep, and each level introduces risk.

# Python: witness a delegation chain
witness.witness_nhi_delegation(
    delegator_credential_id="svc-parent",
    delegatee_credential_id="svc-child",
    delegation_depth=1
)

witness.witness_nhi_delegation(
    delegator_credential_id="svc-child",
    delegatee_credential_id="svc-grandchild",
    delegation_depth=2
)

// TypeScript: same delegation chain
witness.witnessNhiDelegation({
  delegatorCredentialId: "svc-parent",
  delegateeCredentialId: "svc-child",
  delegationDepth: 1
});

witness.witnessNhiDelegation({
  delegatorCredentialId: "svc-child",
  delegateeCredentialId: "svc-grandchild",
  delegationDepth: 2
});

The delegation_depth parameter records how many levels deep this delegation sits in the tree. Depth 1 is a direct delegation. Depth 2+ indicates transitive delegation. This gives assessors visibility into how far authority propagates from the original credential holder.

Cascade Revocation

When a parent credential is revoked, all downstream delegations should be revoked as well. The witness_nhi_revocation method records the revocation event and whether cascade was requested.

# Python: revoke with cascade
witness.witness_nhi_revocation(
    credential_id="svc-parent",
    reason="policy_violation",
    cascade=True
)

# The identity provider handles the actual cascade.
# SWT3 witnesses each downstream revocation independently.
witness.witness_nhi_revocation(
    credential_id="svc-child",
    reason="policy_violation",
    cascade=True
)

witness.witness_nhi_revocation(
    credential_id="svc-grandchild",
    reason="policy_violation",
    cascade=False  # leaf node, no further cascade
)

Seven revocation reason codes are supported:

9. Integration Patterns

The most common integration pattern is event-driven: your identity provider fires a webhook or log event, and your integration layer calls the appropriate SWT3 witness method.

Privilege Change Monitoring

One of the highest-risk NHI governance events is a privilege escalation. The witness_nhi_privilege_change method records the before-and-after scope, creating an independent record of what changed.

# Python: witness a privilege change from an IdP webhook
witness.witness_nhi_privilege_change(
    credential_id="svc-account-xyz",
    previous_scope="read:users",
    new_scope="read:users write:admin"
)

// TypeScript: same privilege change
witness.witnessNhiPrivilegeChange({
  credentialId: "svc-account-xyz",
  previousScope: "read:users",
  newScope: "read:users write:admin"
});

Batch Processing

For environments with high credential churn (CI/CD pipelines, ephemeral containers, serverless functions), the SDK buffers witness payloads and flushes them in configurable batches. This is handled automatically by the SDK's flush interval. No special batch code is needed.

10. What the Assessor Sees

Each NHI witness event produces a SWT3 Witness Anchor. Here is a representative anchor from a scope attestation:

SWT3-E-CLOUD-NHI-SCOPE1-PASS-1756627200-a3f7c920e4b1

The anchor decomposes as follows:

Evidence Fields

Beyond the anchor string, each witness record includes structured evidence that the assessor can inspect.

11. Regulatory Mapping

Each NHI procedure maps to specific requirements across multiple regulatory frameworks.

12. Getting Started

Install the SDK for your language:

# Python
pip install swt3-ai

# TypeScript / Node.js
npm install @tenova/swt3-ai

Initialize the witness, point it at your credential governance events, and every NHI lifecycle action produces an independent, cryptographically anchored audit record.

Both SDKs support demo mode (omit the API key) for local evaluation. Witness records log to stderr with no network calls. When you are ready for persistent evidence, create a free account and set the API key.

• SDK documentation -- Python, TypeScript, and 8 additional languages
• UCT Registry -- full procedure catalog with regulatory crosswalks
• Anchor Verifier -- independently verify any SWT3 Witness Anchor
• Create a free account -- instant tenant provisioning, API key on screen
• All compliance guides -- 225 guides across AI governance, GRC, and identity