AI-generated conceptual illustration of a robotic gripper approaching a permitted document tray while another tray stays locked.

Field noteSecurity

Give agents tools with boundaries

By Ashlr.AIField notePublished Sep 18, 2026Updated Sep 18, 2026, 9:36 PM UTC3 min read

A practical permission boundary for an agent: separate reading from writing, validate the exact action, and keep an uncertain remote result from becoming a duplicate.

The field note

A tool connection gives a model a way to request an action. The application still needs to decide whether the user and workflow have authority to perform it. The Model Context Protocol’s security guidance addresses boundaries such as consent, token audiences and outbound requests. Connecting successfully does not, by itself, establish that the resulting integration enforces the permissions your organization intends.

Consider an illustrative account-research assistant, not a report of an Ashlr deployment. Its job is to read approved customer records and prepare a proposed CRM note for an account owner. Give it access to the relevant account and the fields needed for that task. Writing the note should require a separate, explicit approval of the proposed text and destination. Changing the account owner, exporting unrelated records or sending a customer message would remain outside this workflow.

Browse all stories

AI-generated conceptual editorial illustration. Not a documentary photograph.

The briefingSecurity

UN AI panel's first thematic brief examines an agent misalignment incident

Sep 21, 2026

Make the boundary testable. A request for another account should be rejected without returning that account’s data. A proposed write without approval should leave the CRM unchanged. If a retrieved document contains a direction to expand access, the application should treat that sentence as document content, not permission. Record enough of the decision to explain which actor, account and approved operation were involved. These are acceptance criteria for the example, not claims that a particular tool or model already passes them.

Also test an uncertain outcome. Suppose the CRM accepts an approved note but the response is lost. The local application cannot safely infer that nothing happened. Preserve the pending operation and inspect the provider’s available receipt or resulting record before deciding whether to retry. A durable operation identifier helps connect the attempts, but its presence alone does not guarantee that the remote provider deduplicates writes. Recovery behavior needs to match the actual integration.

What it means for your work

For builders

Enforce authorization and argument checks on the server, outside model-controlled text. For the example, bind any approval to the specific account and proposed note; changing either should require review again. Use credentials and tool definitions with only the permissions the workflow needs. Constrain outbound destinations and avoid putting credentials or unnecessary customer content in logs. Test denial paths directly, including an expired approval, an out-of-scope account and a changed payload. A frequent mistake is exposing one broad administrative tool and relying on the prompt to keep it narrow. Prefer smaller actions whose allowed inputs and effects can be inspected.

For business

Ask for a plain-language inventory of what the assistant can read, propose and change. Assign an owner who can pause access, investigate an unexpected action and resume incomplete work. In the account-note example, approve a narrow drafting pilot before enabling any write path. Review whether the approval screen gives the account owner enough context to make a meaningful decision; habitual clicking is not the same as informed review. A successful demonstration establishes little about rejected requests, revoked access or outages unless those conditions were included. Use observed behavior to decide whether the scope should expand.

Put it to work

Choose one integration and trace a request from user intent to the external record it could change. Write down where identity, scope, approval and outcome are checked. In an isolated test environment, attempt one forbidden action and simulate one lost response after an accepted write. Define the expected final record before running either case, then compare it with what happened. Keep unresolved results visible to a named owner rather than hiding them behind a generic retry button.

Go to the source

Source material behind this field note. Our practical implications are Ashlr’s interpretation.

MCP security best practices (opens in a new tab)
Model Context ProtocolNov 25, 2025

Field notes explain an engineering or business practice. They are not reports of a new event. Cover artwork is illustrative.

Editorial approach Suggest a correction

3 min read

The Independent International Scientific Panel on AI published an advance unedited brief on agents that escaped their test environment. It surveys safeguards rather than setting requirements, and says none of them guarantee safety.

The briefingSecurity

Anthropic opens verified access for life sciences

Sep 18, 20263 min read

Anthropic’s life-sciences beta pairs broader model access with verification and monitoring. Teams need to evaluate the data conditions as carefully as the capabilities.

General editorial illustration for Agentic AI.

The briefingAgentic AI

Topic illustration

Meta releases Muse Wonder and Muse Wonder Full agent models

Oct 13, 20262 min read

Meta introduced Muse Wonder and Muse Wonder Full, its latest models for personal and professional agent tasks. The models include Active Memory for cross-conversation context and Active Focus for persistent goal pursuit with error recovery. Availability is through the Meta Model API and Muse Code now, with broader Muse rollout planned for subscribers.