AgentCore Gateway: connect AI agents to business software and private APIs with TLS

AgentCore Gateway can connect an AI agent to private tools and APIs that use TLS certificates issued by a private certification authority. For an SME with an internal management system, the novelty concerns the secure connection between the components of the system. It does not automatically give the agent the right to read or modify any data.

AWS announced support for 2 October 2026. MCP, OpenAPI, and HTTP proxy targets can use TLS with private CA; the path to private endpoints employs VPC Lattice. Availability should be checked in regions where AgentCore Gateway and VPC Lattice coexist. AWS Announcement.

The practical consequence is being able to assess an architecture that does not directly expose business software on the web so an agent can use it. Identity, permitted tools, write controls and error handling still need to be designed. These elements turn a network connection into a reliable business service.

Why does an internal management system create a problem for agents?

Many business applications are only available in the internal network or through controlled paths. An agent executed in another environment cannot simply call them a public service. Opening a door to the Internet may seem like the easiest shortcut, but it introduces an exposure that needs to be motivated and governed.

In addition, the application can use a certificate recognized by the company infrastructure but not by the public authorities normally considered reliable. The component making the call must know which private CA to accept. Disabling certificate verification to pass the test eliminates just the control that should protect the link.

The AgentCore novelty addresses this piece of architecture. The gateway can reach private targets through the documented path and use a configurable trust anchor for the CA. It does not make application verification unnecessary. The AWS Guide on VPC egress describes the design to be evaluated with who manages the network.

What do TLS, private network and permits guarantee?

TLS protects the connection and verification of the identity of the service according to the configuration adopted. A private network limits the path of reachability. Authorizations instead determine who can perform a given operation on a specific data. None of these controls can be used as a synonym for others.

An agent can successfully reach a private API and still have too many permissions. It can successfully authenticate itself and ask for a customer's document foreign to the request. It can send technically valid parameters that produce a wrong commercial result. These cases require controls in the application layer, in addition to the protected link.

For this reason it is better to describe the system with concrete verbs: read the status of the order, prepare a request, update a field allowed. "Access to management software" is too broad a definition. The Guide to AI Data Security helps to reason on minimization and access; integration must then translate these principles into actually limited operations.

Which APIs should be exposed to the agent?

A management system can have an extended API, designed for users or applications with different responsibilities. Presenting all of its functions to an agent makes it more difficult to verify behavior and permissions. It is often preferable to build a smaller surface, with operations consistent with the chosen process.

For example, the instrument may require customer identification and order number, check the relationship between the two, and only return status and useful information. It should not automatically deliver accounting documents, margins or internal notes. The fields of the result are a project decision, not a detail of the prompt.

When changes are needed, the tool must verify parameters and current status. An address change request can be admitted before shipment and refused after, according to the company rules. The model should not be the only component that applies this rule. The AI Agents for Companies They work best when reasoning and operational constraints remain distinguishable.

How to choose the level of integration?

The table proposes design criteria. It does not mean that every internal application is already compatible with the gateway. If a suitable API is missing, a connector or software modification may be needed. If the problem is a flow between applications, integrate a management software with n8n It tackles a different part of the job.

Also the European expansion of AWS MCP Server has a distinct role: that server allows development agents to interact with AWS services. Here the point is to bring a request from the agent to the company's private tools, with the correct trust report on the certificate.

Hypothetical scenario: a distributor consults orders

Let's imagine an Italian distributor with a management system accessible only to the company network. Commercial staff want to ask an assistant for delivery status without opening multiple screens each time. The first pilot only allows the reading of orders connected to customers assigned to the user.

The gateway reaches the private API via the intended architecture. The API checks the identity and commercial perimeter, then returns the status. The assistant distinguishes an updated data from an unavailable data and does not complete an answer using assumptions. If the order does not belong to the user's perimeter, the request is refused even when the model knows its number.

This is a hypothetical scenario. The test must include homonym customers, non-accessible orders, non-existent identifiers and unavailable management software. Success is a correct and authorized response, with a recognizable source. No time savings or measured improvement is assumed: they are results to be observed in the project, not automatic properties of the link.

Hypothetical scenario: a maintainer prepares requests for intervention

Consider a maintenance SME that collects requests from operators on the territory. The agent helps to prepare a card with implantation, reported problem and relevant documents. The internal system uses corporate CA certificates and is not publicly displayed. Private TLS support may be relevant to achieving it in the chosen design.

