SecurityField note
Give agents tools with boundaries
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.
Loading Ashlr Brief
SecuritySecurityField note
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.
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.
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.
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.
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.
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.
Source material behind this field note. Our practical implications are Ashlr’s interpretation.
Field notes explain an engineering or business practice. They are not reports of a new event. Cover artwork is illustrative.
Anthropic's Claude Code v2.1.311 introduces CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS, removing the final guardrails on commands like rm. The change follows the earlier --dangerously-skip-permissions flag and bypassPermissions mode.
SecurityThe briefing
AI-generated illustration
AWS made its Continuum agent generally available. The service finds, validates, and proposes fixes for code vulnerabilities in repositories while checking the AWS environment.
SecurityThe briefing
AI-generated illustration
Nothing merged in Ashlr's public repositories on October 21. Here is the idea behind a phrase that runs through recent pull requests: value-free reports.