--- title: "Access Control for Agent-Generated Work: Who Can Open What Your Agents Produce" slug: /blog/access-control-agent-output publishedAt: "2026-09-22" updatedAt: "2026-09-22" author: ott priority: P0 keyword: access control ai agent output secondary_keywords: who can see ai generated documents, ai agent output permissions, sso for ai generated content, audit trail ai agent, share ai output with company, agent published document access word_count_target: 2800 funnel_stage: Problem-aware schema: FAQPage, Article description: "Agents now produce reports, dashboards, and specifications for people who never opened the agent. This is the access model for that work: four audiences, three sign-in paths, what the audit log records, and where each vendor's own sharing stops." --- # Access Control for Agent-Generated Work: Who Can Open What Your Agents Produce > **TL;DR:** An agent produces a page. Someone else must open it. Every vendor's own sharing answers that with one of two shapes: a public link, or an account on that vendor's product. Neither is "everyone at my company, and only my company." This post sets out the access model that answers it. Four audiences. Three sign-in paths that need no new account. Roles that never grant content access. An audit log that records who published, who opened, and who changed what. --- ## Three failures this model exists to prevent Access control for agent work is abstract until it fails. It fails in three recognizable ways. **An agent published a customer report to the wrong audience.** The agent did what it was asked. The link it returned was public, because public was the only option that did not require the reader to buy a seat. The report held customer names. Nobody noticed until a customer did. **The feedback no longer matches the page.** A reviewer commented in Slack on Tuesday. The agent published a new version on Wednesday. On Thursday a second reviewer read the Slack thread, opened the page, and could not find what the first comment referred to. **The next agent cannot tell what changed.** Version 3 is live. Version 2 was fine. Nobody can say who published version 3, from which tool, or whether a person or an agent did it. Each failure has the same root. The page had a link, and it did not have an owner, an audience, or a record. --- ## The model in one table [display.dev](/) gives each published page, which we call an artifact, one audience, one sign-in path per reader, and one record. The publisher chooses the audience when they publish, and can change it later. The URL stays the same. | Audience | Who can open it | How they sign in | Plan | | ------------------ | ------------------------------------------------------------- | --------------------------------------------------------------------------- | ---------- | | **Public** | Anyone with the address | No sign-in | Every plan | | **Company** | Everyone at your organization | Google or Microsoft on Pro and Enterprise. One-time password on every plan. | Every plan | | **Private** | The creator, and people they invite | Members: as above. Invited outsiders: one-time password. | Every plan | | **Invited people** | Named email addresses, added to a Company or Private artifact | One-time password sent to that address. No account. | Every plan | On the Free plan, Company and Private artifacts share a limit of 3. Public artifacts are unlimited on every plan. Viewers are unlimited on every plan. --- ## Who counts as "the company" A Company artifact opens for members of your organization. Membership comes from a verified company email domain, not from a list. An Owner adds the domain and verifies it through DNS. From then on, anyone who signs in with an address at that domain is a member. A new hire is a member on their first day. Nobody maintains a roster. Pro organizations can add more domains with an add-on. Enterprise includes them. One organization can hold several domains, which covers a company with more than one brand. Sign-in uses the account the reader already has. On Pro and Enterprise, that is Google Workspace or Microsoft Entra ID. On every plan, the reader can instead enter a one-time password sent to their email address. Enterprise adds SAML for organizations that run their own identity provider. --- ## The reader who is not in the company The audience that vendor sharing handles worst is the named outsider. A client. A contractor. An auditor. Someone who must open one page and nothing else. On display.dev, the publisher adds that person's email address to the artifact. The person receives a notification. When they open the page, they enter the address and the one-time password sent to it. They create no account. They see that one artifact and no other. The link alone does not open the page for anyone else, because the one-time password goes to the invited address. This is the shape a shared password cannot give you. A password is a secret that anyone can forward. An invitation is a person. --- ## What the reader never sees Two rules protect the audience beyond the sign-in. **A denial reveals nothing.** When someone who is not in the audience opens a Company or Private artifact, display.dev does not reveal whether the artifact exists. There is no page that says "this exists, but not for you." **A role is not a key.** Organization roles control administration. Owners manage billing, roles, sign-in, and domains. Admins manage members and public or company artifacts. Members publish. None of those roles grants access to the content of a Private artifact. A Private artifact can be read only by its creator and the people invited to it. An Admin who was not invited cannot open it. Administration and reading are separate on purpose. --- ## What the record holds The third failure, the version nobody can explain, is answered by the audit log and by attribution on the artifact itself. **Every version is attributed.** The version history names the actor behind each version and the surface it came from. A version published by an agent through MCP is recorded as an agent action, with the agent's name. A version published by a person from the dashboard is recorded as that person. A comment names the person who left it. **The audit log records the lifecycle.** On Pro and Enterprise, the organization's audit log records each of these events, with the actor, the source, and the time: - an artifact was published, updated, renamed, or deleted - an anonymous artifact was claimed into the organization - a version was rolled back - the audience changed, or a person was invited or removed - someone in the audience opened the artifact - someone outside the audience was denied - a member's role changed, or a member was removed Pro keeps 90 days. Enterprise keeps 365. Solo records view counts without identity. Free records none of this. **Who opened it, by name.** On Pro and Enterprise, the artifact's view record shows which signed-in person opened it and when. Solo shows counts. Public artifacts record anonymous views as counts only. A signed-in reader can also see who else has the artifact open at that moment. Presence follows the audience, so it never shows a reader anything they could not already open. --- ## How access changes over time Work does not stay still, and neither does its audience. **The audience changes, the URL does not.** Move an artifact from Private to Company when the draft is ready. Move it to Public when it is meant for customers. Move it back. Every change is recorded, and the address people already have keeps working for the people who are still allowed. **Comments stay on the page.** A reviewer comments on the artifact, not in a chat. The next agent reads the comment through MCP, publishes the next version to the same URL, and resolves the thread. The comment and the version it refers to stay together. A reviewer with edit permission can correct a line in the page in the browser, and that change becomes a version like any other. **Versions stay available.** Paid plans keep earlier versions, up to 50 on Pro and unlimited on Enterprise. A retained version can be opened or exported. A rollback is recorded like a publish. **The organization keeps the work.** Artifacts belong to the organization. When a member leaves, their published work does not leave with them. See [Members and roles](/docs/roles) for the offboarding steps. --- ## Where each vendor's own sharing stops Every agent vendor now offers some way to share output. Each one stops at the same line: the reader needs an account on that vendor, or the page is public. | Vendor sharing | Private audience | Reader needs | Company-wide by domain | Outside reader with no account | Audit of who opened | | ---------------------------------- | --------------------------------------- | ----------------------------------------- | ------------------------------ | ------------------------------ | ----------------------------------- | | Claude artifacts, Docs, and Slides | Named people or the Claude organization | A Claude account | ❌ | ❌ | ❌ | | ChatGPT Sites | Workspace members or invited people | A ChatGPT account | ❌ | ❌ | Page views only, none on Enterprise | | Stacktree | Per-link password or email-domain gate | A password or a matching email | Per link, not per organization | ✅ by password | Hashed view log, 30 days | | Palette | Public link with expiry | Nothing | ❌ | Public only | Not documented | | Workplane | Named Workplane users | A Workplane account | ❌ | ❌ | Not documented | | display.dev | Company, Private, or invited people | Google, Microsoft, or a one-time password | ✅ | ✅ one-time password | ✅ Pro 90 days, Enterprise 365 | Stacktree comes closest on gates. Its own comparison page, last updated 20 September 2026, [says](https://stacktr.ee/display-dev-alternative): > "If your primary requirement is 'every viewer must be in our IdP,' and you want every artifact across the org auto-gated to your SSO without per-link configuration, Display.dev's workspace model is a tighter fit today." Each row links to a fuller treatment: [Claude artifacts](/blog/are-claude-artifacts-private), [ChatGPT Sites](/blog/chatgpt-site-private), [Stacktree](/stacktree-alternative), [Palette](/palette-alternative), and [Workplane](/workplane-alternative). --- ## What this model does not do Three limits, stated plainly. **No shared-password links.** display.dev has no password on a link, no expiry timer, and no burn-after-read. Access is a person or an audience, never a secret. If a single-use secret link is the whole job, Stacktree covers it and we do not. **No organization-wide switch yet.** An Owner cannot yet turn off Public links or outside invitations for the whole organization in one setting. That control is planned. Today the publisher chooses per artifact, and the audit log records the choice. **No custom domain below Enterprise.** Solo and Pro artifacts live at your organization's address on `dsp.so`. A custom domain is an Enterprise capability, scoped in the contract. --- ## Getting started Publish one file and set its audience in the same command: ```bash dsp publish ./report.html --visibility company ``` Or invite one outside reader: ```bash dsp publish ./report.html --visibility private --share client@example.com ``` The same choices are available from MCP in Claude Code, Codex, Cursor, and Claude, and from the dashboard. Company sign-in with Google and Microsoft is on the Pro plan at €49 per month, flat per organization, with unlimited viewers. **[Publish your first artifact free](https://app.display.dev)** – 3 gated artifacts on the Free plan, unlimited viewers, no card required. --- *Product behavior in this post reflects display.dev's documentation on 22 September 2026. Competitor claims reflect each vendor's public documentation on the same date. See the linked pages for sources.* **Sources and further reading** - [Sharing and access](/docs/visibility) - [Members and roles](/docs/roles) - [Company email domains](/docs/email-domains) - [Sign-in providers](/docs/auth-providers) - [Plans and limits](/docs/limits) - [What is gated publishing?](/blog/what-is-gated-publishing) - [How to know if someone opened your link, and who](/blog/know-if-someone-opened-your-link) - [Why per-seat pricing kills internal sharing](/blog/per-seat-pricing-internal-sharing) --- ## FAQ **Who can see documents that an AI agent published?** On display.dev, the publisher chooses: anyone, everyone at the organization, or the creator and invited people. Company readers sign in with Google or Microsoft on Pro, or a one-time password on every plan. Invited outsiders use a one-time password and create no account. **Can I restrict an AI-generated page to my company's email domain?** Yes. An Owner verifies the company domain through DNS. Anyone who signs in with an address at that domain is a member and can open Company artifacts. Additional domains are a Pro add-on or included on Enterprise. **Do readers need to buy a seat?** No. Viewers are unlimited on every plan, including Free. Publishers, members, invited people, and agents are not billed per seat. **Can an administrator read a private artifact?** No. Organization roles control administration, not content. A Private artifact can be read only by its creator and the people invited to it. An Admin or Owner who was not invited cannot open it. **What does the audit log record?** On Pro and Enterprise: publishes, updates, renames, deletions, claims, rollbacks, audience changes, invitations and removals, views by signed-in readers, denied access, and role changes. Each entry names the actor, the source, and the time. Pro keeps 90 days, Enterprise 365. **Can I tell whether a person or an agent published a version?** Yes. Each version is attributed to its actor and the surface it came from. An agent publishing through MCP is recorded as an agent, with its name. A person publishing from the dashboard is recorded as that person. **Can I share an AI-generated report with a client who has no account?** Yes. Invite the client's email address on a Private or Company artifact. The client enters that address and the one-time password sent to it. They create no account and see only that artifact. **Does display.dev have password-protected links?** No. Access is always a person or an audience. There is no shared password, no expiry timer, and no burn-after-read. If a secret link is the requirement, a product built around per-link gates fits it better.