Yes. Automation without discovery usually scales blind spots, because teams cannot protect what they have not found. Start by inventorying service accounts, tokens, certificates, and agent identities, then assign owners and classify privileges. Once visibility exists, automation can support rotation, revocation, and alerting instead of amplifying unknown access.
Why This Matters for Security Teams
Prioritising discovery before automation is the difference between controlling risk and accelerating it. If teams automate rotation, revocation, or alerting before they know where service accounts, API keys, certificates, and agent identities live, they usually automate incomplete data, stale ownership, and false confidence. That is especially dangerous because NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
Discovery first also supports broader governance goals in NIST Cybersecurity Framework 2.0, because organisations cannot protect, detect, or respond to identities they have not enumerated. The practical issue is not whether automation has value. It does. The issue is whether automation is acting on verified identity inventory, ownership, and privilege classification rather than inherited assumptions. In practice, many security teams encounter token sprawl, overprivileged access, and offboarding gaps only after an incident has already exposed the weakness, rather than through intentional control design.
How It Works in Practice
A useful sequence is discover, classify, assign, then automate. Start by finding all NHIs across code repositories, CI/CD pipelines, secret stores, cloud accounts, containers, and agent runtimes. Then classify each identity by owner, system purpose, privilege level, secret type, and business criticality. Once that baseline exists, automation can safely handle recurring tasks such as credential rotation, certificate renewal, revocation, and anomaly alerting. That workflow is consistent with NHIMG guidance in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Key Challenges and Risks.
Discovery also makes it possible to measure what matters. If 97% of NHIs carry excessive privileges, as reported in the Ultimate Guide to NHIs, then automation should be aimed at shrinking privilege, not just speeding up approvals. Mature teams often pair this with policy-as-code and evidence collection so that changes can be validated against expected ownership and access patterns before they are enforced.
- Use discovery to build an authoritative inventory before enabling broad automation.
- Assign each NHI to a human owner and a system owner, not a generic queue.
- Flag long-lived secrets, unused identities, and overprivileged access for review first.
- Automate rotation and revocation only after inventory quality is strong enough to trust the outcome.
These controls tend to break down in heavily decentralised cloud environments where secrets are embedded in pipelines and shadow tooling because inventory coverage becomes too incomplete to automate safely.
Common Variations and Edge Cases
Tighter discovery controls often increase operational overhead, so organisations must balance visibility against the speed of delivery. That tradeoff is real in fast-moving engineering teams, especially where ephemeral workloads, multi-cloud estates, or third-party integrations create constant identity churn. Current guidance suggests that automation should still follow discovery, but the order can be staged by domain: high-risk production systems first, then lower-risk environments, then less critical inventories.
There is no universal standard for this yet, but the practical rule is simple: do not let automation outrun confidence in the inventory. For AI agents and other autonomous workloads, discovery becomes even more important because behaviour is dynamic, tool use is variable, and static RBAC alone often fails to reflect intent. That is where stronger identity primitives and runtime governance come in, especially when evaluating whether an action should be allowed at the moment it is requested rather than based only on a pre-set role. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same operational lesson: unmanaged identities compound quickly, and automation makes the blast radius larger when the foundation is weak.
In practice, discovery-first programs do not slow security maturity. They make automation trustworthy, which is the only way automation can safely scale across NHIs, secrets, and autonomous systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Discovery is the prerequisite for controlling unknown and unowned non-human identities. |
| NIST CSF 2.0 | ID.AM | Asset management requires knowing what identities exist before protecting them. |
| NIST AI RMF | GOVERN | Autonomous agents need accountable governance before runtime automation expands access. |
Establish ownership, policies, and oversight for agent identities before enabling automated actions.
