OpenAI's updated Workspace Agents documentation describes agents that teams can create, test, share, schedule, connect to apps, and trigger through an API. It also separates several controls that are easy to collapse into one vague idea of “access”: who can find the agent, who can edit it, whose account it uses, what connected tools can do, and which write actions require approval.

That distinction matters for a remodeler, builder, designer, showroom, supplier, distributor, or trade contractor. A useful shared agent may need to read vendor records, project files, lead details, calendars, or team messages. Giving someone permission to run the agent should not silently give them every permission held by its creator or shared service account.

Sharing the agent creates a new operating boundary

A private prototype has one operator who knows its sources and limits. A shared agent can be discovered by more people, triggered from another channel, scheduled without someone watching, and maintained by multiple editors. Each change increases the number of paths between a user request and a business system.

Before publishing, write down the workflow boundary in business language. A vendor-intake agent might read submissions and approved vendor criteria, draft a routing recommendation, and create a review task. It should not automatically approve a vendor, change payment information, email every contact, or search unrelated employee files.

Build the access matrix before connecting the tools

Use one row for every source or action and make the columns explicit. This can live in a spreadsheet or operating document; it does not need custom software. The point is to force decisions before a broad connection becomes the default.

  • People: who may discover, run, edit, publish, pause, or delete the agent?
  • Sources: which folders, projects, records, mailboxes, or channels may it read?
  • Credentials: does each runner use an end-user account, or does the agent use a limited service account?
  • Actions: what may it draft, create, update, send, post, or delete?
  • Approval: which actions always require a person, and which named role may approve them?
  • Constraints: which recipients, domains, documents, projects, fields, or action parameters are allowed?
  • Evidence: what run log, source reference, tool record, approver, and final result must be retained?
  • Ownership: who reviews access, handles failures, and approves a new published version?

Write approval and data access are different controls

OpenAI says write actions are set to ask during a run by default, with options for different approval settings where supported. It separately explains that connector action constraints govern what the agent can ask a connector to do, but do not necessarily restrict all data that the connector can return through another permitted action.

The Datum interpretation is simple: an approval prompt is not a complete privacy boundary. A person can stop an outbound email and the agent may still have read a much broader mailbox than the workflow required. Test read scope, write scope, parameter constraints, and approval behavior as separate properties.

Prefer the runner's identity when the work is personal

OpenAI distinguishes end-user connections from agent-owned connections and recommends a service account when a shared connection is necessary. For work that should inherit each employee's existing permissions, an end-user connection can preserve a familiar boundary. For a central scheduled workflow, a dedicated service account may be appropriate, but it should receive only the sources and actions required for that job.

Do not connect an owner's personal inbox or all-access account simply because setup is faster. Shared credentials blur responsibility and expand the damage from a mistaken instruction, an overly broad search, or a compromised workflow.

Test the matrix with denied cases

A successful demo proves the happy path. An access test should also prove that the agent refuses or escalates the wrong paths. Try requests to read an unrelated project, send to an unapproved domain, change a payment field, publish without review, expose a restricted file, or run after the responsible owner has been removed.

Record the expected result for each case and rerun the set whenever tools, credentials, sharing, instructions, or ownership change. Reviewers should be able to see the requested action, source used, constraint applied, approval decision, final result, and agent version.

Use a narrow publication checklist

  • Name one business job and one accountable owner.
  • List every connected source and action in the access matrix.
  • Choose end-user or service-account authentication intentionally.
  • Keep risky writes behind named approvals and narrow action constraints.
  • Preview the agent with ordinary, edge, and denied requests before publishing.
  • Start with a small runner group before a workspace directory or broad channel.
  • Log runs and review permissions on a fixed cadence and after staff changes.
  • Maintain a pause and rollback path for the currently published version.

The useful shared agent is not the one that can reach the most systems. It is the one whose team can explain who may use it, what evidence it may see, what it may change, when a person must approve, and how the business proves those boundaries still hold.

Publishing that operating evidence also creates stronger material for customers and search systems. Google says AI Overviews and AI Mode do not require special AI-only schema; helpful visible content, crawlability, accurate structured data, and supporting evidence remain the foundation. A real access matrix, test method, and governance record provide substance that a generic “we use AI” claim cannot.

Sources Read

Next step, if this note maps to a problem on your desk: Discovery Call — a 1-on-1 leverage assessment for your business ($1,500 · 90 min).

Related Field Notes