Im Fixing Bot-to-Bot Authentications Glaring Holes

Hey everyone, Pat Reeves here, dropping in from the botsec.net bunker. Today’s date is March 31, 2026, and I’ve been thinking a lot lately about how we’re handling our bots’ identities. Not in a philosophical “who am I?” way, but in a very practical, “who is this bot, and why is it allowed to do that?” kind of way.

Specifically, I want to talk about bot-to-bot authentication and the glaring holes I’m seeing out in the wild. We’ve come a long way from hardcoding API keys in every script, thank goodness. But even with modern practices, there’s a persistent, insidious pattern of “good enough” that’s setting us up for some serious headaches down the line.

The “Good Enough” Trap: Why Your Bot-to-Bot Auth is Probably Weaker Than You Think

I was on a call just last week with a startup that was positively beaming about their microservices architecture. They had dozens of bots, all chatting away, doing their thing. And when I asked about their bot-to-bot authentication strategy, the lead dev proudly declared, “Oh, we’re using JWTs and service accounts!”

Sounds great on paper, right? JSON Web Tokens are industry standard, service accounts are a step up from root access. But as we dug deeper, it became clear their implementation was… let’s just say, more porous than a sieve.

Here’s the thing: many teams treat bot-to-bot auth like a checklist item. “Are we using tokens? Check. Are we using service accounts? Check.” They don’t actually think through the attack vectors a malicious actor would use to impersonate or compromise one of their bots.

And that’s where the “good enough” trap gets you. It’s the difference between having a lock on your door and having a lock that can be picked with a bobby pin.

The Over-Permissive Service Account: A Classic Blunder

This is probably the most common vulnerability I encounter. You create a service account for Bot A, which needs to read data from Bot B. So, what permissions do you give Bot A’s service account? Often, it’s something like `read:*` or even `admin:*` within Bot B’s scope.

Why? Because it’s easier. It avoids granular permission issues, and it “just works.” But think about the implications. If an attacker compromises Bot A (say, through a vulnerable dependency or a misconfigured environment variable), they now inherit all of Bot A’s permissions. If Bot A has `admin:*` access to Bot B, then the attacker now controls Bot B too. It’s a lateral movement dream for an adversary.

I saw this play out with a client last year. Their “data ingestion” bot had read/write access to pretty much their entire internal database because, “it sometimes needs to update flags.” When that bot was compromised via an exposed internal endpoint, the attackers had a field day, not just exfiltrating data, but also injecting malicious records that caused downstream systems to malfunction for days.

Long-Lived, Statically Issued Tokens: A Ticking Time Bomb

Another common pattern: generating a JWT or API key for a bot, and then embedding it directly into its configuration or environment variables. And these tokens? They often have expiration dates measured in months, or sometimes, no expiration at all.

This is essentially giving your bot a permanent, physical key to a vault. If that key is ever exposed – through a leaked config file, a compromised CI/CD pipeline, or even just a careless `echo $TOKEN` during debugging – it’s game over until you manually rotate it. And how often do you realistically rotate these long-lived, static tokens?

One company I worked with had their entire internal microservice communication secured by a single, never-expiring API key for each service. These keys were stored in plaintext in their Git repository (a private one, thankfully, but still). When a new developer joined, they’d clone the repo, and instantly have access to every internal service. “It’s just for internal dev,” they argued. Until one day, a disgruntled former employee decided to make use of their lingering access.

Beyond “Good Enough”: Practical Steps for Robust Bot-to-Bot Auth

So, how do we move past these common pitfalls? It’s not rocket science, but it requires a shift in mindset from “checking the box” to “actively minimizing risk.”

1. Implement Least Privilege, Always

This isn’t new advice, but it’s critically important for bot-to-bot communication. Each bot’s service account or identity should have the absolute minimum permissions required to perform its specific function, and nothing more.

Instead of `read:*`, specify `read:users`, `read:orders`, and only if absolutely necessary, `write:order_status` for a specific field. This makes the attacker’s job much harder. Even if they compromise Bot A, their blast radius is significantly reduced because Bot A only has access to a very narrow set of resources.

Here’s a simplified example of how you might define a granular IAM policy for a bot that only needs to read customer data:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "s3:GetObject"
 ],
 "Resource": "arn:aws:s3:::my-customer-data-bucket/customers/*"
 },
 {
 "Effect": "Allow",
 "Action": [
 "dynamodb:GetItem",
 "dynamodb:Query"
 ],
 "Resource": "arn:aws:dynamodb:REGION:ACCOUNT_ID:table/customer_profiles"
 }
 ]
}

