Blowing Up the Theme Park
Why GenAI protocols like MCP and A2A threaten modern PKI
The rise of Generative AI as a foundational form of computing has updended modern enterprise infrastructure.
From kicking off an arms race in GPUs that has created a whole new generation of cloud platforms, to creating new disciplines of engineering such as MLOps and LLMOps to manage new stacks of inference and model training infrastructure respectively, supplying genAI with the capabilities it needs to power the next phase of human-computer interaction has fundamentally changed how organizations invest and operate their computing platforms.
The sea change is especially true in cybersecurity. GenAI agents have both become new principals for protection and new potential threat vectors, being vital mechanisms for automating how future DevOps and SecOps teams manage/defend infrastructure while simultaneously throwing gasoline on previously-lit fires around managing how automation securely interacts with sensitive systems.
Vibe Infrastructure Engineering
It’s likely that infrastructure engineering professionals like SecOps and DevOps in the late ‘20’s/early ‘30’s won’t directly be managing or defending infrastructure as code.
Just as Cursor and “vibe hacking” have changed how software engineers architect and write code starring with natural language, SecOps and DevOps professionals to manage and secure infrastructure will likely dictate natural language instructions to intelligent genAI agents.
In turn, those agents will use purpose-built models and mechanisms like Retrieval Augmented Generation (RAG) to reason an optimal solution from the state of that infrastructure and execute those instructions on behalf of those infrastructure engineers.
This pattern of using natural language rather than requiring expertise in reading/writing production-level code has significant benefits for infrastructure engineering.
Removing the requirement of being a stellar programmer removes a major barrier of gatekeeping for SecOps and DevOps professionals. And for those who are skilled programmers, being able to “think first” in a comfortable natural language before dealing with the nuances/complexities of applying their strategies in their chosen programming or scripting language means they can be much faster and much more effective.
The problem changes from battling and debugging with the complexities of frameworks and libraries to reviewing code changes — an often faster and frequently simpler task for a skilled programmer.
But these benefits come at a cost.
Just as software engineers using Cursor or Windsurf need to authenticate into their repositories using GitHub or Gitlab credentials tied to their personal accounts, infrastructure engineers utilizing similar tools need to supply their privileged (often superuser-level) credentials to log into systems they need to administer or protect: endpoint systems, scheduling systems such as Kubernetes, even cloud infrastructure administering an entire company’s compute infrastructure such as AWS’ management console.
Therein lies a huge problem: the protocols genAI agents use for authentication and authorization are not built to securely and performantly manage the deluge of requests that genAI will yield over the next few years.
The Devil in the Details
GenAI Agents rely on open protocols such as Anthropic’s MCP and Google’s A2A to enable activities like vibe infrastructure engineering. While they vary in implementation and intended use, these protocols frequently do the same thing: they allow genAI agents to query data from systems and potentially take action via interaction such as REST API calls.
Agentic protocols like these typically enable two key benefits:
- Improving Model Accuracy: Even if a LLM is perfectly accurate, it’s only accurate up to the date that it was trained. Agentic protocols — when paired with good RAG infrastructure — help keep the basis of knowledge for models up to date by enabling tool calling from relevant data sources. This improves accuracy for inference requests and helps minimize hallucination.
- Taking Action Across Lots of Tools: LLMs are glorified autocorrect text engines. On their own they can’t “do” anything, and require some mechanism to convert strategy to action and execution. Protocols like MCP enable consistent tool calling across a variety of different systems and services, serving as effectively a genAI-friendly version of the OpenAPI standard.
To enable these benefits, these protocols typically rely on authentication built for the Web 2.0 era of computing. Chief among these is the OAuth standard, a family of protocols originally designed to enable applications to authenticate with web-based services.
OAuth has been critical in enabling the last decade of computer innovation. It’s because of OAuth that OIDC exists, and it’s because of OIDC that you can log into your LinkedIn account with your Google e-mail.
But securing how billions of humans beings authenticate into Instagram every month is very a different challenge from securing how each of those billions of human beings potentially authenticate dozens of times a day through agents powered by Anthropic Claude or ChatGPT.
At the core of this massive increase in volume is a key oversight in OAuth and constituent protocols OIDC: how underlying Public Key Infrastructure (PKI) powering their identification and verification mechanisms handle key exchanges.
A Crash Course in OAuth
Whether it’s an agent or a human user, OAuth works the same: it verifies the identity of the client communicating through an application with an Identity Provider (or IdP). These may be dedicated IdPs such as Okta or Microsoft Entra. Or they may be systems of record that have a strong binding to the user’s activity and serve as an effective form of their identity, such as one’s Google or Facebook Accout.
What actually happens during this authentication is up to the provider itself. Multi-Factor Authentication (MFA) may be employed, such that if the user is trying to authenticate an agent using their GitHub Account they may have to give an additional One-Time Password (OTP) sent to a previously logged-in mobile app. OAuth doesn’t dictate how authentication happens; it leaves that to the IdP that serves as the Authentication Service in its exchange.
Once a client has been authenticated, the Authentication Service verifies that client is who they say they are with a JSON Web Token (or JWT). A JWT is an XML-formatted document containing claims about the client that the Authentication Service attests are true.
For example, a series of public claims (i.e.: claims about a client that are visible without decryption when the JWT is reviewed in plaintext) may look something like this:
{
"name": "Andy Manoske",
"id": 1337h4x0r420b1473i7,
"admin": true
}Claims like these are often used to assign entitlement within the Authorization Service after the claim has been read and verified to be true.
For example, if my JWT here was reflecting my authentication via OAuth into Microsoft Azure, my admin claim being true may entitle me to administration rights in my organization’s Azure infrastructure. After logging in I could use that entitlement to take superuser actions such as creating new Azure machines. Or even deleting my company’s entire infrastructure.
Making sure claims are accurate is thus extremely important. To do this, JWTs also contain a cryptographically protected secret from the Authentication Service verifying the token is authentic. These secrets take one of two forms: a HMAC signature and/or a X.509 certificate.
“Crawling in my [CRLs]”
HMAC signatures are the simplest form of authenticity verification. They’re the cryptographic equivalent of a secret handshake, showing that in this case the Client and the Authentication Service at some point know some kind of secret handshake and have verified the contents of the communication.
Secret handshakes are neat, but they are far from secure. An adversary could have been eavesdropping on the Client and the Authentication Service for some time and used knowledge of how they operate to learn that secret handshake.
Or they could have actually put on a wig and Scooby Doo costume and asked the Client to teach them the handshake all over again. And if that client was fooled by their costume, they might think they were talking to Okta instead of Old Man McGee and show them sensitive details.
As such, most JWTs used in situations where Scooby Doo villains shouldn’t immediately be able to shut down the Theme Park by fooling a van full of teenagers (i.e.: secure JWTS) utilize X.509 Certificates.
X.509 Certificates are cryptographic artifacts based on the X.509 standard. Much older than OAuth, this standard was originally created in the late ‘80’s to handle web of trust issues and minimize Man in the Middle attacks for increasingly digital forms of encryption.
X.509 Certificates go beyond the “secret handshake” and give the Authorization Server reading the client’s JWT a mechanism to call the Authentication Service to doubly verifying the client’s claims. Within that mechanism is something called a Certificate Revocation List or CRL, a tool that enables the Authorization Service to verify how long the Authentication Server has verified the integrity of its claims and whether the certificate itself is still valid.
Instead of talking about the math behind asymmetric crypto, let’s revisit Scooby Doo. Imagine the Scooby Gang wants to verify that the thing in front of them at the old theme park really is the Ghost of Zebbediah Kane, an 18th century necromancer that haunts Six Flags: Cartoon America.
With HMAC, the Scooby Gang can only verify that the “ghost” seems to know a lot about how Zebbediah Kane operated and that he convincingly seems to communicating with them in period-appropriate language.
But with X.509, the Scooby Gang can literally call hell itself and ask if this is really Zebbediah Kane.
They can scrutinize details of the ghost’s interaction and verify whether hell sent him back to the park to stop the construction of the new data center there.
Even more importantly, they can actually verify how long he was supposed to be haunting the theme park and if he was ever recalled at some point. If the ghost is there past his expiry date or he’s on the CRL, he shouldn’t be there and something was off.
This combination of the CRL and a short-lived expiry — thereby necessitating frequent reauthentication of a client’s identity and making a certificate much harder to steal — helps solidfiy its validity.
Unfortunately, the X.509 standard was not built for modern Web 2.0 workloads. CRLs get to be massively long and are not formatted well to enable certificates to be short lived.
Unless the cryptosystem backing your PKI infrastructure — either a Hardware Security Module (HSM) or a “software” security module such as a secrets manager — is specifically built for it, the process to verify a certificate is still valid becomes herculean as that list grows.
This is because checking whether a certificate is revoked is a Linear Search Problem, a O(n) algorithm that by algorithmic standards is slow and grows linearly with the size of the list.
You worst case have to go through the entire list every single time you want to see if a certificate is still valid. This list over time can become too long for a cryptosystem to quickly process and respond, ensuring that performance for a system authenticating through it massively degrades.
Defenders frequently rely only on expiry dates for quasi-security, yielding an advantage to adversaries that can use this knowledge to prepare targeted attacks to steal and use valid creds.
TL;DR
CRL performance issues are solvable. But they’re not easy.
One of the reasons why HashiCorp Vault Enterprise is the de facto standard today for enterprise PKI (and really why Secrets Management became a thing) was because of the massive amount of work invested in the PKI Secrets Engine to enable the creation of short lived, dynamic X509 credentials.
Still, even Vault is likely not prepared for the combinatorial explosion of short lived credentials coming with MCP and A2A. Nor are replacement protocols attempting to improve the performance of CRLs like OCSP.
If a majority of human beings are enabling agents to authenticate with their entitlements dozens or hundreds of times a day, ensuring these credentials are all ephemeral is likely a multi-billion dollar technical challenge that necessitates a new generational advancement in Secrets Management technology.
Failure to make these credentials properly ephemeral means that adversaries don’t have to hack Certificate Authorities protecting secrets like long-lived, non-revoked certificates.
The sheer volume of MCP and A2A transactions will statistically yield some mismanaged certificates, ensuring an adversary can exploit what remains the most common mechanism for data breaches and cyberattacks: a stolen credential.
