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.

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.

Access Control for Agent-Generated Work: Who Can Open What Your Agents Produce

Q: 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.

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 for the offboarding steps.

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:

"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, ChatGPT Sites, Stacktree, Palette, and Workplane.

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:

dsp publish ./report.html --visibility company

Or invite one outside reader:

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 – 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

FAQ