Notice how specific the actions and resources are. This isn’t a blanket `s3:*` or `dynamodb:*`. It’s a targeted permission set.

2. Embrace Short-Lived, Dynamically Issued Credentials

This is probably the single most impactful change you can make. Instead of hardcoding long-lived tokens, have your bots request short-lived credentials from a centralized identity provider (IdP) just before they need to perform an action.

Think about cloud IAM roles (like AWS IAM roles for EC2 instances or Kubernetes service accounts with IRSA). Your bot (running on an EC2 instance or in a K8s pod) assumes a role, and the cloud provider dynamically issues temporary credentials that are valid for a short period (e.g., 15 minutes to an hour). These credentials are automatically refreshed, so the bot always has valid access without you ever touching a static token.

If an attacker compromises the bot, they only have access for a very limited time. Once the temporary credentials expire, their access is revoked unless they can re-authenticate. This significantly narrows the window of opportunity for an attacker.

For internal systems not running directly on cloud infrastructure, you can implement similar patterns using tools like HashiCorp Vault or even a custom identity service that issues time-bound JWTs or API keys that are signed and validated.

Here’s a conceptual flow for dynamically issued credentials:

1. Bot A starts up, authenticates itself to an IdP using a secure, platform-specific mechanism (e.g., instance metadata, Kubernetes service account token).
2. IdP verifies Bot A’s identity and issues a short-lived access token for a specific scope (e.g., 15 minutes, permission to call Bot B’s `/read-metrics` endpoint).
3. Bot A uses this token to call Bot B.
4. Before the token expires, Bot A requests a new token from the IdP.
5. If Bot A is compromised, the attacker only has access for the token’s remaining validity period.

3. Secure Your Identity Provider

This might sound obvious, but it’s worth stating: your IdP is the crown jewel. If an attacker compromises your IdP, they can impersonate any bot and issue credentials at will. Ensure your IdP is hardened, monitored, and follows best security practices (MFA for human access, strict network isolation, regular audits, etc.).

4. Implement Mutual TLS (mTLS) for Sensitive Communications

For critical bot-to-bot communications, especially over networks you don’t fully control, consider using mutual TLS. With mTLS, both the client bot and the server bot present certificates to each other and verify their identities before establishing a connection.

This provides two-way authentication: not only does the server know who the client is, but the client also knows it’s talking to the legitimate server, preventing man-in-the-middle attacks and impersonation.

Tools like Istio, Linkerd, or even Nginx with client certificate authentication can help you implement mTLS without rewriting all your application code. For example, if you’re running services in Kubernetes with Istio, you can enable mTLS with a few lines of YAML:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
 name: default
 namespace: my-bot-services
spec:
 mtls:
 mode: STRICT

This forces all services in the `my-bot-services` namespace to communicate using mTLS, assuming your service mesh is properly configured.

Actionable Takeaways for Your Bot Security Audit

Alright, let’s wrap this up with a few concrete actions you can take starting today to tighten up your bot-to-bot authentication:

• Inventory Your Bots and Their Permissions: Do you know every bot you have and exactly what resources it can access? Create a spreadsheet, use a configuration management tool, whatever it takes. Get a clear picture.
• Review Service Account Policies: For each bot, critically evaluate its permissions. Can you reduce them? Can you make them more granular? Apply the principle of least privilege rigorously.
• Identify Long-Lived Tokens: Scan your codebases and configurations for static, long-lived API keys or JWTs. Prioritize replacing these with dynamically issued, short-lived credentials.
• Explore Cloud IAM Roles / Identity Providers: If you’re on a cloud platform, make sure you’re fully utilizing its native IAM roles for dynamic credential issuance. If not, investigate solutions like HashiCorp Vault.
• Consider mTLS for Critical Paths: Identify your most sensitive bot-to-bot communications and explore implementing mutual TLS for enhanced authentication and encryption.
• Plan for Credential Rotation: Even with dynamic credentials, have a plan for how you’d rotate root keys for your IdP or certificates for mTLS.

Don’t fall into the “good enough” trap. Your bots are often the unseen workforce of your infrastructure, and their security is paramount. By taking these steps, you’re not just checking a box; you’re building a truly resilient and secure bot ecosystem. Stay safe out there, and keep those bots locked down!

🕒 Published: March 31, 2026