Before an AI agent gets tools, define its authority

An AI assistant that drafts an answer and an agent that can change a business system require different controls. The first can mislead a reader. The second can also send a message, update a record, expose information, or spend money. Connecting a tool turns a language problem into an operational responsibility.

The right starting question is not how many systems an agent can reach. It is what authority the workflow actually needs. An assistant preparing an account review may need approved metrics and documents, but no permission to change prices or contact customers. A service assistant might prepare a correction while leaving approval and execution with an accountable person.

This article focuses on that access boundary. It complements the broader operating model in From chatbot to governed agent: useful automation needs clear permissions at the point where actions happen, not only good intentions in a prompt.

A standard connection is not a trust decision

The Model Context Protocol, or MCP, provides a standard way for compatible AI applications to connect with tools and context. Standardization can reduce integration friction. It does not mean every server, tool, or response is trustworthy, or that a connected agent should receive all of a user's authority.

The MCP security guidance addresses issues including token audience validation, scope minimization, consent, and unsafe credential forwarding. In particular, it forbids accepting and passing through tokens that were not issued for the MCP server. These are implementation responsibilities, not properties that appear automatically because a connector uses the protocol.

Business owners do not need to inspect every authorization detail. They should expect the implementation team to explain who the agent acts for, which records it can reach, what actions it can perform, and how that access can be withdrawn.

Define tools around business tasks

A narrow tool is easier to reason about than an unrestricted interface. "Read approved inventory exceptions for this account" has a clearer boundary than "run any database query." "Prepare a draft service response" has a clearer effect than "call any customer API."

For each tool, document its purpose, required inputs, permitted scope, returned information, side effects, and failure behavior. Validate identifiers and values in the application or service. The model should not be able to choose another tenant simply by supplying a different account identifier.

Avoid bundling unrelated authority into one convenience tool. Reading a record, proposing a change, and applying that change can be separate operations. That separation makes it possible to evaluate the recommendation without also granting execution permission. It also produces a clearer record for review and incident investigation.

Keep identity attached to the request

The system needs to know the initiating user and the effective authority used for the request. A shared service account with broad access can accidentally erase the distinctions between users, departments, or customers. Where service identities are necessary, constrain them and enforce the requesting user's authorized scope explicitly.

Check permissions when data is retrieved and when an action is executed. Access may change between those moments. Do not assume a result cached for one user is suitable for another. Derived summaries and search results can contain restricted information even when they no longer resemble the original source record.

Make revocation practical. If a user leaves a team or a connector is suspended, the organization should know which credentials, sessions, and cached outputs are affected. A documented access boundary is incomplete if nobody can promptly reduce it.

Treat retrieved content as evidence, not authority

A document, website, or tool response may contain text that tries to redirect the assistant. That text can look like a business instruction while actually requesting unrelated disclosure or a different action. OWASP identifies direct and indirect prompt injection as risks for language-model applications.

The defense is not simply a longer instruction telling the model to be careful. Keep untrusted content separate from trusted operating rules, and ensure that available tools cannot exceed the authorized workflow even if the model follows a misleading instruction. Use validation, restricted outputs, and approval requirements as independent controls.

For example, a supplier document being summarized should not be able to authorize the assistant to send internal customer records to an address found in that document. The legitimate task is to interpret the supplied evidence. New authority must come from the authorized user and system policy, not from the material being read.

Make approval specific and understandable

An approval should identify what will happen: the target record or recipient, the proposed change, material values, and important consequences. "Allow the agent to continue" is too vague for a consequential action. Reviewers need enough context to recognize a mistake without reconstructing the entire conversation.

Tie the approval to the version of the action being executed. If a draft message, recipient, or amount changes afterward, the earlier approval should not silently cover it. Consider expiry and changed business state as well. An inventory recommendation approved yesterday may no longer fit today's availability.

Do not overload people with confirmations for every harmless step. Reserve meaningful gates for the actions that require judgment, while controlling low-risk operations through narrow permissions and tested limits. Too many repetitive prompts can make the important approval less effective.

Test an ordinary workflow and an interrupted one

Consider an illustrative account-review assistant. It retrieves approved sales and inventory measures, prepares a summary, and drafts a follow-up task for the account owner. It cannot send an external email or change the customer's commercial terms. That boundary gives the assistant useful work without implying authority it does not need.

Test a user requesting another account's data, a missing source, a contradictory document, and an attempted instruction hidden in a retrieved record. Then interrupt the workflow after a task is submitted but before the response arrives. A timeout does not prove the task failed; a blind retry might create a duplicate.

Use request identifiers and state checks where the receiving system supports them. Make uncertain outcomes visible for review. Some actions cannot be reversed reliably, so recovery may require a correction process rather than a rollback button. Those limits should be understood before the workflow goes live.

Keep useful evidence without creating a new exposure

The operating record should show the initiating identity, tool version, authorized scope, validated action, approval reference, result, and relevant timestamps. Capture enough evidence to investigate a decision without unnecessarily retaining passwords, tokens, personal records, or complete confidential prompts.

Apply access and retention controls to the logs themselves. A monitoring system can become an unintended second copy of sensitive data if every tool response is stored indefinitely. Redaction should preserve useful context, such as record identifiers and status, while avoiding secret values.

Monitor unusual tool-call volume, repeated failures, approval bypass attempts, and access-denied events. Define who can pause a connector or workflow and how users continue their work during the pause. An alert is useful only when someone knows the next action.

Use authority as a release criterion

Before launch, ask the business and technical owners to describe the same boundary in their own language. They should agree on the permitted task, data scope, approval points, failure handling, and accountable owner. Test those claims rather than relying on a connector's feature list.

Expand authority only for a demonstrated business need and with appropriate evidence. More tools are not inherently more value. A small set of well-designed integrations can be more useful than a broad assistant that nobody can confidently supervise.

VeriVal helps teams design governed AI workflows, trusted analytical context, and controlled tool integrations. If an assistant is ready to move beyond answers into action, start a conversation.

References

• Model Context Protocol: security best practices
• OWASP: prompt injection
• NIST: AI Risk Management Framework