Free Resource

NHI Security Audit Checklist

8 questions to map your credential exposure, attribution gaps, and lateral movement surface. Run this against your own environment. Takes about 15 minutes.

8 questions · ~15 minutes · No install required

Most security teams have strong controls for human identities. The gap is below the human layer: every service, pipeline, agent, and workload that authenticates with a credential your team manages.

This checklist covers the eight areas where non-human identity (NHI) risk is highest. For each item, assess your current posture as green, yellow, or red using the criteria below. Your results will tell you where to focus first.

1

Identity Inventory

Can you enumerate every non-human identity in your environment?

List every service account, API key, machine token, and agent credential across all environments, production, staging, CI/CD, cloud. Include credentials stored in env vars, config files, secret stores, and pipeline variables.

Green Full inventory exists, is current, and has an owner
Yellow Partial, some teams track credentials, others don't
Red No inventory, or it is months out of date

Why it matters: You cannot secure what you have not counted. Most organizations discover credentials they did not know existed during an incident, not before one.

2

Credential Scope

Are your machine credentials scoped to the minimum permissions they actually need?

Pick 5 service accounts at random. Check what they are authorized to do versus what they actually call. Flag any with wildcard permissions, admin access, or access to resources outside their function.

Green All sampled credentials are least-privilege and regularly reviewed
Yellow Some are over-scoped but documented with a remediation plan
Red Over-scoping is common and undocumented

Why it matters: Over-privileged machine credentials are the primary lever for lateral movement after initial access. One compromised credential should not reach your entire infrastructure.

3

Rotation Posture

What percentage of your machine credentials rotate automatically, without human intervention?

Separate credentials into three groups: auto-rotated, manually rotated on a schedule, and never rotated. For manually rotated credentials, track how often rotations actually happen versus the stated policy.

Green 80%+ rotate automatically; remaining are low-risk and documented
Yellow Mixed, some auto-rotate, most rely on manual process
Red Mostly manual or no rotation policy; credentials are long-lived by default

Why it matters: Rotation reduces exposure window but does not eliminate risk. A credential that exists can be stolen. The goal is eliminating credentials from process memory entirely, not just rotating them faster.

4

Attribution Gap

If a machine credential triggered an alert right now, how quickly could you identify which specific workload used it?

Simulate this: pick a shared service account that multiple workloads use. If it made an unauthorized call at 2am, which workload would you attribute it to? How long would that investigation take? How many teams would need to be involved?

Green Every credential maps to exactly one workload; attribution is immediate
Yellow Most credentials are per-workload; some shared credentials create blind spots
Red Shared credentials are common; an alert tells you something happened, not what

Why it matters: Credential breaches take an average of 292 days to identify and contain, longer than any other attack vector (IBM Cost of a Data Breach, 2024). Attribution gaps are a primary reason incident response takes as long as it does.

5

Lateral Movement Surface

If one workload is compromised today, what is the maximum number of other services it could reach?

Map the network reachability of your most connected service. Check whether workload-to-workload connections are governed by identity-based policy or only by network ACLs. Count how many services share the same credentials.

Green Workload connections are identity-verified and policy-governed; blast radius is bounded
Yellow Network segmentation exists but no workload identity layer, bypassable by a compromised workload
Red Flat trust between services; one compromise can reach most of your infrastructure

Why it matters: Flat trust is why breaches spread. Network segmentation alone does not stop an attacker who compromises a workload already inside the perimeter.

6

AI Agent Exposure

Do any AI agents in your environment call external APIs or access sensitive data using credentials you manage?

Identify every AI agent or LLM-powered workflow that makes outbound calls. For each: what credentials does it use, where are those stored, what can the agent reach, and who controls what it is allowed to do next?

Green No agents in production yet, or agents have per-agent identity with scoped, short-lived credentials
Yellow Agents exist with rotated credentials, but egress is not governed per-agent
Red Agents use shared or long-lived credentials; they make autonomous calls with credentials they hold in memory

Why it matters: AI agents make non-deterministic execution decisions, they decide what to call at runtime. Traditional IAM assumes predictable workload behavior. Agents break that assumption, and the credentials they hold are exposed for the full duration of the agent's session.

7

mTLS Coverage

What percentage of service-to-service connections in your environment are mutually authenticated and encrypted?

Survey your internal service calls. Separate connections into: mTLS enforced, TLS server-only, and unencrypted. Flag connections that carry sensitive data or access privileged resources but are not mutually authenticated.

Green mTLS enforced on all internal service connections
Yellow Partial coverage; high-risk connections are protected but gaps remain
Red Minimal or no mTLS coverage on internal connections

Why it matters: mTLS without workload identity is incomplete. Certificates prove a server exists, workload identity proves which specific process is connecting. Server-only TLS allows service impersonation from any process that can reach the network.

8

Revocation Readiness

If a machine credential were confirmed stolen today, how long would it take to revoke it everywhere it is used?

Trace a single credential through its full lifecycle: where it is stored, which systems consume it, how long rotation takes end-to-end, whether consumers handle rotation without downtime, and whether downstream systems may have cached it.

Green Under 1 hour, automated, zero downtime for consuming services
Yellow Hours to a day; partially manual with some coordination required
Red Days or unknown; requires coordination across teams before revocation is complete

Why it matters: A 4-day revocation window on a confirmed breach is 96 hours of live exposure after you know you have a problem. Revocation speed is directly tied to how credentials are managed, static credentials are inherently slow to revoke because they exist in too many places.

How to read your results

7-8 green

Strong NHI posture. Your exposure surface is mapped, attribution is clear, and blast radius is contained. Focus on the remaining gaps and plan for AI agent credential management before you deploy at scale.

4-6 green

Significant gaps in at least one critical area. Prioritize in this order: attribution (item 4), rotation posture (item 3), lateral movement surface (item 5). These three have the highest incident impact.

0-3 green

Foundational NHI work is needed. Static, shared credentials are the norm. Start with an identity inventory and work toward per-workload attribution before addressing encryption or AI agent exposure.

This checklist surfaces gaps. Riptides closes them.

Kernel-enforced identity for every workload and AI agent. Secretless credentials, automatic mTLS, per-agent egress control. No code changes required.