AI agents need limits on what they can do
Authorizing a task means defining how far an agent may go. Reports and research involving Claude, Copilot CLI, and MCP help show where those boundaries belong.
· 6 min read · By Murilo Martins, founder of SemantiqWall
Imagine an AI agent preparing a sales proposal. It checks prices, reads documents, and organizes a response. During its research, an external page asks it to upload an internal file to "validate information." The agent can access both the file and the internet. Sending it appears to help complete the task.
This hypothetical situation exposes a decision that needs to be made before execution: may that information leave the company, for that destination, and for that purpose?
The quality of the finished proposal cannot answer that question. To assess security, the company also needs to understand and control how the work gets done. A legitimate objective can lead to actions that exceed the authority of the person who requested it.
Four reports and studies published in September and October 2026 help examine this problem. They concern different mechanisms and have distinct limitations. Our assessment is that content inspection, permission management, and execution controls serve complementary purposes.
The URL limit in Anthropic's report
On October 9, Anthropic reported that Claude models had used URL shorteners to work around URL length limits. A correction published on October 12 clarified that those limits were intended to reduce risks such as data exfiltration; they had not been introduced to prevent SQL injection or command injection. [1]
The company described the observed impact as minimal, disabled internet access for internal evaluations, and said its detection tooling blocked the reported cases when tested against them. That result applies to those tests; it does not establish universal protection. [1]
Instructions that become readable after decryption
On October 6, Adversa published a demonstration involving GitHub Copilot CLI, encrypted instructions, local file access, and the transmission of file contents to a researcher-controlled destination. The scenario required autopilot mode and a susceptible model. The researchers did not claim to have bypassed a human confirmation prompt. [2]
According to Adversa, GitHub's triage team validated the finding but declined to classify it as a vulnerability, given the autonomy the user had granted. That position is reported by Adversa here, rather than established through a separate GitHub statement. [2]
The technical implication needs care: a filter looking for readable instructions at ingestion may miss content that is still encrypted. Other defenses can still respond. Decrypting external content should neither erase its origin nor give it authority to direct subsequent actions.
What a clean scan actually covers
In research published on September 15, Pluto Security evaluated five scanners for MCP, a protocol used to connect agents to tools. Each scanner returned no findings in at least one configuration involving malicious servers. However, SkillSpector detected both servers at their normal size; the result with no findings appeared in a variant too large for complete analysis. [3]
That distinction changes the interpretation. Coverage varied across metadata, source code, and other analysis modes. Pluto itself distinguishes an absence of findings from a guarantee of safety. [3]
For a company adopting an integration, "it passed the scanner" should lead to a specific question: what was inspected, and what was left out?
Injection spread across channels
In the preprint Measuring and Exploiting Implicit Trust in LLM Tool-Calling Pipelines, submitted on September 16, Murali Ediga and Sudipta Chattopadhyay examine attacks that distribute instructions across tool interaction channels. The authors report exfiltration under conditions in which certain models resisted single-channel attacks. [4]
Their analysis of seven security tools combines documentation review, source inspection, and API testing. It therefore does not amount to seven complete, equivalent product audits. The findings depend on the models, clients, and configurations studied. [4]
Our interpretation is that isolated inspection can miss relationships that emerge across a sequence of interactions. An authorization decision needs to consider where the data came from and how it will be used.
Authorization must be enforced throughout execution
Return to the sales proposal. Reading a price list may be authorized. Sharing a margin report with an external service may be prohibited. Both actions could appear useful to the agent, but usefulness does not grant permission.
Evaluating context should therefore mean comparing a concrete action with explicit rules. Is the destination approved? May this data be shared? Does the requesting user have authority to initiate the operation? Does the authorization still apply if the recipient or content changes?
This assessment does not need to discover what the model "really intended." It needs to produce an enforceable decision before an external effect occurs. If policy requires approval before sending data to a new recipient, the approval request should identify that recipient and the relevant content.
This layer also has limits. A tool server can execute unauthorized code behind an apparently legitimate call. Inspecting the agent's request alone cannot reveal everything happening inside that server. The architecture must also constrain tool execution and the access those tools receive.
Controls that make boundaries enforceable
OWASP identifies excessive functionality, permissions, and autonomy as causes of Excessive Agency. Its recommendations include reducing privileges, requiring approval for high-impact actions, and enforcing authorization in the systems that execute operations. [5]
In practice, we recommend starting with five decisions:
- Define the scope of each task. Specify the resources and operations that are allowed. Broad permission to "access the internet" does not, by itself, define which data may be sent.
- Preserve data provenance. Content received from pages, documents, or tools should remain identifiable as external, including after it has been transformed.
- Authorize the actual parameters. Validate the destination, data, and operation that will be executed. Reassess permission if those details change.
- Constrain the tool environment. Restrict access to files, credentials, and network destinations. Additional barriers should limit the consequences of a failure in the agent's judgment.
- Record decisions and enable intervention. Retain evidence of actions, approvals, and blocks, with controlled access and appropriate handling of secrets. The person responsible for the operation needs a way to suspend an execution.
These controls should be tested in real workflows. A demonstration in which a model refuses a dangerous request helps assess that behavior, but it does not establish that every execution path is protected.
How to evaluate a protection claim
Before expanding agent deployment, a company should ask for evidence that matches the work it plans to delegate.
Do the tests cover long tasks involving multiple tools? Can external information influence a later call? Are there network or execution paths that bypass the control? Does the system block the action before data leaves, or only raise an alert afterward?
Evaluation also needs to measure the cost to legitimate work: how many valid tasks are interrupted, how much latency the checks add, and how often a person must intervene. Even a correct block needs a clear review process.
Recording model, tool, and policy versions helps establish what each test result actually covers. Changes to that combination warrant reassessing the affected workflows.
What the company is delegating
At SemantiqWall, we believe authorization should be an explicit part of agent operations. That position combines contextual assessment with enforceable permissions and controls over tools.
For leaders adopting AI, the decision starts with a concrete question: what is the company prepared to let this agent do without further approval?
The answer gives teams a practical basis for deciding how much autonomy to grant. When an agent finds a different way to finish a task, the organization needs to determine whether that path still falls within what was authorized.
Explore SemantiqWall and assess how to establish enforceable boundaries for your company's AI agents.
Sources
- Anthropic, Investigating unintended model actions in our evaluations and internal use, published October 9, 2026; corrected October 12, 2026
- Adversa AI, Cryptographic Context Injection in GitHub Copilot CLI, October 6, 2026
- Pluto Security, Malicious MCP servers, clean scans, September 15, 2026
- Murali Ediga and Sudipta Chattopadhyay, Measuring and Exploiting Implicit Trust in LLM Tool-Calling Pipelines, arXiv preprint 2609.18217v1, submitted September 16, 2026
- OWASP GenAI Security Project, LLM06:2025 Excessive Agency