The first version prepares a draft. Operator controls plant and priority before final registration. The descriptions received can be incomplete or contain extraneous instructions: they are treated as the content of the request, without becoming permission to search for other data. Inclusion in management software takes place only through a restricted function.

This case is also hypothetical. The test must above all verify the association to the correct plant and the management of the missing information. An agent who asks for clarification may be preferable to one who quickly completes a wrong card. The private link protects the path, while the correctness of the card depends on data, rules and staff control.

What to try with certificates and network?

Open track for private target testing

Verify the correct target, trusted CA, network path, and region adopted. Try an untrusted certificate, an unreachable endpoint, and a permissionless identity. Check that no errors are bypassed by disabling TLS verification. Keep the technical and the application results separately.

Then we need a plan for the rotation of certificates. When the CA changes or a certificate expires, the system must detect the problem and direct it to the manager. A working configuration on the day of the test does not prove that the integration is maintainable. Inventory should include dependencies, owners, and upgrade procedure.

Regional availability should not be extended to all AWS: the joint presence of the requested services is required. Accounts and architecture may also require specific verification. The operational source remains the AgentCore Gateway documentation, along with the announcement of support. Universal or automatic availability is not affirmed here in an Italian region.

When do you still need a dedicated connector?

Reducing the need for private linkage intermediaries does not eliminate every integration function. A connector can still serve to transform data, apply business rules, manage compatibility with legacy software, or offer more restricted operations than the original ones. The criterion is the responsibility it must carry out, not the number of components to be removed.

If the management software does not have APIs, automating the graphical interface is another path. The new classes of Claude SDK for browsers and computers use It's about that kind of interaction. A controlled API access and an action on the screen have different frailties: the second also depends on layout, sessions and interface behavior.

The same private link can become an instrument of a voice agent, as in the case of Amazon Nova Sonic. Change the request channel, but remain identities and permissions. A natural entry must not get more rights than an authenticated user through a web page.

What mistakes to avoid in accessing the management system?

The first is to confuse “internal” with “authorized.” A secure network can host information that the agent should not see. The second is to resolve a certificate issue by turning off the TLS verification. The third is to share an administrative credential for all requests, losing the ability to distinguish users and responsibilities.

Another mistake is retrying writes without knowing whether the first call took effect. A timeout does not prove that the business software did not record the operation. The procedure must use identifiers and checks that recognise a request already executed. Otherwise, the automation can create duplicate service jobs, orders or communications.

Finally, it is fragile to keep the entire response of the management software in the logs when the status and outcome are sufficient. Traces must allow diagnosis and accountability without becoming an indiscriminate copy of the data. The review should also include what support staff see, because log access is part of the project.

How to maintain integration when management software changes?

An internal API can change fields, status codes, or meaning of responses. The TLS link can continue to work as the content becomes incompatible with the agent's tool. This is why testing must distinguish the availability of the network and the correctness of the application contract. A successful call does not prove that the answer is usable.

It is advisable to keep examples of permitted requests and their expected responses. When the management software provider updates the software, these cases help to recognize a significant difference. A missing field should not be replaced by the model with a plausible value: the system must treat it as a limit and choose the intended path.

The same principle applies to authorisations. If a person changes roles or leaves the company, the agent should not continue to operate with rights associated with the old situation. Revocation and revision of accesses must follow staff processes, not depend on manual prompt correction. A shared technical identity requires special attention to the perimeter of requests.

The procedure for assistance must also be verified. Whoever receives an error must understand if a resource is missing, a credential has expired or the service is not reachable. The message addressed to the user can remain simple, while the technical track helps the person in charge to intervene. Neither should include secrets or data in excess of the problem.

Finally, the link should be deactivated. A pilot can reveal that the API does not offer sufficient guarantees or that the process requires more revision than expected. In that case the staff must be able to continue with a known procedure, without losing the requests already collected. Reversibility is a useful property even after startup.

What result to ask the first pilot?

A useful pilot must demonstrate a complete path: an authorised request, a call to the correct target, a limited response, error handling and a result staff can understand. The first extension should come after the boundaries have been verified, not as soon as the agent produces a convincing answer.

The company should also receive a dependency map and a list of responsibilities. Who keeps the API? Who rotates the certificates? Who can revoke access? Who controls a disputed writing? These answers make maintenance concrete. The cost should be estimated on the complete architecture, without confusing a new cloud function with a ready-made project at fixed cost.

If your management software needs to remain private, a path of automation of business processes can start with a delimited and verifiable consultation. From there it is decided what actions to add, with what identity and with what control before they become real commitments for the company.