Embedded Files
The employee analogy has a limit
A company gives an AI agent a simple assignment: investigate a delayed customer order and prepare a response. The agent opens the order history, reads a supplier email, checks an internal document and discovers a proposed workaround. At what point does gathering information become permission to change the order, disclose a customer record or commit the company to a refund? The model may be capable of doing all three. That does not mean the assignment authorized them.
On October 19, 2026, Microsoft security chief Hayete Gallot described enterprise agents as “agentic insiders” and argued for continuous supervision of their actions. Her post connects this approach to Project Perception, which Microsoft announced in July. The immediate significance is the problem definition: software deployed by an organization can create risk even without a conventional external compromise. Microsoft’s announcement is a statement of its security approach, not independent evidence that every proposed safeguard works across every enterprise deployment.
This is a different question from whether an agent can write good code or finish a difficult benchmark. It concerns what happens after an organization connects intelligence to authority. A useful way to evaluate an agent is to ask two questions separately: how often does it choose the right action, and what prevents a wrong choice from becoming an unacceptable outcome? Better models can improve the first answer. The second also depends on systems outside the model.
Server infrastructure, shown for context rather than as a Microsoft deployment. Photo: Brett Sayles / Pexels. Resized and compressed.
A convincing explanation is not authorization
Ordinary business work contains conflicting signals. A supplier wants a payment processed quickly. A customer says a manager approved an exception. An old document describes a procedure that has since changed. People resolve these situations using authority, context and judgment. An agent encounters them largely as information to interpret, even when some of that information is trying to influence its next action.
OpenAI’s March 2026 discussion of prompt injection emphasizes social engineering: malicious content may persuade an agent through a plausible story rather than a crude instruction to ignore its rules. The company argues for limiting the effects of successful manipulation as well as improving resistance to it. That distinction matters because a beautifully reasoned response can still rest on an unauthorized premise.
Consider the hypothetical order investigation again. A message might say that the customer has already approved sending their purchase history to an outside service. The correct control should not depend entirely on whether the agent finds that claim believable. A business system can require approval from a verified account, limit the fields that may leave the company, and restrict the destination. The email remains evidence to assess, not a new source of permission.
The same distinction applies without an attacker. An agent might infer that updating a record would make its report more accurate, or that contacting a supplier would resolve uncertainty. Both could be helpful. Neither necessarily belongs inside the original assignment. Product design must make that boundary visible, because helpfulness and authority are different properties.
Give the job a smaller action space
OWASP identifies excessive agency as a combination of unnecessary functionality, excessive permissions or too much autonomy. Its examples include giving an agent modification and deletion functions when the task only needs reading. This is a useful starting point because it makes risk a property of the application’s design, rather than treating every failure as something to repair with a stronger instruction.
For the order agent, a narrow tool could retrieve the status of one authorized order and return only the fields needed to answer the customer. A broader tool might expose a general database query interface. A still broader arrangement might provide an interactive account with access to many internal systems. Those designs may use the same model and produce similar demonstrations, yet they create very different opportunities for error.
Narrow interfaces have a cost: someone has to define the work carefully. A team must decide which records matter, which operations are routine, and where exceptions belong. But that work is also an opportunity to simplify the service itself. If an organization cannot explain which actions an employee is allowed to take for a particular task, an agent is unlikely to make the ambiguity disappear.
Time is another boundary worth designing explicitly. An agent that investigates one delayed order today should not automatically retain the same access next month. A job can have an expiry, and a recurring service can have an owner responsible for renewing or withdrawing its scope. That makes access a maintained business decision rather than an accidental inheritance from an old experiment.
A practical starting design is therefore a specific job with a specific owner, a bounded set of tools and a clear stopping point. Add capabilities when a demonstrated workflow needs them. Avoid granting broad access merely because it makes a demo smoother. Unused power is still power, and it becomes part of the system that must be tested, monitored and eventually revoked.
The boundary has to survive a bad decision
NIST’s zero-trust architecture guidance predates the current agent boom. It rejects implicit trust based solely on network location or ownership and puts authentication and authorization around access to resources. Applied to agents, the lesson is straightforward: being our agent, running in our environment, is not enough to establish permission for every resource it can reach.
Anthropic’s engineering account of containment gives a concrete warning about implementation. In one disclosed case, an allowed API domain could still be used to upload data to an attacker-controlled account. The destination passed the domain check, but the intended security boundary did not hold. Anthropic describes adding checks tied to the provisioned session token. The broader implication is that a trusted service name does not identify every permitted operation or recipient within that service.
For an enterprise buyer, that turns a vague question about sandboxing into more useful questions. Which identity performs the action? Which customer record is in scope? Can the agent choose a different recipient? Can it create a new credential, change its own permissions or invoke a second tool with broader access? A boundary that looks strong in one interface may be bypassed through an overlooked path.
No architecture eliminates every security failure. Policies can be wrong, enforcement code can contain bugs, and administrators can grant too much access. The goal is to create independently enforced constraints and then test the actual paths through them. A model’s promise to stay within its assignment should supplement those controls, not be the only thing standing between a mistaken interpretation and a consequential action.
Supervision should change what happens next
Microsoft’s October 19 post advocates guardian agents that evaluate activity before actions occur, alongside controls across identity, data, endpoints, networks and runtime. That is a useful direction to examine, but the presence of another model does not by itself create an independent security guarantee. A supervisor needs reliable information, a defined policy and a way to block execution.
In our hypothetical workflow, a supervisor could notice that an order-status task is about to send a file outside the organization. The important outcome is not a warning buried in a dashboard after the upload. It is an intervention at the point where the upload can still be stopped, with enough context for an authorized person to make a decision.
Human review needs similar care. An approval that says only “Allow tool use?” asks the person to guess at the consequence. A useful request identifies the recipient, the information leaving the system, the purpose and the scope of the approval. If the recipient or contents change afterward, the earlier decision should not silently stretch to cover the new action.
This suggests a division of work rather than a universal approval ritual. Low-risk, reversible operations can run within a preapproved scope. Consequential exceptions can receive focused review. Non-negotiable boundaries can remain blocked. The objective is not to maximize the number of confirmation dialogs. It is to ensure that a person’s attention is spent on decisions for which their judgment can actually change the outcome.
Test the business process, including the aftermath
A realistic evaluation should include ordinary success cases, ambiguous requests and attempts to push the agent beyond its assignment. For the order workflow, a team could test a forged approval in an email, a legitimate request concerning the wrong customer, a stale internal procedure and an unavailable verification service. These are proposed test cases, not results from a system we have evaluated.
Measure more than whether the final answer sounds correct. Did the agent access an unrelated record? Did it attempt an unauthorized update? Was that attempt blocked before execution? Could it finish the legitimate portion of the task afterward? A system that refuses everything may be safe in a narrow test while being unusable in the business. A system that completes everything may be hiding unacceptable shortcuts.
Recovery belongs in the same exercise. If a tool times out after submitting a change, retrying blindly can duplicate the operation. The workflow should be able to determine whether the first action happened. If a mistake occurs, the operator needs an action history and a practical way to stop further work, revoke access and correct reversible changes. Some disclosures cannot be undone, which makes prevention at those boundaries especially important.
Teams also need a way to distinguish a blocked attempt from a completed incident. Counting every denied action as a breach exaggerates risk; counting only visible damage can hide repeated pressure on a weak control. Keeping those categories separate helps operators identify where a model needs improvement and where the application’s enforcement is already doing its job. It also prevents a favorable completion rate from concealing interventions that required substantial human work.
Finally, test changes to the system itself. A new connector, a wider account role or a revised tool can alter the consequences of an unchanged model. Security evaluation should follow the deployed combination of model, permissions and business process. A past benchmark result is useful evidence about a particular test, not a permanent approval of everything attached later.
The commercial prize is dependable delegation
For businesses, the real benefit of agents is the ability to hand over work without continuously reconstructing what happened. That requires a service definition: what the agent may decide, what it must escalate, what evidence it retains and who owns the result. The work can then become easier to price and manage, because the organization knows what responsibility it has delegated.
This also changes how to compare products. A dramatic demonstration may show an agent crossing many applications without interruption. A production evaluation should ask whether that freedom is necessary, whether it can be reduced, and whether the remaining exceptions are manageable. The fastest agent is not automatically the least expensive service once review, incident handling and customer trust are included.
The emerging security discussion is therefore part of the economics of autonomy. A narrowly authorized agent that reliably completes a meaningful business process can be more valuable than a broadly empowered assistant that demands constant vigilance. More capable models expand the set of tasks worth attempting. Carefully engineered boundaries help determine which of those tasks an organization can responsibly put into daily operation.
Google Sites
Report abuse