# Where Should an Agent’s Tools Live?

> Compare local functions, direct services, and shared gateways by ownership, enforcement, failure behaviour, and operating cost.

[Canonical HTML page](https://trustcyber.ca/insights/ai-tool-access-patterns/)

- Author: [Junior Williams](https://trustcyber.ca/about/)
- Type: Insight brief
- Published: 2026-09-26
- Modified: 2026-09-26
- Topics: Enterprise architecture, Agentic AI, Cybersecurity

A team building its first agent can expose a function directly and finish the integration quickly. A platform team supporting many agents may want a shared tool gateway. Both choices can be reasonable. The deciding factors are where authority is enforced, who owns the service, and what happens when a dependency fails.

![Three architectures: a local tool within the agent runtime, a direct connection to a remote service, and a shared gateway routing to services.](https://trustcyber.ca/images/insights/decision-series/tool-access-architectures.svg)

Conceptual patterns. The protected service retains responsibility for business rules in all three designs.

## Local functions: a compact operating boundary

An in-process tool shares the agent’s deployment and runtime. That can make a bounded workflow easy to understand, test, and support. One team can version the function and its caller together. The cost appears when several agents copy the same integration and gradually diverge in credentials, validation, and logging.

Treat the local call as a real business operation. Validate inputs, keep secrets out of model-visible context, and ensure the target system checks permissions. A function running nearby can still change a distant production record.

## Direct services: ownership at the destination

A remote API or tool server can evolve independently of the agent. Its owner can enforce permissions, maintain a versioned contract, and scale the service for several callers. This is attractive when the target systems already have strong authorization and operational support.

The integration burden grows as more agents connect to more services. Teams need consistent ways to discover tools, delegate credentials, interpret failures, and correlate logs. A protocol can standardize communication while leaving these governance decisions unresolved.

**The architectural tradeoff**

| Pattern | Useful when | Operating cost to examine |
| --- | --- | --- |
| Local function | One team owns a narrow workflow | Duplicated controls as integrations spread |
| Direct remote service | Destination has strong ownership and authorization | Repeated discovery, delegation and logging work |
| Shared gateway | Many agents need common policy and visibility | Availability, latency, isolation and bypass prevention |

## Shared gateways: common control, common dependency

A gateway can provide a tool catalogue, apply policy, manage access, and standardize event records. AWS’s enterprise guidance identifies tool registries and access controls as governance concerns. A gateway is one implementation choice for those concerns; its usefulness depends on what it actually enforces.

Design the failure mode deliberately. If the gateway is unavailable, should the action wait or stop? If an agent still has a direct route and a broad token, the gateway may not control the operation. Tenant isolation and credential handling also need attention when several teams share the same component.

Keep business authorization close to the system with the necessary facts. A gateway may know that a caller can request a refund, while the payment service knows whether that particular transaction is refundable. Those checks complement each other when their responsibilities are clear.

## Choose one action to compare

Take a consequential operation and draw its full path under each candidate design. Mark where credentials are obtained, permission is checked, an approval is attached, and the outcome is recorded. Then examine an outage and a retry. This makes the tradeoffs tangible before a platform choice spreads across the estate.

A mixed design may be appropriate: local utilities for bounded computation, direct calls to mature services, and a gateway for shared controlled operations. Keep the exception routes visible and test them. The architecture is easier to defend when each connection exists for a stated operational reason.

## Selected primary sources

- [AWS Prescriptive Guidance: Governing and architecting agentic AI at scale](https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/introduction.html)
- [Microsoft Security: Runtime authorization beyond identity](https://techcommunity.microsoft.com/blog/microsoft-security-blog/authorization-and-governance-for-ai-agents-runtime-authorization-beyond-identity/4509161)
- [AWS Well-Architected: Agent portfolio management](https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentops03-bp04.html)