How AppViewX addresses agent sprawl and quantum threat

An AI register tells you an agent exists. It rarely tells you the cryptography that agent depends on, and that gap is where post-quantum risk hides.

Key takeaways

• Building a crypto-agile identity strategy requires a record of every AI agent and its owner, a record of the cryptography each agent depends on, and the ability to change that cryptography without breaking the workflow.
• An AI register and a cryptographic inventory each describe part of the same system, and neither one points back to the other.
• Agents inherit cryptography they never chose, through the protocols, credentials, and services their workflows run on.
• Replacing one quantum-vulnerable certificate can require every party in the trust path to move with it.
• Executive Order 14412 puts federal deadlines behind the post-quantum transition, which gives enterprises a fixed date to plan against.

Most enterprises can now stand up an AI agent faster than their inventory can record it. A team connects a model to internal data and a few tools, and the result may show up as one application or one line in an AI register. That entry says little about the identities, credentials, and services the agent relies on to do its job.

What the agent relies on does not stay fixed. AI systems can invoke or spin up subagents. A coding agent might hand off review, testing, or deployment to other agents, each of which can call external services or internal systems.

As agents delegate work, the number of identities, credentials, and trust relationships involved in a single workflow can grow quickly.

In July 2026, OpenAI disclosed that a set of its frontier models escaped an isolated testing sandbox, chained together a zero-day in a third-party package registry proxy, escalated privileges, and reached a live Hugging Face production database.

That incident shows how far an agent’s reach extends once it can delegate and act.

Every agent is a network of cryptographic trust

An agent receives authority from a human identity, authenticates through an identity provider, calls a model through a gateway, and reaches tools, databases, and other agents.

Each connection depends on a mechanism to establish identity, protect the exchange, or verify authority. Certificates, signing keys, tokens, trust stores, and cryptographic libraries sit underneath those controls.

The protocols agents are beginning to use make those dependencies visible. The Model Context Protocol (MCP) bases its HTTP authorization model on OAuth 2.1. Agent2Agent (A2A) uses HTTPS/TLS and supports authentication through mechanisms such as OAuth 2.0 and OpenID Connect. The Secure Production Identity Framework for Everyone (SPIFFE) can represent workload identity through X.509 certificates or JSON Web Tokens (JWTs).

An agent workflow can therefore rely on those mechanisms long before anyone labels them as part of the agent.

Two inventories that never meet

An AI register and a cryptographic inventory each hold half of what a migration decision requires.

An AI register is the list an organization keeps of the AI systems it operates, maintained for governance and compliance reporting. A cryptographic inventory, sometimes formalized as a cryptographic bill of materials, is the list of certificates, keys, and algorithms in use, maintained for certificate operations and now for post-quantum planning. The two are compiled at different times for different audiences, and neither was designed to reference the other.

Inventory	What It Records	What It Cannot Answer
AI register	Models, data, and purpose	Which cryptography the agent depends on
Cryptographic inventory	Certificates, keys, and algorithms	Which agent workflows depend on that cryptography

Post-quantum cryptography (PQC) migration turns a list of algorithms into a dependency problem. The public-key systems these connections lean on, RSA and elliptic-curve cryptography (ECC), are the ones a future quantum computer would break.

NIST finalized its first three PQC standards in 2024 and is now urging organizations to begin applying them and migrating systems to quantum-resistant cryptography. Symmetric encryption and hash functions have a different risk profile and need a separate assessment, so a blanket “quantum-vulnerable” label hides the decisions that have to be made.

The exposure takes two forms. An attacker can copy encrypted traffic now and decrypt it once the hardware exists, and a machine that breaks those systems can forge the signatures and certificates that establish identity.

Executive Order 14412, signed in June 2026, puts hard federal deadlines behind the transition: agencies must name a migration lead by July 2026, and all high-value federal systems must be running post-quantum digital signatures by the end of 2031, with contractor requirements expected to track the same timeline.

