Classical Public-Key Foundations · 5 of 5
One Agent Connection, Several Different Keys
One secure call from an AI agent to a tool quietly involves at least four kinds of keys. Follow the handshake, name each key, and see what stealing it would really cost.
Ask most people how a secure connection works and you will hear something like 'the two sides use a key to encrypt the traffic'. That sentence hides a surprising amount. When an artificial intelligence (AI) agent makes a single protected call to a tool server, at least four different kinds of keys take part, each created at a different time, held by a different party, living for a different length of time and doing a different job. Some prove identity, some build a secret, some encrypt the data and one vouches for all the others. Mixing them up leads to bad decisions: protecting the wrong key, rotating the wrong one, or misjudging how bad a leak really is. This article follows one real-world style connection from the first hello to the first encrypted byte, names every key along the way, and then asks the question that matters most to anyone running agents in production: if this particular key were stolen, what exactly could an attacker do, and for how long?
The scene: an agent calls a tool
Picture a concrete setup. An AI agent, software that uses a language model to decide on actions and then calls tools to carry them out, needs to read a customer record. It does this by calling a tool server, a service that exposes the customer database through a small set of operations. The agent and the tool server live on different machines and talk over a network that other systems share.
The organisation wants two guarantees. The agent must be sure it is talking to the real tool server and not an impostor that would feed it false data. And the tool server must be sure the caller really is this agent, so that it can apply the agent's permissions and record who asked for what. When both sides prove their identity to each other in this way, the connection is called mutual Transport Layer Security, usually shortened to mutual TLS or mTLS. Transport Layer Security (TLS) itself is the protocol behind the padlock in a browser and behind most machine-to-machine connections.
The rest of this article follows a single mutual TLS connection using version 1.3 of the protocol, the current version. The details are simplified, but every key named here exists in real deployments, and the questions about each one are exactly the ones a security review should ask.
Before the connection even begins, two things are already in place. The tool server holds a certificate, an electronic document that says 'this public key belongs to tools.example.internal', signed by a certificate authority (CA) the agent trusts. The agent holds its own certificate, saying 'this public key belongs to the customer-support agent', signed by a CA the tool server trusts. Each side also holds the private key that matches the public key in its own certificate.
Many agent setups use a different pattern instead: ordinary TLS where only the server proves its identity, with the agent sending a password-like token, often called a bearer token, inside the encrypted connection. That works, but the token is a secret that can be copied and replayed by anyone who obtains it. With mutual TLS the agent's proof is a signature made fresh for each handshake by a key that never travels, which is much harder to steal in transit. The two approaches are often combined, and the key map below applies to both.
The handshake, step by step
Step one: the agent sends a hello. Its opening message, called the ClientHello, lists the options it supports and, importantly, includes a key share: the public half of a brand-new key pair created just for this connection, most often on the X25519 elliptic curve. The private half never leaves the agent's memory.
Step two: the tool server replies with its own hello, called the ServerHello, containing its own fresh key share. Now both sides can run an elliptic-curve Diffie-Hellman calculation: each combines its own fresh private value with the other side's public share and arrives at the same shared secret, which never crossed the network. From this point everything else in the handshake is encrypted with handshake keys derived from that secret.
Step three: the tool server proves who it is. It sends its certificate chain, and then a message called CertificateVerify: a signature, made with the private key that matches its certificate, over a fingerprint of everything said so far in the conversation. That fingerprint of the whole conversation is called the transcript hash. Signing it ties the server's long-term identity to this exact handshake, including the fresh key shares, so an attacker in the middle cannot swap in their own shares without the signature failing. The server also asks the agent for a certificate, and finishes with a Finished message, a short code computed from the handshake secret that proves it saw the same conversation.
Step four: the agent checks the server's certificate chain up to a CA it trusts, checks that the name matches the tool it meant to call, and checks the CertificateVerify signature. Then it does the same in reverse: it sends its own certificate, its own CertificateVerify signature made with the agent's private key, and its own Finished message. The tool server checks all of that against the CAs it trusts for agents.
Step five: both sides derive the application traffic keys, the keys that actually encrypt the customer-record request and the response, and the agent's call goes through. The fresh private values from step one have done their job and are erased.
Four kinds of keys, four different jobs
Now name the keys. The first kind is the issuer key: the private key of each certificate authority. It is used only to sign certificates, for example to sign the tool server's certificate and, separately, the agent's. It never appears in the connection at all; only its signatures do. It typically lives for years, and it should live in a hardware security module, a locked-down device that performs signing without ever revealing the key.
The second kind is the leaf signing key: the private key that matches a certificate at the end of a chain, the 'leaf'. There are two in a mutual TLS connection, one for the tool server and one for the agent. Each is used during the handshake to sign the transcript hash in CertificateVerify, proving its owner's identity. A leaf key lives as long as its certificate, which might be a year for a traditional server certificate, or hours to days for an automatically rotated workload certificate.
The third kind is the ephemeral agreement key: the fresh private value each side created for its key share in the hello. It is used once, to compute the shared secret, and then erased. It lives for a fraction of a second. It proves nothing about identity; its only job is to make a secret that will not outlive the connection.
The fourth kind is the traffic key. From the shared secret, both sides derive a series of symmetric keys, meaning keys that are the same on both ends: one set to protect the rest of the handshake, and then the application traffic keys, one for each direction, that encrypt and authenticate the actual data. Traffic keys live as long as the connection, and TLS 1.3 can even replace them in the middle of a long connection with a key update message.
It is worth pausing on how many separate keys that adds up to. Counting both sides, a single call can involve two issuer keys, two leaf signing keys, two ephemeral agreement keys and at least four traffic keys for the handshake and application data in each direction. Most of them exist for less than a second, and almost none of them is ever seen by a human, which is exactly how it should be.
| Key | Held by | Job | Typical lifetime |
|---|---|---|---|
| Issuer (CA) key | Each certificate authority | Signs certificates | Years |
| Leaf signing key | Tool server; agent | Signs the handshake transcript | Hours to a year |
| Ephemeral agreement key | Both sides, in memory | Builds the shared secret | One handshake |
| Traffic keys | Both sides, in memory | Encrypt the data, per direction | One connection or less |
Why the protocol keeps the jobs apart
It would be simpler to use one key for everything, and early protocols came closer to that. The separation in modern TLS exists because each kind of key is exposed to different risks, and keeping the jobs apart stops a problem with one key from spreading to the others.
The most important separation is between proving identity and making the secret. In the old static RSA style of key exchange, still found in very old configurations, the client encrypted the session secret to the server's long-term key. That meant anyone who later stole the server's private key could decrypt every recording of every past session. TLS 1.3 removed that option: full handshakes always build the secret from ephemeral key shares, and the long-term leaf key only signs. The leaf key vouches for the conversation but never contributes to the secret. That property, that stealing a long-term key later cannot unlock traffic recorded earlier, is called forward secrecy.
A second separation is between the many traffic keys. Using different keys for each direction, and different keys for the handshake and the application data, means that a weakness in how one stream of messages is handled cannot be turned into an attack on another. A third is between issuer and leaf: the issuer key never touches live traffic, so the most powerful key in the system is also the least exposed.
There is a useful general rule hiding in this design, and it applies far beyond TLS: give every key exactly one job, and make its lifetime match that job. Identity keys last as long as the identity is trusted. Secret-making keys last only as long as it takes to make the secret. Data keys last only as long as the data flows.
TLS 1.3 adds two refinements that follow the same logic. A long-running connection can replace its traffic keys partway through with a key update message, so that even a leaked traffic key only exposes a slice of the conversation. And a client that reconnects soon can resume using a secret left over from the previous connection; by default, resumption still mixes in fresh key shares so that forward secrecy is preserved, while a resumption without fresh shares trades some of that protection for speed.
If this key were stolen, what would it cost?
The real payoff of naming the keys is being able to answer the question every incident responder asks first: what can the attacker do now, and for how long? The answers differ enormously.
A stolen traffic key is the smallest loss. Someone with it can read, and potentially alter, the data in one direction of one connection, until that connection ends or the keys are updated. A stolen ephemeral agreement key, for example scraped from memory during the handshake, gives roughly the same: that one connection's secrets, and nothing else. Neither lets the attacker impersonate anyone.
A stolen leaf signing key is a much bigger problem, but of a specific shape. With the tool server's leaf key, an attacker who can intercept traffic can pretend to be the tool server to any agent that trusts its certificate, until the certificate expires or is revoked. With the agent's leaf key, an attacker can pretend to be the agent to any tool that trusts it, calling tools with the agent's permissions. What a stolen leaf key cannot do, thanks to forward secrecy, is decrypt recordings of past connections, because the secrets for those connections came from ephemeral keys that no longer exist.
A stolen issuer key is the worst case. The attacker can mint brand-new certificates for any name that CA is trusted to vouch for, creating fake tool servers or fake agents at will, and every system that trusts the CA will accept them. Recovery means distrusting the CA everywhere and re-issuing every certificate it signed, which is why issuer keys sit in hardware security modules and are used as rarely as possible.
Notice the pattern: the longer a key lives and the more it vouches for, the larger the damage when it leaks. That is not an accident; it is the design. Short-lived keys are cheap to lose; long-lived keys are guarded heavily and used rarely.
One leak, traced from start to finish
To make the map concrete, follow an illustrative incident from start to finish. It is a composite of a common pattern, not a specific real event. A team packages its customer-support agent in a container image, and to keep things simple, the agent's leaf private key and certificate are copied into the image. The certificate is valid for a year.
Months later, the image is pushed to a registry that turns out to be readable by a wider group than intended. Someone outside the team pulls the image and finds the key file. What can they do with it? Following the map, the answer is precise. They hold a leaf signing key, so they can impersonate the agent: they can open mutual TLS connections to every tool server that trusts the agent's CA and call those tools with the agent's permissions, reading customer records and performing whatever actions the agent is allowed to perform.
What they cannot do is just as important. They cannot read recordings of the agent's past conversations, because those secrets came from ephemeral key shares that were erased long ago. They cannot impersonate the tool servers, because they do not hold the servers' leaf keys. And they cannot mint new identities, because they do not hold the issuer key. The blast radius is one identity, with that identity's permissions, for as long as the certificate stays trusted.
The response follows from the same map. Revoke the agent's certificate and issue a new key pair that never touches an image. Review the tool servers' logs for calls made with the agent's identity from unexpected places since the image was published. And fix the root cause: move the key into a key store, switch the agent to short-lived automatically issued certificates so the next leak would expire in hours, and narrow the agent's permissions so that even a successful impersonation could do less. Notice that none of these steps involves the traffic keys or the issuer key; knowing which key leaked keeps the response focused.
How agent deployments quietly collapse the separation
The protocol keeps the keys apart, but deployments can undo that work without anyone noticing. Agent systems are particularly prone to it, because they are often assembled quickly from containers, configuration files and automation, and because the agent itself reads text from many places.
The first collapse is a leaf key that is not really private. An agent's private key baked into a container image, stored in an environment variable, committed to a repository or pasted into a configuration file is readable by anyone who can read those places. A key that a model can read can end up in a prompt, a tool result or a log, and then it is no longer an identity, just a password with extra steps.
The second is one identity shared by many agents. Giving every agent the same certificate and key makes them indistinguishable to every tool, so permissions cannot be scoped per agent and audit logs cannot say which agent did what. Stealing that one key impersonates all of them at once.
The third is long lifetimes where short ones would do. A year-long leaf certificate for an agent that is redeployed every day means a stolen key stays useful for months. Automatic issuance of short-lived workload certificates, measured in hours or days, shrinks the window dramatically.
The fourth is exporting traffic secrets. Many TLS libraries can write their session secrets to a file so that a debugging tool can decrypt captured traffic, a feature commonly enabled through a variable named SSLKEYLOGFILE. It is invaluable in a lab and quietly devastating in production, because it hands an attacker exactly the traffic keys forward secrecy was designed to make disappear.
The fifth is switching off verification. A test setting that skips certificate checks, if it reaches production, makes all of the identity keys irrelevant: the agent will complete a handshake with anyone, including an attacker in the middle.
- Leaf private keys in images, environment variables, repositories or prompts.
- One certificate shared by many agents.
- Year-long certificates for short-lived workloads.
- Session secrets exported to key-log files outside a lab.
- Certificate verification disabled 'temporarily'.
What this means for practitioners and for AI agents
For teams running agents, the practical controls map directly onto the four kinds of keys. Protect issuer keys in hardware and use them rarely, ideally through a managed certificate service so that nobody handles the key directly. Give each agent its own leaf identity, issued automatically, short-lived and rotated without human involvement; where the platform offers a managed workload identity, use it rather than handling key files at all. Keep leaf private keys in a key store or hardware security module that signs on the agent's behalf, so the key never sits anywhere a process, a person or a model can copy it.
Let the protocol handle the ephemeral and traffic keys, and do not undo its work. Require TLS 1.3 where possible, so every full handshake uses fresh key shares and gives forward secrecy. Never enable session-secret export outside a controlled lab, and make sure agent telemetry and tracing never record key material, raw handshake secrets or authorization headers.
Verification deserves the same care as keys. Every agent connection should check the full certificate chain, the expiry and the name of the tool it intended to reach, and tool servers should check the agent's certificate against the CA they trust for agents and map it to that agent's permissions. When something fails, the connection should fail closed, with an alert, rather than fall back to an unverified mode.
Finally, plan the incident response before the incident. For each kind of key, write down how you would detect a leak, how you would revoke or rotate it, and how long the attacker's window would stay open. The answers make the design choices obvious: if replacing an agent's key takes a week and a ticket, the key will live too long; if it takes one automated step, short lifetimes become easy.
Looking ahead, post-quantum key agreement is being added to TLS by combining X25519 with a new key-encapsulation method in the key share. That changes what goes inside the ephemeral key share, but not the map in this article: there will still be issuer keys, leaf signing keys, ephemeral agreement keys and traffic keys, each with one job and one lifetime.
Identity is only useful if something acts on it. On the tool side, map each agent's certificate to a specific set of permissions, the smallest set that agent needs, and record the identity in every log entry. Then the blast radius of a stolen agent key is limited by design: the attacker inherits exactly what that one agent could do, and the logs show exactly what was done in its name.
Key takeaways
- A single mutual TLS call from an agent to a tool involves issuer keys, two leaf signing keys, ephemeral agreement keys and per-direction traffic keys.
- Ephemeral key shares build the secret; leaf keys only sign the handshake transcript; issuer keys only sign certificates; traffic keys protect the data.
- TLS 1.3 keeps identity and secret-making apart, giving forward secrecy: a stolen long-term key cannot decrypt traffic recorded earlier.
- The blast radius grows with lifetime and authority: a traffic key exposes one connection, a leaf key one identity, an issuer key every identity it covers.
- Agent deployments undo the design through keys in images or prompts, shared identities, long lifetimes, exported session secrets and disabled verification.
- Give each agent its own short-lived, automatically rotated identity held in a key store, require TLS 1.3, and never log or export key material.
Glossary
- Mutual TLS (mTLS)
- A TLS connection in which both sides present a certificate and prove they hold its private key.
- Certificate authority (CA)
- An entity whose issuer key signs certificates that tie public keys to names.
- Leaf certificate
- The certificate at the end of a chain that names the actual server or agent.
- Key share
- The public half of a fresh key pair sent in a TLS hello to build the shared secret.
- CertificateVerify
- The TLS message in which a side signs the transcript hash with its leaf private key to prove its identity.
- Transcript hash
- A fingerprint of every handshake message exchanged so far, which the signatures and Finished messages cover.
- Traffic keys
- Symmetric keys derived from the shared secret that encrypt and authenticate the data in each direction.
- Forward secrecy
- The property that stealing long-term keys later cannot decrypt traffic that was recorded earlier.
- Workload identity
- A short-lived, automatically issued identity for software such as an agent, instead of a long-lived key file.