The Sentinel Ridge Files · Track 1: The Framework

The Town Clerk's Office: How Agent Identity Gets Made

Mar 30, 2026 15 min read

A Small Town

In a small town everybody knows everybody else. That’s just how it works. You start your life being identified as the son of your father or the grandson of your grandfather. Nobody calls you by your real name; they just know who you came from. People are also really good at identifying the folks who don’t belong there or at least the ones that they think don’t. It isn’t that looking different than everyone else is a bad thing. It’s just noticeable. It’s not that people think that those who act differently are wrong. That’s just not how things are done around here. People care about order because they believe it’s what’s best for their neighbors. I ought to know; I grew up in a place like that and even though I’ve been gone for over twenty-six years, it hasn’t changed much. Everyone’s looking out for everyone else.

The Clerk’s Office

In this small town there is one place that everyone goes to in order to get the documentation that they need. The town clerk serves as the central authority for every identity that matters in the town. Did you and your family just move into town? You go to the clerk’s office in order to get your personal IDs. Want to open up a business? Not a problem at all. Just go to the clerk’s office to get your business license. Want to become a contractor to build homes or offices for people? You need a contractor’s license. The clerk’s office issues licenses and identities which establish who is allowed to operate in any capacity within our city limits.

Now here’s what’s important to understand about the clerk’s office. It is critical for the smooth operation of our town’s various systems and processes. It establishes who everyone is and makes it clear who has official credentials to transact and do official business within the town before they conduct their transactions. They DO NOT know about or enforce standards for buildings and structures. That’s the town building permit office. They DO NOT conduct health inspections on the local restaurants. That’s the local town health department’s responsibility. The clerk’s office is highly specialized. It’s all about establishing an entity’s identity.

This is perhaps the most important function in our town’s government. It makes it so that all the other governing bodies can do their job properly. They must ensure that they aren’t using the same identities that they used back in 1778, the year our town was founded. That’s because while a paper card with a wax seal looked cool back then, it’s pretty simple for fraudsters to use a 3D printer to forge something “close enough” to fool the departments and local businesses that rely on the identities they establish. In fact they have to constantly evaluate what is happening and reissue new types of identities based on what is happening in other areas of the country and the world. It’s also important to understand that by default, our town clerk’s identities are not honored in any other jurisdiction. Not in the county, not in neighboring towns, not in other states. Our clerk is for our town, our citizens, our businesses.

From Town to Tech: The Certificate Authority

So now we begin to map functions to our “virtual town” of agents. The town clerk’s office is an illustration for the Certificate Authority, or CA. It is used to mint or publish certificate chains which allow our NHEs — Non-Human Entities — to be assigned identities that they need to prove that they are “our” entities and can be authorized by various systems to access or change various data.

A certificate “chain” is composed of a root certificate — the primary or first certificate in the chain — and then any number of intermediate certificates. Typically the root certificate is kept offline in order to prevent it from being stolen or compromised by attackers. The last one in the chain is the leaf certificate. This leaf certificate identifies who it belongs to — typically through a Subject Alternative Name, or SAN, which contains the hostname, IP address, or URI of the entity. Think of it as the equivalent of your “Name” on your driver’s license issued by the town clerk.

Any system which needs to utilize — that is, trust — the leaf certificate and treat it as valid must install and trust the root or preferably one of the intermediate certificates in the chain. This allows the client computer or any entity to “trust” any certificate that is issued from that intermediate certificate chain.

When the town clerk issues an official ID, whether it’s a driver’s license, a hunting license, or a contractor’s license, they have to put the official town seal on it. When a CA issues a certificate, it cryptographically signs it to “seal” it. This is the way that a certificate authority is able to issue identities that can be relied upon to be authentic. In fact, if a CA is truly to be relied upon, most use some form of HSM — a Hardware Security Module — in order to physically protect those private keys so that they cannot be stolen and copied. This prevents counterfeit certificates. Without the physical device, an attacker can compromise the server and still not be able to forge the clerk’s seal.

Every certificate that is generated by the CA has a corresponding private key that goes along with it. In our town example this would be equivalent to a photo of the face of whoever was issued a particular ID. So for example if someone comes to the town clerk’s office and requests a driver’s license, they would have their photo taken and the photo would be embedded within the license itself. But it’s not the photo that is equivalent to the private key. It’s the face that is represented by that photo that is the private key. You can copy the photo. You cannot copy the face. Now, every metaphor has its limits — unlike a face, which is visible to anyone who looks at you, a private key should never be visible to anyone or anything. It is a mathematical proof that you are who your certificate says you are, and it works without ever revealing itself. This private key must never be stored in plain text or retrievable by an attacker. It is never sent to the large language model. It must live in protected storage, not in context.

