What NHI Governance Means for Product Teams
Non-human identity, usually abbreviated as NHI in this context, refers to any digital credential that represents a machine, service, workload, application, API client, automated agent, or other software entity rather than a person. Product teams create and depend on these identities whenever an AI feature calls a model, a mobile app accesses a cloud service, or a deployment pipeline uses a service account. Governance is the system of assigning ownership, limiting permissions, rotating credentials, recording activity, reviewing access, and removing identities that are no longer needed. The direct answer is that product teams should treat NHI governance as a product operating requirement, not as a cleanup project owned only by security. As of 30 September 2026, rapid growth in software agents and machine identities makes this distinction important: identity is becoming the control point through which automated activity receives access. Governance does not mean preventing automation or placing a human approval in front of every machine action. It means making machine access attributable, bounded, observable, reversible, and removable. For B2B UX teams, that translates into researchable ownership, clear lifecycle states, usable administrator experiences, and evidence that customers can inspect. A governance process that exists only in spreadsheets or scanner output will struggle once the number of identities grows beyond what one person can review manually.
Also worth reading: What is AI agent identity and access management, and how should teams manage identities for AI agents in 2026? · Who Should Own Each SaaS Metric in Product, Design, and Revenue Teams? · How Should B2B UX Enablement Academy Software Work for Product Teams in 2026?
The acronym needs disambiguation. In cybersecurity, NHI commonly means non-human identity; in South Africa, the National Health Insurance Act of 2023 and the proposed national health insurance system also use “NHI.” This article addresses non-human identities only. The two meanings share little beyond the acronym, so product documentation should write “non-human identity” at first mention and define the relevant entity types. That small editorial choice prevents search ambiguity, reduces support tickets, and makes policy language more precise. Product teams should not assume that every credential behaves like a workforce login. Some identities are long-lived deployment subjects, some are temporary workloads, and others belong to third-party integrations whose rotation requires coordination with a vendor.
Why Machine Identities Are Growing Faster Than Conventional Controls
Software now creates machine identities whenever developers automate a task that previously required a person to log in. A CI/CD job needs a deployment token, an analytics pipeline needs a database role, a customer integration needs an API key, and an AI agent needs permission to retrieve enterprise data or invoke another tool. Each addition can be operationally reasonable while still expanding the attack surface if ownership and expiry are unspecified. Identity has therefore become a practical perimeter: once a secret is copied, the system receiving it generally cannot determine whether the caller is an authorized workload, a compromised repository, or an attacker replaying the same credential. GitGuardian frames NHI governance as the desired outcome rather than the vendor or product category, which is a useful distinction. Governance is the result; a secret scanner, vault, access-control platform, or identity provider may support that result, but none by itself proves that the entire lifecycle is controlled.
The volume matters as much as the individual risk. Human access reviews assume that an employee can explain a role, an owner can approve it, and an identity can be removed during offboarding. A machine account may have no employee, may be shared by several services, or may continue running after its creator leaves. A 2026-era product can contain thousands of credentials across production, staging, customer tenants, developer machines, and temporary environments without displaying thousands of identities in a single user interface. Consequently, percentages and thresholds should come from the organization’s own exposure rather than an arbitrary industry claim. A practical starting point is to inventory all credential-bearing repositories, cloud accounts, CI/CD systems, API gateways, and agent platforms; count unique and duplicated secrets; then set a target such as eliminating hard-coded production secrets within 90 days and reducing unidentified privileged credentials within 180 days. Those are management targets, not universal security statistics, and teams should adjust them to regulatory obligations and risk.
The Ownership and Lifecycle Model Product Teams Need
Every non-human identity should have a named business or technical owner, a machine-readable purpose, an environment, a risk tier, an expiry or review date, and a revocation procedure. The owner can be a platform engineer, product manager, security architect, or service team, but “the platform team” is rarely specific enough when several teams share the same account. The purpose should describe the actions the identity can perform rather than merely saying “for API,” because that statement does not establish least privilege. Environment labels such as production, customer, test, and development help prevent a convenient test credential from receiving production access. A lifecycle model normally covers creation, validation, use, rotation, suspension, and deletion, with automated checks where APIs and policy engines permit them. Temporary workloads should receive short-lived credentials instead of static secrets; long-lived exceptions should be recorded, reviewed, and eventually retired.
A useful risk tier separates low-value test identities from production, customer-data, payment, administrative, and cross-tenant permissions. Organizations can set concrete review intervals: monthly for privileged or production identities, quarterly for standard service identities, and immediately after a suspected exposure, ownership change, vendor termination, or service retirement. Those intervals should be tested against staffing; a quarterly review that can only be completed in bulk at year-end is not a meaningful control. Teams should also define what happens when an owner leaves, a repository is archived, or a customer disables an integration. Default behavior should be disablement or quarantine when ownership cannot be verified, followed by restoration only after an accountable person accepts the access. For AI-enabled products, add model, tool, data-source, and spending permissions to the record because an agent identity can cause harm even when it lacks conventional administrator rights.
A product team can make governance more usable by treating exceptions as interface states. Instead of exposing a raw list of keys, an administration experience can show whether each identity is healthy, duplicated, over-privileged, expiring, or orphaned. It can indicate which business feature will fail if the credential is revoked and provide a safe test for the replacement. UX research should include administrators who do not write code, because encryption is effective only if the people responsible for business configuration can rotate and remove access. Measure completion rather than information availability: the important number is the share of identities with verified owners and tested revocation, not the number of fields displayed in a table. This connects identity controls to product design while avoiding a dashboard that creates confidence without operational follow-through.
A Practical 90-Day Governance Program
The first 30 days should establish visibility and scope. Product and security teams can connect repository scanning, cloud inventories, CI/CD configuration, secret-management platforms, API gateways, and relevant SaaS audit logs to a common inventory. They should identify static secrets, service accounts, signing keys, OAuth clients, machine identities, and AI tool credentials, while excluding sample values from tickets and analytics. Deduplication is essential because one leaked key copied into five repositories remains one underlying exposure but creates five cleanup tasks. The team should set a baseline with at least five measures: number of known identities, percentage with an owner, percentage with a documented purpose, number of hard-coded production secrets, and age of the oldest privileged credential. Absolute counts alone can be misleading, so record environment, privilege, customer reach, and internet exposure beside each item.
Days 31 through 60 should convert the inventory into enforceable rules. Production secrets should be blocked from source control, while protected branches should require a manager and security reviewer for exceptions. CI jobs should receive workload identities or short-lived tokens rather than repository-wide API keys. Service roles should be reduced to the actions each workload needs, and wildcard permissions should be removed or time-bound. Teams can set a practical zero-tolerance threshold for plaintext production secrets in active branches, allowing only time-limited migration exceptions. For customer-facing products, administrators should be able to create, scope, rotate, suspend, and delete integration credentials without contacting support. During this phase, pilot the process with one product containing AI agents, one customer integration, and one internal deployment pipeline so that edge cases appear before enterprise-wide rollout.
Days 61 through 90 should test whether governance works when people, software, and vendors change. Revoke a noncritical test identity, rotate one service credential, and confirm that the dependent workflow fails or recovers as designed. Remove an identity owned by a departing engineer and verify that no production dependency is hidden. Ask each product owner to approve the remaining privileged exceptions and assign a review date to every one. Establish a weekly exception review and a monthly report to product leadership, with details such as 100% of internet-exposed production secrets remediated, at least 95% of active identities assigned an owner, and at least 90% of privileged accounts reviewed on schedule. These are target examples rather than claims about current industry performance. After 90 days, continue the cycle, measure exceptions by age, and add automation only where it removes repeated work without obscuring accountability.
Governance, Secrets Management, and Zero-Trust Automation Compared
No single tool category solves NHI governance. A secrets manager protects values and may issue dynamic credentials, but it cannot determine whether a permission is appropriate or whether a business still needs an integration. A scanner finds exposed material in code and collaboration systems, but it may not know the complete set of identities in a cloud tenant or SaaS application. A privileged access management system controls human access and can cover some machine accounts, yet it may not map those accounts to product capabilities. An identity provider can issue short-lived workload credentials, but only if application architecture supports them. A CI/CD governance platform can enforce pipeline policy, but external customer integrations may remain outside its view. The correct approach is layered control with a shared inventory and accountable ownership rather than a search for one perfect vendor.
| Governance need | Central secrets manager | Code and secret scanner | Workload identity and access control | Product-native integration settings |
|---|---|---|---|---|
| Core purpose | Stores and rotates secret values | Finds committed or exposed secrets | Authenticates workloads and limits actions | Creates, scopes, and revokes customer integrations |
| Ownership discovery | Moderate; depends on metadata integrations | Limited to scanned repositories | Strong in managed infrastructure | Strong when tied to accounts, workspaces, and products |
| Short-lived credentials | Often supports issuance through connected systems | Rarely its primary function | Usually a central capability | May support token expiry, but varies by architecture |
| Product design role | Administrator setup and recovery UX | Engineering remediation workflow | Policy and migration UX | Customer-facing trust, usability, and self-service UX |
| Main limitation | Does not prove business necessity | Cannot see every credential type | Requires workload migration and policy work | Cannot govern internal or third-party identities alone |
Common Mistakes That Make NHI Programs Stall
The most common failure is equating secret rotation with governance. Rotation limits the useful life of a credential, but an unowned account can still retain excessive permissions, and a shared owner can disappear immediately after replacement. Another mistake is purchasing a dashboard and declaring risk reduced because the dashboard contains many findings. Findings require triage, ownership, remediation, and verification; a count of 10,000 unresolved items is not equivalent to a count of 10,000 controlled identities. Teams also tend to prioritize internet-facing repositories while overlooking internal build systems, lower-environment accounts, customer sandboxes, and software agents. Security questionnaires can reveal whether controls exist, but they rarely test whether credentials can be revoked during an emergency. Attackers and auditors will test paths that product teams did not document.
Overcorrecting is equally damaging. Blocking all new credentials can stall development if the replacement workflow takes days, while allowing broad temporary exceptions can make the temporary state permanent. AI automation adds a special hazard: an agent may chain a model permission, a data connector, and a payment or communication tool without a human approving each action. Excessive autonomy should therefore be limited through scoped tools, spending ceilings, action logs, rate limits, and emergency stop controls. Do not build a governance system that treats every machine as hostile; many machine identities are safer than passwords because they are short-lived and observable. Balance friction with risk by applying strong controls to production, customer data, money movement, privileged actions, and external exposure while using lighter review for isolated test credentials. Measure false positives and failed deployment rate so the program can improve rather than become a source of alert fatigue.
When Product Teams Should Act Before 2027
Immediate action is warranted when an identity is internet-exposed, hard-coded in source control, privileged, tied to customer data, or connected to an autonomous agent that can invoke external tools. Teams should also act if an account has no identified owner, has remained unchanged for more than one year, or cannot be rotated without guessing. A useful trigger is any new AI feature entering pilot, because permissions granted during experimentation can survive long after the pilot ends. Another trigger is a merger, major acquisition, contractor departure, repository transfer, or migration from one cloud or identity platform to another. Vendor contract changes and customer offboarding also require machine-identity review because integrations frequently outlive the employees who configured them. These conditions do not justify emergency redesign of every credential on the same day; they justify containing active exposure and scheduling verified remediation.
Product and design-operations teams should escalate governance into roadmap planning when customers begin asking where their credentials are stored, who can access them, how long they last, and how to revoke them. Enterprise buyers may require audit trails, regional processing, role-based administration, and contractual breach notification, but exact requirements vary by contract, industry, and jurisdiction. Rather than promising zero risk, state which controls are automated, which are customer-configurable, and which require support. Review at least quarterly during 2026 and after every major architecture change, with a full access review at least annually for ordinary accounts and more often for privileged ones. The decisive test is not whether the organization has an NHI policy; it is whether an unauthorized machine can obtain a new permission, move a secret, or retain access after revocation. If the answer is unknown, the program remains incomplete.
How to Measure a Credible Governance Outcome
Measure the control system by outcomes that can be tested. Track the percentage of known machine identities assigned to an accountable owner, the percentage of production secrets stored outside source control, and the median time to revoke or rotate an exposed credential. Add the percentage of service roles with documented permissions, the number of privileged identities older than the required review date, and the share of customer integrations that support independent disablement. For automated agents, measure tool permissions, approval requirements, action logging, spending limits, and successful emergency shutdown. Set service-level objectives only after collecting a baseline; for example, teams might target revocation within four hours for internet-exposed production secrets and within one business day for standard customer integrations. Those intervals are organizational commitments, not universal security rules, and incident severity may require faster action.
Governance should also be evaluated from the user’s perspective. In usability studies, ask administrators whether they can distinguish production from test identities, understand the consequence of revocation, and recover a failed integration without engineering intervention. Record task success, completion time, support contacts, and incorrect permission changes across at least 5 representative participants before redesigning a complex administration flow. Include security engineers, product operators, customer administrators, and people with motor or cognitive accessibility needs because a technically secure flow can still be unusable. Report both control strength and operational burden; a process that adds 6 hours of review work for every minor rotation may be avoided by teams under delivery pressure. The strongest 2026 program combines machine-enforced policy, short-lived credentials, product-level ownership, usable administration, and evidence that revocation actually works.