Collaboration platforms spent the last two years adding assistants that summarise, draft and answer questions about the documents they already hold. That was a feature. What is arriving now is different in kind: software inside the workspace that is given a task, decides on a sequence of steps, and carries them out across the tools it can reach. The demonstrations are good. The governance question underneath them has barely been asked, and it is not a security question in the conventional sense.
An assistant that answers a question is bounded by what you asked. An agent that completes a task is bounded by what it can reach, and in most workspaces that is everything the person who invoked it can see
That sentence describes the entire design problem, and it is worth thinking through before the deployment rather than after.
What the workspace platforms are actually shipping
Three capabilities, arriving at slightly different speeds. Task execution across tools. Create the page, update the tracker, message the three people, schedule the review. Genuinely useful, and the value is the chain rather than any single step. Standing automations. An agent that watches a channel or a database and acts when a condition is met, without anyone invoking it. This is the one to be careful with, because nobody is present at the moment of action. Retrieval that acts. Finding the relevant material and then doing something with it, which combines two capabilities whose failure modes compound. All three inherit the permissions of a human principal, which is the sensible default and also the source of the difficulty: people's permissions are broad, stale, and were granted on the assumption that a human would only look at what they needed.
The four design decisions worth making before rollout
Scope the agent narrower than the person. A task agent should reach the tools and spaces its task requires, not everything its invoker can open. Most platforms now allow this and almost no one configures it. Distinguish reversible from irreversible actions. Creating a draft, updating an internal page, adding a comment — all recoverable. Sending an external message, sharing a document outside the organisation, deleting content, changing permissions — not. Require confirmation on the second category and let the first run. Decide about standing automations deliberately. An agent triggered by an event acts when nobody is watching. Give each one a named owner, a written purpose and a review date, or it becomes the workspace equivalent of a forgotten service account. Keep the person in the record. Every action should be attributable to the human on whose behalf it ran, visibly, in the place where the action appears. Colleagues need to know whether a message was written by a person.
The risk nobody puts in the deployment plan
Agents read content, and content can contain instructions. A page, a comment, a forwarded email or a shared document can carry text designed to redirect an agent that reads it. This is not hypothetical and it does not require sophistication — the mitigation is not detection but constraint: an agent that cannot send external messages cannot be induced to send one, regardless of what it reads. That is why scoping matters more than filtering. Narrow the capability and the manipulation has nowhere to land.
| Boundary | Check before enabling |
|---|---|
| Invoked task | Limit tools and spaces to the task, not the person's whole access |
| Recoverable work | Keep drafts and internal edits attributable and logged |
| External or sensitive action | Require explicit confirmation for sends, sharing, deletion or permission changes |
| Standing trigger | Record its purpose, accountable owner and review date |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Agentic Workspace Design
- Scope agent permissions narrower than the invoking person's.
- Split actions into reversible and irreversible; confirm the second.
- Give every standing automation an owner and a review date.
- Make the human principal visible wherever the action lands.
- Prohibit external sends unless explicitly required and confirmed.
- Run a pilot in one team before enabling workspace-wide.
- Log agent actions where administrators can actually search them.
- Revisit sharing hygiene first; agents inherit your existing mess.
The Regional Angle
The first consideration is that workspace permissions in regional organisations are frequently structured around entities rather than roles, and agents expose that immediately. A group with operating companies across several Gulf states commonly separates access by giving people membership of entity-specific spaces, with a handful of group finance and executive staff holding access to all of them. An agent invoked by one of those people inherits cross-entity reach, and a task that seems innocuous — summarise the quarter, chase the outstanding approvals — can pull content across legal entities whose data ought not to be commingled. Scope group-level users' agents to a single entity by default and require a deliberate choice to widen. The second concerns language, and it is a practical governance problem rather than a convenience one. Regional workspaces run in English and Arabic, often mixed within a single thread, and correspondence with government bodies and many counterparties is Arabic-first. Agents now handle both competently enough to draft outbound text, which is exactly where the risk sits: a drafted Arabic reply to a ministry or a bank carries formal register conventions and a legal weight that a fluent but non-native generation may not respect. Keep external Arabic correspondence in the confirm-before-send category specifically, even where you have relaxed the rule for internal drafting. The third is about the composition of regional teams and what agents do to informal escalation. Gulf organisations typically run with a high proportion of staff who are relatively new to the company, rotating on multi-year postings, and who rely heavily on asking a colleague who has been there longer. An agent that answers those questions from workspace content is genuinely valuable in that setting — it compresses the onboarding penalty that high turnover imposes. But it also removes the conversation in which the experienced colleague would have said that the written process is not what actually happens. Where the documented answer and the practised answer differ, the agent will give the documented one confidently, so it is worth fixing the documentation in the few processes where that gap is known to exist.
The objection worth taking seriously
The strongest objection is that this treats a productivity feature as an infrastructure programme. Workspace agents are, in most organisations, a handful of people asking software to draft a summary and update a page; building permission scoping, action classification, ownership registers and pilot programmes around that is the kind of governance overhead that ensures the capability is never adopted, while competitors who simply turned it on get the benefit. The security profession has a reliable record of designing controls for the version of a technology that exists in three years rather than the one people are using now. That is a fair description of how governance programmes usually go wrong, and most of the recommendations above should indeed be skipped for a small pilot. Two of them should not, and they are the two that are expensive to retrofit. Standing automations — agents that act on a trigger with nobody present — are a different category from invoked ones, and an organisation that accumulates fifty of them without owners will not be able to reconstruct what they do or who wanted them. And the reversible/irreversible split matters because the recoverable failure and the unrecoverable one look identical in a demonstration. Neither takes more than an afternoon to decide. Turn the feature on, let people use it, and settle those two questions before the first standing automation is created rather than after the fiftieth.
Common Questions
Should agents have their own accounts?
They should have their own identity with the invoking person recorded as principal, and a narrower permission set. Running them as the person destroys both attribution and containment.
How do we stop content from redirecting an agent?
By limiting what it can do rather than by filtering what it reads. Detection of manipulative content is unreliable; a missing capability is not.
Do colleagues need to know an agent wrote something?
Yes, for anything that reaches another person. Attribution is a trust question before it is a policy one, and workspaces that blurred it have had to unblur it.
What should we expect over the next twelve months?
Expect every major workspace platform to ship agent capability as a default-on feature, with permission scoping arriving later than the capability. Expect the first notable incidents to involve standing automations nobody owned. Expect administrators to discover that their sharing hygiene was worse than assumed. And expect attribution conventions to settle into a visible label rather than a policy document.
Agentic Workspace Design — we set the two boundaries that are expensive to add later, then let your teams use the rest of it.