Last updated on September 21st, 2026 at 08:12 am
Most enterprise security programs are running a silent crisis under the radar. This isn’t about firewalls and phishing. It is about identity, that is, thousands of non-human identities (NHIs) that are running silently in cloud environments, SaaS architectures, CI/CD pipelines, and production workloads without much or any central control.
Combine that with cryptographic properties – certificates, keys, and tokens that are distributed across hybrid infrastructure, and you have an attack surface that is scarcely visible to most organizations, much less under the control of management.
Discovery and Inventory: This has become a security best practice to gain visibility into AI Agents and Cryptographic Assets. New national policy instructions have clarified this: you cannot protect what you have not mapped.
This article breaks down why visibility is so challenging, what discovery targets actually look like, how modern tooling handles the issue, and why the migration to post-quantum cryptography (PQC) makes it even harder.
Table of Contents
Why Visibility Is So Hard Right Now – And It’s Getting Harder
Multi-Cloud and Hybrid Environments Break Traditional Inventory Models
Most organizations didn’t build their environments with the NHI in mind. They grew. One crew deployed an AWS infrastructure. Another team moved to Azure. One began running workloads on-prem and integrating three SaaS platforms. For years, you have service accounts communicating with APIs across five clouds, and nobody has a clean list of what relates to what.
I have audited settings where the permissions of the same service account were spread across three cloud providers- and no one in the security team was aware of its existence until a scheduled audit was able to raise it. That’s not unusual. It’s almost the norm.
The problem is structural. NHI API keys, OAuth tokens, service accounts, machine certificates, workload identities, etc., don’t exist in a single place. They are hard-coded in commits, stored in CI/CD pipeline variables, hard-coded into containerized microservices, and have permissions that aren’t assigned by IAM but increase gradually over several months.
An AI agent introduced into a ‘workflow’s physical presence adds an identity layer: access credentials to authorized data sources, access keys for external API calls, and secrets to authenticate to downstream systems. These are machine-fast; they run 24/7, and most seldom pass through the same review gates as human user accounts typically do.
Secrets Are Hiding in Plain Sight
What complicates the inventory problem is that a large fraction of active secrets aren’t in a secrets manager. My experience assessing security posture across organizations of varying sizes showed a general trend: hardcoded credentials embedded in application source code, API keys stored in environment variable files committed to internal repositories, and tokens in CI/CD pipeline configurations dating back years.
Security teams often miss these until a breach occurs, an unwary developer commits to a public repository, or a code scanner is first run. At that point, finding a single exposed key isn’t the whole task; it is building a constantly updated map of credentials across all environments.
What You’re Actually Trying to Discover: NHIs and Cryptographic Assets
Non-Human Identities Across Every Layer
The discovery scope is broad. NHIs exist across:
- Cloud IAM – service names, workload names, instance names, managed names (Azure, GCP, AWS)
- SaaS application authentication – OAuth, API, Third-party linked applications.
- CI/CD pipelines: CI/CD pipeline tokens– deployment tokens in tools such as GitHub Actions, GitLab, Jenkins, and CircleCI; environment secrets in tools such as GitHub Actions, GitLab, Jenkins, and CircleCI
- On-premises systems- on-premises service accounts such as Active Directory, timed task accounts, LDAP bind accounts.
- IoT and OT space – device certificates, signing keys of firms such as firmware signatures, and industrial system authentication keys.
- SSOs and automation processes, AI agents– identities (LLM-related), tool-use Credentials, RPA bot identities.
All of these have an access scope, an owner (often unknown), a purpose (often undocumented), and a risk profile that evolves. Finding them is a challenge in itself, but mapping each NHI to context is a challenge. Who owns it? What can it access? When was it last rotated? Is it currently in use, or an orphan of its time with the live permissions?
The underlying aspect of this issue – especially with the introduction of AI agents into enterprise processes – is exploited to an extent in the contextualization of Identity Crisis – Securing Non-Human Identities to AI Agents, which takes a closer look at how agent-based architectures introduce new breeds of NHI risk that conventional IAM was not designed to accommodate.
Cryptographic Assets: The Algorithm Layer
Crypto asset discovery runs in parallel. Where NHI inventory would be interested in who is authenticating, cryptographic discovery is concerned with how – the nominated algorithms, certificates, keys, and protocols that establish data-in-transit and at-rest security.
The cryptographic inventory must provide an answer to:
- Where are all certificates, including TLS/SSL certificates? i.e., when do they expire?
- What encryption algorithms are being used in applications, databases, and APIs?
- Do you still use deprecated or weak ciphers in your production systems?
- Which keys are there, who owns them, and what is the rotation policy?
- Which cryptography definitions are vulnerable to quantum?
I observed that in the vast majority of organizations, partial answers to some of these are available, typically the certs that are run by a recognized CA or a commercial PKI product, but very few have a wholesome picture.
Shadow certs, test certificates created by code developers and deployed, test certificates created by tools, and the alphabet diversity of algorithms in third-party libraries all leave gaps that tooling-level certificate monitoring doesn’t catch.
Discovery and Inventory: Gaining Visibility into AI Agents and Cryptographic Assets
Automated Discovery: The Tool Stack
Inventory scaling does not work with manual inventory. Layered automated discovery is used as the methodology towards which organizations are converging:
IAM tools and CIEM tools– Cloud Infrastructure Entitlement Management (such as Wiz, Ermetric, or Sonrai) tools scan IAM settings to reveal all identities, including human and non-human, and permissions as well as patterns of usage. These tools can identify over-privileged service accounts, unused credentials, and unintended cross-account access.
Secrets scanners – These scan source code for secrets, along with CI/CD settings and histories of secret discoveries. Applications such as Trufflehog, GitLeaks, and Semgrep can scan this code. Commercial versions integrate into developer workflows and intercept exposures before they reach production.
CSPM (Cloud Security Posture Management) — CSPM solutions maintain visibility into cloud resource settings and identify undesirable settings that expose credentials or allow unauthorized access to service identities.
Network and passive monitoring– Network-level discovery: Network traffic can reveal undocumented API usage, find services speaking on unusual ports, and reveal problems in cryptography protocols (e.g., insecure TLS versions, use of weak cipher suites) with the aid of traffic analysis.
Code and SBOM scanning: Software Bill of Materials (SBOM) tools and static analysis can identify cryptographic libraries in use, flag vulnerable algorithm implementations, and provide a software-level representation of cryptography usage.
New NHI-specific applications– such as Astrix, Entro, and Oasis Security- take it one step further by establishing identity graphs that identify each NHI with its access paths, owners, the context in which it was created, and the systems it serves.
Such tooling has been useful in the Proof-of-concept world, including in environments where an identity graph view is especially helpful. Instead of a flat list of credentials, it creates a map of relationships and risk to explore.
Mapping NHIs to Context: The Four-Field Framework
Discovery without context is just a list. The operational aim is to identify the location of participating NHIs in four fields:
- Owners— Who is in charge of this identity? What team, system, and/or person?
- Purpose — What is it used for? What workflow does it enable?
- Environment — In what environment does it work? On-prem, prod, dev, staging, cloud?
- Access scope What are its permissions? What data or systems can it access, and is it allowed to?
A security team cannot make risk decisions without these four fields. Broad S3 read permissions on a service account could fit a data pipeline, but they could also be a misplaced credential from a retired tool. Context differentiates the two.
Cryptographic Discovery Platforms
Specialized cryptographic asset discovery and inventory (CADI) systems, such as those provided by Keyfactor, AQtive Guard by SandboxAQ, or research initiatives such as TNO’s CADI work, go as deep as software algorithms.
These systems combine network scanning, API connectivity, and passive monitoring to construct a Cryptographic Bill of Materials (CBOM) – a formal catalog of all the active cryptographic assets, where it is located, which algorithm it is performing, key length, validity duration, and compliance level.
CBOM is increasingly being discussed similarly to SBOM as a structured artifact that companies should maintain continuously, and not just create during audits.
Policy Is Catching Up – And It’s Moving Fast
Executive Orders and the NHI Requirement
The policy environment has changed significantly in recent years. Executive-level cybersecurity direction in the United States has driven federal agencies (and, by implication, their contractors and supply chain partners) to treat ongoing asset visibility as a minimum standard.
Inventory is a governance service covered by the NIST AI Risk Management Framework (AI RMF), which requires organizations using AI systems to maintain records of AI elements, such as identities used and integrations made by those technologies.
For cryptographic resources in particular, NIST’s continued cryptographic migration guidance treats cryptographic inventory as a requirement, not an option, and a mandatory activity before any PQC transition can be implemented. You cannot even migrate cataloged algorithms.
PQC Migration: Why Inventory Is Step Zero
The nearest future trend that favors cryptographic discovery is post-quantum migration. Most of the cryptographic algorithms that form the basis of the modern internet- RSA, ECC, and Diffie-Hellman- are vulnerable in theory to sufficiently powerful quantum computers. In 2024, NIST completed the first round of post-quantum cryptographic standards, and federal agencies were ordered to begin migration planning.
Migration cannot happen without visibility. Companies must understand exactly which systems run which algorithms, which certificates rely on quantum-vulnerable key exchange, and where cryptographic logic is coded. It is also a CBOM issue and must be discovered with the methodology mentioned above.
My early organizational experience during PQC planning shows a constant bottleneck: teams understand the urgency but can’t prioritize it because they lack a complete cryptographic inventory. Preparation isn’t part of the discovery phase; it’s the rate-limiting one.
What’s Just Beginning: The Emerging Capability Layer
AI Agent Identity Graphs
AI agent NHI management is the least developed area right now. With each new agent launched (whether a customer support agent, code generator, data analyzer, workflow automator, etc.), you add a new identity layer.
Agents call APIs, read and write to databases and files, and gain entry through downstream service authentication. They often receive credentials provisioned in haste, and they don’t get the lifecycle management afforded to human user accounts.
And where to find them can be tooling specifically dedicated to this space, such as the AI Agent Discovery module of Astrix, and the NHI management tooling of Oasis Security, which are contributing to real-time inventories that cover agent identities themselves: what part of the infrastructure the agent can identify, what credentials it possesses, how it was provisioned, and whether its credentials have been rolled or scoped accordingly.
This is one area to monitor. Implementing AI agents with machine-speed, widely scoped NHI credentials creates a risk surface that most existing security programs are not adequately prepared to monitor.
CAASM + NHI Convergence
Cyber Asset Attack Surface Management (CAASM) reasons are starting to combine with NHI-specific software. The rational final state will be a single asset database comprising human identities, non-human identities, cryptographic assets, software components (SBOM), and AI systems – all in a single continuously updating graph.
That convergence is not quite here yet. Most organizations still use different tools for IAM, CSPM, secrets management, certificate management, and NHI visibility. The trend is obvious, however: a unified, persistent, context-sensitive asset inventory of all identity types.
Trust Booster: Two External Resources Worth Bookmarking
Two outside sources are particularly useful to the reader who develops practical programs or expands on their knowledge:
- NIST SP 800-57 (Key Management Guidelines): 800-57 is the underlying document of the policy and practice of cryptographic key management. It is immediately pertinent to developing a cryptographic inventory program.
- Anchor text consideration: NIST Key Management Guidelines.
Link: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final - TNO CADI Report (Cryptographic Asset Discovery and Inventory) – A comprehensive technical report about the current circumstances regarding cryptographic discovery tooling and methodology consisting of CBOM frameworks.
- Anchor text: TNO Cryptographic Asset Discovery and Inventory Report.
Link: https://publications.tno.nl/publication/34645425/j6EewK7a/TNO-2025-P11921-GB.pdf
Where Things Stand and What Comes Next
Discovery and Inventory: Becoming Visible to AI Agents and Cryptographic Assets remains more aspiration than reality for most organizations. The tools are maturing. The policy pressure is real. The PQC timeline is approaching.
Nevertheless, the gap between what organizations are supposed to see and what they can actually see is large.
Practically, the starting point is always to prepare the store before you need it. Map NHIs to controllers and access scopes. A CBOM is a good thing to build before your PQC planning stage, since you have no idea what algorithms you’ll be executing.
Discovery should be part of CI/CD because you need to ensure new credentials don’t pass without evidence.
The identity aspect of this issue will increase exclusively for anyone tasked with handling AI-integrated settings. Agents will multiply. Their credential footprint will increase. And organizations that have already achieved continuous NHI and cryptographic visibility will be in a fundamentally different risk position than those that have not.
The visibility gap can be bridged.
However, to close it, organizations must elevate discovery and inventory to an ongoing operational practice, not a project.
I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