Short-Lived IDs and Why They Matter

In our town the clerk re-issues identification constantly. Because the town doesn’t have walls — anyone can walk in from the highway — it is essential that identities be difficult to forge. Different techniques can be used in order to make it more difficult to forge these identities. The reality is that attackers will always be able to figure out how to create false IDs if given enough time. Short-lived certificates are one layer of defense against this. If an attacker has sixty seconds in order to utilize a stolen credential, that doesn’t leave much time for them to make use of a cert that they stole. A certificate authority can be configured so that SSH certificates are issued and are only valid for between thirty and sixty seconds. This gives an attacker a very limited window in order to utilize the certificates that they were able to obtain fraudulently.

For instance in our town back in the 1700s, it would have been enough to have a seal made of wax and a hand-carved signet ring used to make an impression in the hot wax. In today’s world someone could use a 3D printer in order to copy the pattern on that signet ring and make an almost identical mark in their own hot wax. Short-lived certificates and rotating secrets help reduce the attack surface by limiting the amount of time in which these are considered valid.

When IDs Go Bad: Revocation

Even though we have very short-lived identities available, which help prevent abuse of our town clerk’s identities, this is not foolproof. Because of this our town clerk also has the ability to revoke identities that have been issued. Our town clerk maintains a public list of revoked IDs — in certificate terms, this is called a Certificate Revocation List, or CRL. There’s also a way for anyone to ask the clerk in real time, “Is this ID still good?” — that’s OCSP, the Online Certificate Status Protocol.

Let’s say that during a routine audit it is determined that a particular ID that has been issued by the town clerk’s office was done so under false pretenses. Perhaps an attacker was able to somehow infiltrate the town clerk’s office and blackmail one of the employees and get a certificate issued that should not have been. Perhaps they used forged information or lied on their application for a license. Perhaps they stole a certificate from another citizen of the town and the citizen comes and reports the theft of their identity. Even though we’re talking about a certificate that only exists for seconds, we live in a world where automation and now autonomy of systems carries with it a much larger blast radius for damage to occur even in very short time periods, such as our sixty-second certificate validity timeline. Because of this, Certificate Revocation Lists and OCSP can be used to declare identities null and void. This helps our town clerk — our CA — to remain a trusted source of identity for all who utilize their services, both those who receive identities and those who are able to check issued identities against those that have been presented to them.

Enter the Agents

You may have already known everything that we’ve talked about before this point. This isn’t really “groundbreaking” material. These components — CAs, certificates, HSMs, secrets — have been in use for years. But what IS new in our digital town are agents. Previously, we had different transit systems — information transport protocols like roads, rails, and air-traffic lanes — and we even had the vehicles to run through them like cars, buses, trains, and helicopters. But now we also have agents walking around and acting on our behalf in the township. These are similar to people — similar, but not the same, and as we discussed last time, that difference matters.

An agent is not a server. An agent is a series of API calls that carry context data to an LLM endpoint, retrieve a response, and then potentially perform some action based on the response received. In other words, the agent isn’t an LLM. The agent is the framework that sends data to and receives data from the LLM. The ID — the certificate, the API key, the password, the secret — is not, or at least should not be, sent to the LLM. The agent holds this locally, fetches it from the appropriate service or resource, and then uses it while it is valid.

When an ID expires in our town, the agent renews it by going to the CA and requesting a new cert. When certs expire, they go in the agent’s “trash” because they’re invalid. And it all is governed by our township’s laws and infrastructure, not based on the whims of the individual agent.

When the Clerk’s Office Falls

So what happens when the clerk’s office is compromised? What would be the end result if there was some type of substantial break-in and the clerk’s ability to sign certificates was stolen or replicated by some outside attacker? This has happened in the real world. In 2011, a Dutch certificate authority called DigiNotar was fully compromised. Attackers breached their systems and issued fraudulent certificates for major domains including google.com. The result? DigiNotar had to be completely decommissioned. Every browser in the world had to remove DigiNotar from its trusted root store. The entire organization ceased to exist. That’s what happens when the clerk’s office falls. I’m certain a slew of companies don’t even know that they’ve had compromises of this nature.

