The Permission Problem Is Becoming the Main AI Problem
AI agents are moving from systems that generate information to systems that can take actions. In September 2026, that distinction became harder to ignore as Meta rolled out Muse, a consumer-facing personal agent that can browse websites, fill forms, send messages, book services, and make purchases. Meta says Muse can continue working after a user closes the application and return for approval when an action requires it. The company built the system around a dedicated cloud virtual machine, its own browser, and a separate security layer intended to control what reaches the internet.
The significance is not simply that another AI assistant can click buttons. The more consequential change is the widening of the agent’s authority. A conventional chatbot generally receives information and returns an answer. An agent can receive a goal, retrieve information from multiple systems, decide which tools to use, execute several steps, and potentially create an external consequence. That consequence could be a calendar change, an email, a software deployment, a financial transaction, or a purchase.
This creates a security question that is different from whether an AI model produces an incorrect paragraph: what should the system be allowed to do when the model is wrong, manipulated, or operating outside the user’s original intent?
That question is now being addressed by developers, security researchers, and standards organizations at the same time that companies are expanding agent capabilities. NIST has been examining identity and authorization for software agents, while OWASP has developed an Agentic Applications Top 10 and, in September, introduced an Agent Control Standard intended to make agent behavior more inspectable and controllable at runtime.
What Changed in 2026
The important development is not one particular product launch. It is the convergence of several technologies that make agents substantially more capable of acting across boundaries. Modern agents can combine a reasoning model with browsers, APIs, application connectors, files, shell commands, databases, and payment systems. Google’s 2026 updates, for example, describe computer-use capabilities that allow agents to see, reason about, and act across desktop, mobile, and browser environments. OpenAI has similarly expanded its agent tooling around controlled sandboxes, computer interaction, and long-running tasks.
That architecture creates a loop roughly like this:
Goal → model reasoning → tool selection → external action → new information → further reasoning → additional action.
The model is therefore no longer the complete application. It is one component inside a larger system containing credentials, tools, permissions, memory, network connections, and policy controls. That distinction matters because restricting the model alone cannot necessarily restrict the whole agent. OpenAI’s own security guidance for agent environments recommends isolated workloads, restricted network access, and separated credentials because agent-generated code can otherwise reach the files, credentials, and network resources available to its environment.
The practical security boundary is consequently shifting from “What can the model say?” toward “What can the agent actually reach and change?”
Why Access Changes the Risk Model
Giving an AI access to an email account does not merely give it more information. It gives the system a potential communication channel. Giving it calendar access can allow it to alter schedules. Giving it cloud storage access can expose documents. Giving it a payment method introduces financial consequences. The risk compounds when these permissions are combined.
Consider an apparently harmless task such as asking an agent to organize a trip. The agent may need access to email to find travel details, a browser to compare options, a calendar to identify available dates, and perhaps a payment method to complete a reservation. Each individual permission may appear reasonable. Together, they create a system capable of making consequential decisions with relatively little human intervention.
This is one reason NIST’s work on agent identity and authorization is significant. Its 2026 concept paper specifically identifies identification, authorization, auditing, non-repudiation, and prompt-injection controls as areas requiring attention. NIST later said that organizations need to apply identity standards and best practices to agents because the scale and range of autonomous actions can increase substantially.
The underlying problem resembles traditional cybersecurity, but with an important difference: an agent is not simply a static program following a fixed sequence of commands. It can interpret information, select tools, and adapt its behavior as circumstances change. That means permission systems need to account not only for who has access but also for what the agent is attempting to do with that access.
The Prompt-Injection Problem Makes the Boundary Harder
One of the most difficult issues is prompt injection. A web page, email, document, or other piece of data can contain instructions that are intended for the AI rather than the human. If an agent treats those instructions as authoritative, information retrieved during an otherwise legitimate task can influence the agent’s subsequent behavior.
OpenAI’s current ChatGPT agent documentation gives a concrete example: an agent asked to research a restaurant could encounter malicious content instructing it to retrieve a password-reset code from email and send it elsewhere. The documentation describes confirmation mechanisms, prompt-injection monitoring, and other safeguards, while also warning that these measures do not eliminate the risk.
This creates an unusual security boundary. Traditional software generally distinguishes between instructions from the application and data returned by an external website. An AI agent interprets both through a language model, which means untrusted content can sometimes resemble a legitimate instruction. The safest architecture, therefore, cannot depend entirely on the model recognizing malicious instructions. Technical restrictions need to exist outside the model as well. That is the logic behind sandboxing, network allowlists, credential isolation, approval gates, and runtime monitoring. If a model is persuaded to perform an action it should not perform, the surrounding system should ideally make that action impossible or require explicit authorization.
Meta’s Muse Shows How These Controls Are Being Built
Meta’s September launch provides a useful example because the company describes several layers rather than relying on a single safety filter. Muse runs inside what Meta calls a Muse Secure VM, a dedicated virtual machine containing the agent, data, and browser. Meta says a separate “Sentinel” agent controls internet access and can require user permission. The company also says Muse does not directly see passwords or payment methods stored in its secure system.
Meta also gives users controls over connected applications. For example, the company says users can decide whether Muse can read email only or can also send messages on their behalf. Sensitive actions such as sending an email or making a purchase are designed to require confirmation, according to Meta.
The approach is important because it treats the agent as a privileged computing environment rather than merely a chatbot. There is, however, an important distinction between a company’s described architecture and independent evidence that the architecture works under every realistic attack. Meta’s security claims describe the controls it has implemented; they do not establish that every possible prompt injection, credential, browser, or integration attack has been eliminated. That distinction applies across the industry.
The Browser Is Becoming a New Security Boundary
Browser-based agents are particularly complicated because websites were designed for human users, not autonomous software that can interpret pages and make decisions. A University of Washington study published in June 2026 examined seven agentic AI browsers and found that four created ways to bypass the browser’s same-origin security model. The researchers also demonstrated a proof-of-concept attack against one browser.
The same-origin policy is a foundational web security mechanism that prevents one website from freely reading information belonging to another website. Agentic browsers can complicate that model because the AI layer may intentionally coordinate information across many tabs and services on behalf of the user.
This does not mean every AI browser is inherently insecure. It does mean that granting an agent broad browser control can undermine assumptions on which conventional web security has been built. The distinction is increasingly important as agents move from reading pages to submitting forms and completing transactions.
The Commerce Fight Reveals a Second Kind of Limit
The question of access is not only about cybersecurity. It is also becoming a question of who gets to decide whether an agent may interact with a service. Meta’s Muse launched with the ability to shop on behalf of users, using Stripe’s Link system for checkout. Meta said its architecture keeps payment credentials hidden from the agent and described a one-time-use card mechanism.
But Amazon subsequently blocked Muse from shopping on Amazon.com. Reporting from TechCrunch and GeekWire said Amazon’s message characterized continued access by an unauthorized AI agent as a violation of its Conditions of Use. GeekWire reported that Amazon objected to Muse accessing the site without prior agreement and to how the agent identified itself and handled credentials.
At almost the same time, Shopify took the opposite approach. Shopify announced a partnership allowing Muse to use Shop Pay for agentic checkout across Shopify stores. The contrast illustrates an unresolved question in agentic computing: should an AI agent be treated like a user, like an application, or as a separate category of software identity?
Traditional websites generally assume that a person is browsing through a browser, while automated software is governed through APIs, authentication credentials, and terms of service. Agents blur that distinction. They may act because a person instructed them to do so, but the actual browser activity is performed by software that can make intermediate decisions. That makes agent identity increasingly important.
Why Agent Identity Matters
A useful way to think about an AI agent is as a new kind of non-human identity. A company already knows how to give a human employee access to a database, revoke that access, and log activity. It can also give an application a service account with narrowly defined permissions.
Agents complicate both models because their behavior can change according to context. NIST’s work explicitly examines how agents should be identified, authorized, and audited. Its August 2026 cybersecurity guidance argues that organizations need a stronger identity foundation as agents gain the ability to perform tasks across systems. OWASP’s 2026 security framework identifies risks including agent goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, insecure inter-agent communication, cascading failures, and rogue-agent behavior.
These categories point toward a more granular permission model. Instead of giving an agent blanket access to an application, a system could distinguish between:
| Permission level | Example | Human approval |
|---|---|---|
| Read | Check a calendar or retrieve a document | Usually unnecessary |
| Prepare | Draft an email or build a shopping cart. | Often unnecessary |
| Modify | Change a calendar entry or edit a file. | Context-dependent |
| Communicate | Send an external message. | Often appropriate |
| Financial | Purchase goods or transfer money. | Strong approval recommended |
| Privileged | Deploy code or alter security settings. | High-assurance authorization |
The exact boundaries will vary by application, but the principle is straightforward: permission should reflect consequence, not merely technical capability.
Runtime Controls May Matter More Than Static Permissions
A particularly important development is the move toward runtime control. OWASP’s Agent Control Standard, introduced in September 2026, argues that enterprise agents should be inspectable, traceable, and instrumentable, with mechanisms for controlling behavior while the agent is operating. Its approach is intended to provide portable controls across different agent frameworks and environments.
That direction addresses a weakness in conventional access control. A permission granted at the beginning of a task may become inappropriate later. Suppose an agent is allowed to read a public website and then encounters a page requesting access to a user’s private email. A static permission system may know that the agent has email access, but a runtime policy can ask a more useful question: is this particular action consistent with the task the user authorized?
That is much closer to behavioral governance. Akamai has described the same shift as moving beyond traditional identity management toward governance of autonomous, non-human entities. Its September 2026 security report argues that organizations need to consider what agents are allowed to do after gaining access, rather than only which systems they can reach.
The Industry Is Still Working Out the Right Model
There is no single agreed permission architecture yet. Some systems emphasize sandboxing: give the agent a contained environment and tightly restrict its network access. Others emphasize application connectors and APIs, which can provide more structured permissions than unrestricted browser automation. Still others combine browser access with confirmation gates and specialized credential storage.
The difference is important. An API can expose a specific operation such as “create calendar event” without giving an agent the ability to manipulate the entire calendar application. A browser gives an agent much broader flexibility, but that flexibility also increases the number of unexpected interactions it can encounter.
For developers, the trade-off is therefore between capability and containment. The more narrowly an agent is constrained, the easier it is to reason about what it can do. But excessive restrictions can also defeat the purpose of an agent, particularly for tasks that involve unfamiliar websites or long sequences of actions. That tension is unlikely to disappear simply because better models are released.
What Is Confirmed—and What Is Still Uncertain?
Several developments are now clear. Consumer agents are gaining access to browsers, applications, data, and payment mechanisms. Major AI companies are building technical controls around those capabilities rather than treating them as ordinary chatbot features. Standards organizations are developing frameworks for agent identity, authorization, monitoring, and runtime control.
It is also clear that companies disagree about how open these systems should be. Meta’s Muse is designed to work across external services; Amazon has blocked that agent from its marketplace, while Shopify has announced infrastructure intended to support it.
What remains less certain is how reliably today’s controls perform against adversarial conditions at a large scale. There is no universal test that proves an agent is safe simply because it has a sandbox, a confirmation dialog, or a separate security component. Agents interact with changing websites, third-party applications, dynamic content, and increasingly complex chains of tools. Security therefore depends on the complete system rather than the language model alone.
There is also an unresolved question about responsibility. If a user authorizes an agent to make a purchase, the agent misinterprets a webpage and buys the wrong item; responsibility may be straightforward in some cases and much less obvious in others. The same problem becomes more serious when agents send messages, modify business systems, or execute code.
What Limits Make Sense?
The emerging evidence points toward layered limits rather than one universal cutoff. An agent does not necessarily need human approval for every action. Requiring confirmation every few seconds would make automation almost useless. But consequential actions should not be treated the same way as harmless information retrieval. A sensible architecture can separate low-risk actions from actions that create durable consequences. Read-only access can often be broader. Writing, deleting, publishing, spending money, changing permissions, or communicating externally can require progressively stronger authorization.
The agent should also have a distinct identity, limited credentials, an auditable activity trail, and technical boundaries that remain effective even when the model makes a mistake. Network access, secrets, and sensitive data should be isolated rather than exposed simply because the agent might eventually need them.
For users, the practical principle is equally simple: give an agent only the access required for the task, and avoid treating a general instruction as unlimited authority. OpenAI’s current agent guidance similarly recommends enabling only necessary apps, avoiding vague instructions such as asking an agent to “handle everything,” reviewing permissions, and stopping a task when something suspicious occurs. The technology is moving toward agents that can do more without waiting for a person at every step. The security architecture now has to mature at the same pace.
The Bigger Shift Is From Model Safety to System Control
The debate over AI-agent limits is sometimes framed as a question of whether models can be trusted. That is too narrow. A capable model can still be deployed safely if its environment is tightly controlled. Conversely, a model that performs well in evaluations can become risky when given broad credentials, unrestricted network access, and authority to affect external systems. The important unit of analysis is therefore the agentic system: model, tools, identity, memory, browser, credentials, network, policies, and human approvals working together.
As of September 27, 2026, the direction is clear even though the final architecture is not. AI agents are receiving broader access to the digital systems people use every day. Companies are responding with sandboxes, permission controls, confirmation gates, dedicated credentials, monitoring, and emerging standards. NIST and OWASP are treating identity and runtime control as central technical problems, while real-world deployments are already exposing disagreements over who should be allowed to access which services.
What remains to be established is whether these layers can keep pace with increasingly autonomous behavior. The central question is no longer simply what an AI model can generate. It is what an agent can reach, change, authorize, and cause to happen—and whether the system around it can reliably stop the actions that fall outside the authority a human actually intended to grant.