AgentCore Gateway Now Supports Private TLS Certificates: What It Means for Agent Security

In my earlier post on AgentCore Policy, I compared the gateway to a bouncer standing at the door, checking every action an AI agent wants to take before it happens. That bouncer decides what your agent is allowed to do. But there's a second question that matters just as much: how does the gateway safely talk to the private systems your agent actually needs to reach?

A recent update to Amazon Bedrock AgentCore Gateway answers part of that question. It now supports TLS certificates signed by private certificate authorities for connections to private endpoints inside your VPC. If that sentence sounded like a wall of jargon, don't worry. This post breaks it down step by step, explains why it matters for agent security, and shows what changed compared to before.

An AI agent usually doesn't work alone. It calls tools, and those tools often live on internal systems, like a company API, a database wrapper, or a self hosted MCP server. AgentCore Gateway sits in the middle, helping the agent reach those tools in a controlled way.

For safety, many companies keep those internal systems on private networks, not the public internet. AgentCore Gateway can reach them through your VPC using Amazon VPC Lattice, which lets the gateway connect to private endpoints without exposing them publicly. So the network path was already private.

TLS is the technology that encrypts a connection and proves who you're talking to. When your gateway connects to a backend system, that system shows a certificate, like an ID card, saying "yes, I really am who I claim to be." The gateway checks that ID before sending anything sensitive.

Here's the important part. Certificates are issued by a certificate authority, or CA. Public CAs are trusted by everyone by default. But many companies run their own private CA for internal systems, since it gives them full control and avoids paying for or exposing certificates for internal services.

Before this update, AgentCore Gateway only trusted publicly signed certificates. If your internal system used a certificate from your own private CA, the gateway didn't recognize that ID card, and the connection failed during the handshake.

The workaround was to place an internal Application Load Balancer in front of your service, using a public certificate from AWS Certificate Manager. It worked, but it meant adding an extra piece of infrastructure just to satisfy the gateway. More components means more setup, more cost, and more things that can be misconfigured, which is not great when the whole point is tighter security.

AgentCore Gateway can now trust certificates signed by your private CA. Based on the announcement, here's what stands out:

It supports private CA certificates for MCP, OpenAPI, and HTTP proxy targets, so it covers the main ways agents connect to tools.

It allows secure connections to private endpoints without needing an intermediate load balancer, which removes that workaround entirely.

The gateway fetches your PEM encoded CA certificate from Amazon S3 or AWS Secrets Manager, so you can store the certificate in a place you already manage.

It's available in all Regions where AgentCore Gateway and VPC Lattice are supported.

In plain terms, you tell the gateway which private CA to trust, and it can then connect directly to your internal services using the certificates they already have.

It's easy to read this as a convenience feature, but I think the security angle is the more interesting one.

First, fewer moving parts. Every extra component in the path between your agent and your tools is another thing to secure, monitor, and keep updated. Removing the load balancer workaround shrinks that surface.

Second, you keep control of your own trust. With a private CA, you decide exactly which services are trusted internally. You're not forced to push internal services into the public certificate system just so the gateway will accept them.

Third, it keeps the end to end story clean. In my earlier posts, I talked about defense in depth, meaning several layers protecting an agent. Policy rules control what the agent can do. Guardrails check what it reads and says. Encrypted, verified connections make sure that when the agent does act, it's talking to the real internal system and not something pretending to be it. This update strengthens that last layer.

Imagine your agent needs to look up an order in an internal system. Several things need to be true for that to be safe:

The agent must be allowed to look up orders, which is handled by policy rules at the gateway.

The request and response must be checked for anything suspicious, which is handled by guardrails.

The connection to the internal order system must be encrypted and verified, which is where private TLS certificates come in.

Everything must be logged so you can trace what happened, which is handled by your monitoring setup.

Each layer covers a different risk. None of them replaces the others.

Treat your private CA with care. If someone gains control of it, they could issue certificates your gateway would trust. Protect it the way you'd protect any critical secret.

Store the CA certificate securely. Since the gateway pulls it from S3 or Secrets Manager, make sure access to that location is tightly restricted, and that only the right people and roles can change it.

Test the failure case on purpose. Try connecting to a service with a certificate that is not signed by your CA and confirm that the connection is rejected. A security feature you have never seen block something is a security feature you are only assuming works.

Check the official documentation for current limits and setup details, since this is a recent feature and specifics can change.

Announcements like this rarely get the attention that new AI models do, but they're the kind of change that makes real production systems safer. Agents that talk to private systems are only as trustworthy as the connections they use, and being able to use your own certificate authority directly makes it easier to keep those connections both private and verified.

If you're running agents against internal systems, this is worth a close look. And if you've already set it up, I'd love to hear how it went and whether anything surprised you. Drop a comment, I'm always happy to compare notes.