Migration depends on the whole trust path

A scanner can identify an RSA certificate on an AI gateway and correctly flag it as quantum-vulnerable. That still does not tell you what has to change before you can replace it safely.

The agent client, the service mesh, the cryptographic library, the issuing authority, the trust store, and any external partner may all have to change together, and the migration can fail at any verifier that cannot accept the new signature.

Build one operating picture

For each agent, you need to know who owns it, which identities and credentials it uses, which cryptography protects those connections, and which services will be affected when that cryptography changes.

One agent running across development, test, and production can use a different certificate, token, trust store, and owner in each environment, so counting agents does not measure the problem.

A migration-ready inventory links each agent and its owner to the identities, credentials, algorithms, libraries, and services its workflow depends on. It also shows which of those dependencies are ready to move to PQC and which are not.

The gap shows up the moment a vulnerable cryptographic dependency has to be replaced and no one can say which agent workflows will stop working.

You should be able to name every production agent and the person accountable for it, trace each agent through its identities, cryptographic controls, tools, and data, and predict which workflows will fail when one vulnerable dependency changes.

If you can answer the first two but not the third, you do not yet have a migration plan.

What CISOs should be able to answer

For each production agent, security leaders need answers to five questions:

Question	What the Answer Covers
Which agents exist and who owns them?	Every production agent, plus the accountable person or team and the service account behind each one
What identities does it use?	Human, workload, service, and delegated identities
What cryptography does the workflow depend on?	Certificates, keys, signing algorithms, token validators, trust stores, and libraries
Which dependencies are quantum-vulnerable?	RSA and ECC dependencies, assessed apart from symmetric cryptography and hashes
Can the workflow migrate without breaking?	Whether every party in the trust path supports the change together

Developing your crypto-agility strategy

The first step is connecting each agent to the cryptography underneath it. Crypto-agility means being able to change those dependencies without breaking the workflow.

Keep an agent’s ownership, authority, identities, credentials, and cryptographic dependencies tied together from deployment through retirement. When a certificate, key, algorithm, or trust relationship changes, you should know which agent and workflow it affects.

Each agent should have a known owner and purpose, defined authority, traceable workload identities and credentials, and a clear view of the cryptographic dependencies that establish trust around it.

In practice, that requires four capabilities:

• Discover and correlate: Connect agents, owners, identities, credentials, algorithms, libraries, trust stores, tools, and data into one dependency graph.
• Prioritize: Identify quantum-vulnerable public-key cryptography and rank migrations by data lifetime, business criticality, exposure, and dependency complexity.
• Decouple: Avoid hard-wiring agents and applications to specific algorithms, issuers, certificates, or cryptographic implementations so trust mechanisms can change without redesigning the workflow.
• Test and Migrate: confirm that the full trust path accepts the new cryptography before it changes in production.

The objective is to know which agent workflows depend on the algorithms that have to change, and to migrate those workflows without losing identity, access, or availability.

How AppViewX addresses agent sprawl and quantum migration

AI agent sprawl, over-permissioning, and missing identity lineage are interconnected challenges that become more difficult to address as agent proliferation accelerates. That proliferation also expands the cryptographic dependency graph enterprises will eventually have to migrate.

Treating agent inventory and cryptographic inventory as separate exercises makes that migration harder with every new agent. AppViewX builds records on both sides:

• Agent discovery across the platforms where agents run, capturing each agent’s owner, models, MCP servers, and credentials
• Posture assessment against detectors for ownership, credential hygiene, MCP server sanction status, and model drift
• Certificate discovery and replacement across certificate authorities, cloud, and on-premise environments

Crypto-agility starts by connecting who owns the agent, what authority it has, how it establishes trust, what cryptography that trust depends on, and what else must change when the cryptography changes.

If security teams can see that graph and change its trust mechanisms without rebuilding the workflows around them, they have the beginnings of a crypto-agile identity strategy. Let’s discuss yours.