The moment an agent can call an external tool, it stops being only a text interface. It can read a customer record, create a ticket, deploy code, query a data warehouse, or send a message under a company's name. The technical question of whether the model can form the right API request is usually the easy part.

The harder questions are operational. Who granted this reach? Which exact operations are allowed? Where does the credential live? Can a person inspect a sensitive action before it happens? If something goes wrong, can the team tell which agent and which task caused it?

Those questions make tools security boundaries.

A connector is not a bag of secrets

The early pattern for agent integrations is understandable: place API keys in an environment file, expose a few wrappers, and instruct the model to be careful. It is fast, and it demonstrates value. It also leaves the runtime with a broad credential that can be exposed through logs, subprocesses, file reads, or prompt injection.

A production design should separate the agent's request from the credential used to fulfill it. The agent can ask to use a connector. A trusted control plane checks the task identity and policy, resolves a scoped credential outside the model environment, performs or brokers the request, records the result, and returns only what the task needs.

This arrangement changes more than secret handling. It creates a place to enforce policy and produce a meaningful audit trail.

Reads, writes, and consequences

"Can use Slack" is not a useful permission. Reading a project channel, drafting a message, posting it, deleting history, and changing workspace settings all have different consequences. The same is true for source control, cloud infrastructure, billing, and internal data systems.

An agent policy should reflect those differences. It might allow routine reads, permit a branch write inside an isolated environment, require approval before external sends, and block destructive operations altogether. The important thing is not the exact set of labels. It is that the rule is visible, reviewable, and enforced outside the model.

This also helps teams make sensible tradeoffs. A support assistant can summarize a ticket without being able to issue a refund. An engineering agent can run tests and open a change request without merging to the shared branch. A research assistant can retrieve papers without having the ability to alter a source dataset. Capability remains useful because authority is scoped.

Treat every call as attributable

When a shared service account performs all agent actions, downstream logs often show only that the account made a request. The missing context is precisely what a security review needs: which person initiated the work, which agent carried it out, which project or tenant it belonged to, which policy applied, and whether a human approved the operation.

A well-designed runtime carries that context through the call. It does not need to expose private reasoning, but it should preserve the identity and decision path that made the action legitimate. That record supports incident response, revocation, billing, and ordinary debugging.

It also creates a better user experience. Rather than receiving a vague warning that an agent wants to "use a tool," a person can see that a task is requesting permission to publish a specific preview to a specific environment, using a limited grant, because a review needs a visible artifact. The difference is clarity.

Prompt injection does not respect intent

Tool access becomes particularly sensitive when an agent reads untrusted content. A document, webpage, issue, or email can contain instructions that conflict with the user's intent. A model may not be able to perfectly distinguish content from commands, especially when the request is complex and the content is persuasive.

The answer is not a stronger sentence in the system prompt. The answer is containment. The tool layer should limit what the task can do, the credentials it can reach, and the operations that can leave the workspace. Risky actions should require an explicit policy decision or human approval. The system should assume that any text an agent reads may be adversarial and should not let that text expand the agent's authority.

This is why the boundary needs to be structural. A model can make an imperfect judgment; the runtime should still prevent that judgment from becoming unrestricted access.

Security should make useful work easier to trust

Security controls are often described only as restrictions. In an agent system, good controls can make useful work easier to delegate. When a person knows that an agent has only the connector grants needed for a task, that external sends require approval, and that every action is attributable, they can hand it more meaningful work with less anxiety.

The goal is not to create a maze of confirmations. It is to make the real boundary visible: what the agent can observe, what it can change, what it can propose, and what must remain a human decision.

Tools are where models meet the world. That meeting deserves the same care as any other production security boundary.