Much of what teams send is now built with AI: a customer microsite assembled in Claude, a weekly ops report a script rebuilds every Monday, a proposal drafted between two meetings. Making the page takes minutes. The exposure starts five minutes later, when someone pastes the HTML into whatever tool is open, sends the link, and treats the words "draft only" as a policy. The policy owner for AI-generated deliverables, usually in IT or operations, then has to decide whether the team needs a governed AI sharing platform or one more reminder email.
A governed AI sharing platform is the sanctioned place those deliverables get published. The page is checked before a link exists, the link carries defaults nobody had to remember, and the policy owner can see afterwards where it went. Done well, the team publishes as fast as it did with the workaround, and the policy owner can answer questions about any link.
What a governed AI sharing platform does: the five-question test
A governed AI sharing platform gives teams one approved way to publish HTML. The controls are built into the publish step, so nobody has to remember a checklist at 6:42 p.m. on a Friday. In HTMLvault that step works the same wherever the HTML comes from: Claude, ChatGPT, Gemini or Cursor through the MCP server, Zapier, Clay or a script through the REST API, or a paste on the web. Every publish is checked against the account's PII and secret-scanning policy, and every outside URL against Google's unsafe-URL lists. A refused publish returns the findings instead of a URL. A clean one becomes a private link that is never indexed, can carry a password and an expiry, and reports how it was read.
To check whether that adds up to governance, picture an AI-generated deliverable going to the wrong person this afternoon. Could your team answer these five questions quickly?
- What was in it? The stored HTML, plus the PII audit's scan event and findings for every publish and edit.
- Who opened it? Views, unique and repeat viewers, country and city, device, browser and referrer. With one tracked link per recipient, you also know whose link it was.
- How long was it reachable, and can you close it now? The expiry answers the first half. Shortening the expiry or deleting the link answers the second.
- Who owns it? A named person, not a team alias.
- Who approved it for this audience? Your process holds that answer. HTMLvault records the scan, not the sign-off.
If the honest answer to any of them is "we would have to ask around," governance is not in place. It is a document about governance.
Govern the deliverable, not the prompt
Most AI governance advice covers prompts, model choice and training data. Those rules shape what goes into a model. They do nothing about the moment the output becomes portable. The deliverable is what leaves the building, so the deliverable is what needs controls.
HTML makes that harder than a document format would. Sensitive material can sit in a script, a hidden field or a table labelled "sample" that a visual review never touches. AI tools also reassemble context well enough to carry a customer's email address from an earlier prompt into an unrelated page. HTMLvault drops HTML comments at publish, but script text is kept exactly as written, so a token in a script block goes live unless the scan stops it.
Inspect the output before it can be shared. That means secret scanning and PII detection on every publish, because manual review is inconsistent at volume. A reviewer will catch a bad pricing claim and miss a staging token on line 214. HTMLvault's scanner is regex-based and covers nine categories: SSN, financial data, API keys, passport numbers, addresses, person names, dates of birth, email addresses and phone numbers. Pattern matching costs zero tokens, so the scan runs on every publish and edit and nobody is tempted to switch it off. An AI agent can preview findings with the scan_html MCP tool before publishing. There is no REST scan endpoint. Teams and Enterprise accounts can add an optional AI scan with their own Anthropic, OpenAI or Google key. It reviews a link after it is published instead of blocking the publish, and HTMLvault pays for none of its tokens.
Require the right level of approval, not the maximum level. Not every AI output needs executive sign-off. Anything shared outside the company does need a named owner who can say "this is approved for this audience and this use." Without one, review becomes communal optimism, and optimism is not a control.
Treat the scan as a decision point, not a certificate. Pattern matching is excellent at structured data that has no business in a proposal or a lead-list preview. It cannot tell whether a name is fictional, a number is a test value, or a field is sensitive because of business context. A false positive gets reviewed and cleared. A missed pattern is why the standing rule still applies: externally shared HTML is no place for data the audience should not receive. The cheapest control is to share less in the first place.
Sanctioned or merely tolerated? How to tell
Plenty of companies tolerate AI usage and call it sanctioned. Three signs give it away. First, approval lives in tribal knowledge, so the only way to learn whether a tool is approved is to ask whoever usually knows. Second, approval has no mapping to data classes, so "approved" means approved for everything, including the lead list with phone numbers in it. Third, the security review was never redone after the tool's features changed, so it approved a product that no longer exists. Re-review whenever a vendor adds an API, an agent integration or a new way to share, HTMLvault included.
The fix is proportional control, not maximum control. Low-risk experimentation, such as an internal prototype or a draft nobody outside the team will open, can run on lighter rules and faster approval. Customer data and anything that leaves the company get the full set. Sanctioned has to mean deliberate rather than slow. A sanctioned path that loses to a personal account on every deadline is sanctioned on paper only.
Turn policy into defaults: content classes and publishing tiers
Governance introduced as a reminder fails at the first tight deadline. Governance introduced as a default holds, because nobody has to remember anything.
Start with a few content classes, defined by what the page contains: public marketing, external business-confidential (proposals, customer microsites), internal restricted (reports with customer metrics, lead lists) and automated operational output. Then map each class to one of three publishing tiers, defined by how far the page travels.
- Internal. Colleagues only: drafts under review and internal reading. A password, a short expiry and a shared team folder.
- Controlled external. Named recipients: one tracked link per recipient, the company's own domain, and an expiry that matches the decision window.
- Public. Anyone with the link, such as a campaign page with one tracked link per channel. It gets the same brand and legal review as anything else the company publishes. HTMLvault links are never indexed, so a page that needs search traffic belongs on your website.
Each tier comes with its settings, so nobody picks them link by link. Configurable expiry is the clearest case. Pro and above choose from fixed steps between 1 hour and 1 year, or never; Free links expire after 30 days. You can change or extend an expiry after sending, so a short default costs little. For picking each class's window, see matching the window to the deal.
HTMLvault has no org-wide expiry default or cap, and its Publishing Rules are PII rules. That means these defaults live in the workflow that publishes: the Claude project instructions, the Zapier step, the script's create call. Passwords are set on the web, in the upload form or the links dashboard. MCP create_link and the REST API cannot set one. Retention is the one setting no class can carry. It is a single account-wide value (for an organization member, the org owner's): 7 days to 2 years on paid plans and 7 to 90 days on Free, counted from each link's expiry. When it runs out, the content and its per-visitor view data are deleted. Set the retention window once, on the web, for your strictest class.
Then treat the defaults as hypotheses. If every rep asks for an expiry extension, the default is too short. If the scan refuses the same legitimate sample data every week, write a review path rather than teaching people to work around findings. Ignored alerts produce the paperwork of governance without the effect.
Here are two deliverables going through the same tiers. A marketing team builds a customer microsite in Claude for a prospect's evaluation. It starts in the internal tier: Claude publishes it through MCP with a 3-day expiry, the marketer adds a password in the links dashboard, and the reviewer opens it from the shared folder. Once approved, it moves to controlled external. It goes out as one tracked link per stakeholder through create_recipient_links, on the company's white-label domain, with a 30-day expiry the marketer extends if the evaluation runs long. A recipient.viewed webhook passes each open to the CRM through Zapier.
The weekly ops report is automated operational output and never leaves the internal tier. A script rebuilds it every Monday and publishes through the REST API. The first run creates the link, and someone sets its password and a 1-year expiry once on the web. Every later run edits that same link with PATCH /api/v1/links/{slug}, so the URL never changes, and every edit is scanned like a publish. A patch must match the stored HTML exactly once. So the page gives each section and table an id or data- attribute and writes each value in one place. An HTML comment cannot serve as an anchor, because publishing drops it.
Who owns what: content, platform and risk owners
Defaults fail quietly when nobody owns them. Marketing assumes security approved the sharing method, security assumes marketing removed the customer data, and IT doesn't know the page exists. Three named owners close that gap.
- Content owner. Accuracy, purpose and audience. Picks the class, resolves scan findings and decides when a link should close. For the microsite that is the marketing lead; for the ops report, the analyst who maintains the script.
- Platform owner. The approved sharing environment and its baseline, usually IT or operations. Holds the organization owner account, whose retention setting applies to every member, and manages API keys, webhook endpoints, custom domains, shared folders and roles.
- Risk owner. Security, privacy or compliance. Writes the PII and secret-scanning policy, defines the classes, and sets when to escalate: which findings refuse a publish outright and which deliverables need a second approval.
Ownership also sets how much approval a link needs. In the internal tier, the content owner publishes once the checks pass. Controlled external needs the content owner's sign-off for the audience. Anything with regulated data or client records also needs the risk owner, with the approval recorded in the ticketing system you already use.
SSO/SAML (Enterprise; an add-on on Teams) sits with the platform owner. It controls who signs in to HTMLvault, never who can view a link. Viewers are governed by the link's password, expiry and audience. Sign-in uses one-time email codes, passkeys, Google or Apple, so there are no account passwords to reuse. SAML SSO for sharing tools covers the setup.
Monitor the controls, not every sentence
Reading every AI-generated sentence doesn't scale, and it turns the policy owner into the bottleneck the policy was meant to remove. Instead, monitor the events that show the controls working: what was published, what the checks found, who opened it and when access ended.
Start with events. HTMLvault's webhooks fire on link.created, link.updated, link.viewed, link.expired, recipient.created, recipient.viewed and usage.threshold. Send the create, update and expire events to a log or channel the platform owner reads. Pro allows up to 5 endpoints, and Teams and Enterprise allow 20. Each event is tried once and retried 3 times (after 60 seconds, 15 minutes and 1 hour), so a receiver that is briefly down doesn't leave a hole in the record. The PII audit is the only audit log, with one scan event per publish or edit. HTMLvault keeps no log of access changes, expiries, deletions or retention changes. Record those decisions where they are made, in the ticket that asked for the extension or the change request that set retention.
Analytics also work as an anomaly signal. Per-link analytics cover total views, unique visitors, repeat visits, country and city, device and browser, referrer, scroll depth, time on page and server-side channel attribution. Some patterns deserve a look: a link opened from a country where you have no customer, a link still being opened weeks after the deal closed, or a referrer from a public forum, which means someone posted it. Most patterns are harmless, since a buying committee can reread a proposal for weeks. Flag patterns for review, not single views, or the team learns to ignore the alerts. Set limits on the analytics too: decide who sees recipient-level detail and which tracking codes (GA4, Meta, HubSpot) each class may carry.
Roll it up into a one-page monthly report for the platform and risk owners: links published, scan findings, links revoked or expired, and exceptions granted. Trends tell you more than single counts. If secret findings rise after a new automation goes live, fix the template while the problem is small.
Then measure adoption, because monitoring that only watches the sanctioned path cannot see the work that skipped it. Count exception requests, look for HTML attachments in outbound email and pages on unapproved hosts, and track time to publish from request to link.created. If the sanctioned path slows routine work without reducing any real risk, change the rule.
Limits, and the adoption test
Controls reduce exposure. They do not make recipients trustworthy. Nothing here prevents a screenshot. A password restricts access but does not establish identity the way a signed-in session does. Expiry shortens the window but cannot retract what someone copied while the page was live. Regex scanning catches structured patterns and misses context, and the BYOK AI scan reviews a link after it is live, not before. None of it replaces legal review for regulated content.
The product has limits to plan around too. There is no org-wide expiry default or cap. Retention is one account-wide setting, not a per-link choice. The PII audit is the only audit log. SSO governs who signs in, never who views. Links are never indexed, which suits a proposal and rules out a page meant to rank in search.
The largest limit is adoption. A flawless policy in a security wiki loses to a public paste tool the first time a deal is on the line. A sanctioned tool passes only if a marketer, an analyst or an automation can publish approved HTML faster through it than around it. If you are weighing a governed AI sharing platform, time it. Run one real deliverable from each class through the tiers on a pilot account and compare the minutes with the workaround. The Free plan's 50 links a month are enough for that. The enterprise checklist covers the vendor evaluation.
When legal asks what was in the customer microsite and who opened it, the policy owner can answer in the time it takes to open the dashboard: the link's scan record, its expiry and its per-recipient analytics. Nobody has to dig through a week of sent mail.