The secret keys must be protected but unfortunately they are not always. When this occurs an organization has but one option: rebuild the clerk’s office from the ground up. If good practices have been used and root certificates have been kept offline and are uncompromised, this doesn’t have to be a complete ground-up rebuild — but that’s basically what it amounts to. Every certificate that was issued by the compromised intermediate must be considered suspect. Every system that trusted those certificates must be re-evaluated. Every agent that was carrying one of those IDs must be re-issued a new one from the rebuilt authority.

When Towns Start Talking

So we’ve established that our town clerk issues IDs, that those IDs are short-lived, and that the clerk’s office is the most important building in town. But here’s a question that I had to wrestle with: what happens when our town starts talking to other towns?

Right now our clerk issues IDs that work within our borders. But what if our agents need to operate across multiple environments? What if they need to prove who they are to a service running in the cloud, or to another organization’s infrastructure? My town clerk’s ID doesn’t mean anything to the next town over — unless both towns have agreed on a common standard for what an ID looks like and how to verify it.

This is where SPIFFE comes in. SPIFFE — the Secure Production Identity Framework for Everyone — is an open standard that defines how services and agents identify themselves to each other. Think of it as a set of rules that multiple towns have agreed upon for how IDs should be formatted, what information they contain, and how they can be verified. If our town clerk issues IDs that follow the SPIFFE standard, then any other town that also follows the standard can verify our citizens’ identities without having to trust our specific clerk.

The actual ID that SPIFFE defines is called an SVID — a SPIFFE Verifiable Identity Document. In our town metaphor, this is a standardized ID card format that multiple towns have agreed to recognize. It contains the entity’s identity encoded as a URI like spiffe://our-town/agent/charles, it’s cryptographically signed, and it’s short-lived. Sound familiar? It should. It’s everything we’ve been talking about, but in a standardized format that enables cross-town trust.

SPIRE is the implementation — the actual software that does the work. If SPIFFE is the standard for what the ID card looks like, SPIRE is the clerk’s office that issues them. It handles agent registration, certificate issuance, rotation, and revocation. What makes SPIRE different from a traditional CA is attestation — SPIRE doesn’t just issue a cert to anyone who asks with the right credentials. It verifies the runtime environment itself, confirming both the machine and the specific workload before issuing an identity. Think of it as the clerk not only checking your application but also verifying that you’re actually standing in the clerk’s office and not sending someone in your place. You can run SPIRE alongside or in place of a traditional CA for workload identity.

Now I want to be honest about where I am with this. I’m still learning SPIFFE/SPIRE in practice. My current implementation uses step-ca as my town clerk, and it works well for my homelab. SPIFFE/SPIRE becomes more important as the number of agents and services grows, especially when they need to communicate across trust boundaries. For a homelab or a small environment, a well-configured CA does the job. For an enterprise deploying hundreds of agents across multiple environments, SPIFFE/SPIRE starts to become essential.

And SPIFFE isn’t the only game in town when it comes to emerging standards for agent identity. Multiple draft proposals are circulating within the IETF for OAuth 2.x extensions specifically addressing agent-to-agent authorization — how an agent proves not just who it is but what it’s allowed to do on behalf of someone else. W3C Decentralized Identifiers, or DIDs, are taking a different approach entirely — identities that don’t depend on any single town clerk at all. DIDs can be resolved through various methods — some use distributed ledgers, others use plain DNS and HTTPS, and some are entirely self-contained. DIDs are further out and more relevant for public-facing agents that need to prove their identity to the broader internet, not just within your own infrastructure.

The landscape is still forming. SPIFFE is the most mature standard for what we’re doing. OAuth 2.x agent extensions are coming fast. DIDs are on the horizon. What isn’t going to change is the fundamental problem: agents need verifiable identity, and somebody — or some system — has to issue it.

Identity Is Just the Beginning

We’ve described our town and the first and most important building in it, the clerk’s office. But the reality is that the clerk’s office just issues IDs. It doesn’t tell the businesses in town what the agents are authorized to do. The clerk can issue my assistant Charles a perfect identity but that identity can’t stop Charles from walking into the bank vault. That’s a different system, a different business, a different set of rules.

Proving who you are is just the beginning. Ask anyone who’s ever had their identity stolen: the first question is “who are you?” but the second question is “what are you allowed to do?” And then beyond that — are you doing what you’re supposed to be doing? Everything we’ve discussed in this article is necessary but wildly insufficient on its own. Identity without authorization and behavioral monitoring is like giving someone a perfect driver’s license and no speed limits. You see, identity is not the only necessary piece to protecting your data in this new world with agentic AI. Our town is going to need a lot more services to make things safe…

---