IT & Security

View pricing

Where it fits

They are already pasting it. You just cannot see where.

The business is already generating HTML. Finance asks an assistant for a dashboard, sales asks it for a proposal, and every one of those pages has to go somewhere. The fastest route is a paste site, a personal drive, or an attachment nobody can recall. None of those scan for credentials, and none of them tell you it happened.

HTMLvault is the sanctioned path, and it does not replace anything you already run. Your IdP still owns identity, and the assistants keep writing the pages. It takes the HTML the business already produces and routes it through the one path you can see: scanned for keys and PII before it serves, the same gate on the REST API and the MCP server as on the web form, and a retention window every member inherits.

Nothing changes for the person sharing, which is the point. Vault it, publish, send a link, in seconds, so the governed route is also the convenient one. Policy loses to convenience the moment it adds a review step, so here the review step is a rule that runs before publish rather than a person who has to be awake.

ONE GOVERNED PATH, NO SIDE DOORS

YOUR ORG, UNCHANGEDVAULT ITWHO THEY SHARE WITHYOUR PEOPLEfinance, sales, support,already asking for pagesTHEIR TOOLSClaude, ChatGPT, Gemini,already making HTMLHTMLVAULTscanned before it serves,one path you can auditTHE RECIPIENTopens a link,never a paste-site URLEVERY VIEW LOGGEDEVERY PUBLISH AUDITED

How it works

From shadow IT to sanctioned tool

Step 1

Content comes in

Proposals, dashboards, reports. Whatever the business generates, through the web app or the API.

Step 2

Scan & redact

API keys, credentials, emails, and PII caught by regex scanning, plus optional AI scanning with your own provider key.

Step 3

Policy gates publish

Org publishing rules decide whether findings block or warn. Custom roles decide who can do what.

Step 4

Everything is auditable

PII audit across every user, org-wide retention windows enforced automatically, full view logs.

Worked example · The publish that got refused

An AWS key in a dashboard, caught at 13:20.

Someone in finance asks their assistant for an internal dashboard, and the assistant helpfully inlines the connection string it used to query the warehouse. On a paste site that key is now public and nobody in your org knows it happened.

Here it never serves. The scan runs before publish, the finding scores above the threshold your org set, and the publish is refused by a rule rather than by a reviewer who has to be awake. The author sees exactly what was found and what to remove.

Six minutes later the redacted version is live, and there is an audit row naming who published what and which rule ran. The person who nearly leaked a key still got a working link the same afternoon, which is the only reason they will come back through this path next week instead of going around it.

  • The rule decides, not a queue. Findings over the threshold your org set refuse the publish. Under it, they warn and let it through.
  • The author sees the finding. A blocked publish returns the rule and the risk score, so the fix takes minutes instead of a support ticket.
  • Every publish leaves a row. Who, what, which rule ran, and what it found, across every member of the org.
SCAN AND GATE BEFORE IT SERVES
EVENT LOG7 EVENTS · 6 MIN
TIMEStateEVENTTOOL / SOURCEDETAIL
WED13:20External stepHTML arrivesthe web form, or the REST APIone path, no side doors
WED13:20HTMLvault stepScanscan_htmlkeys, credentials, emails, PII
WED13:20Needs attention3 findings1 AWS key, 2 email addressesover the org threshold
WED13:20HTMLvault stepPublish refusedorg publishing rulesthe rule decides, not a reviewer
WED13:26HTMLvault stepRedacted, republishedcreate_linklive, six minutes later
WED13:26Step completedAudit row written/admin/pii-auditwho, what, and which rule ran
WED13:26Signal expectedRetention window openorg-wide defaultthe content purges itself when it closes

Use cases

Govern it without becoming the bottleneck

  • Kill the paste-site habit

    Every upload is scanned for secrets and PII before it goes live, including links created through the API. The convenient path is finally the safe one.

    • Secret scanning
    • Sanitization

  • Nothing leaks to crawlers

    Links are never indexed by search engines or AI crawlers, by design. What the business shares stays between them and the people they sent it to.

    • Never indexed

  • Data with an expiry date

    Expiry on every link and an org-wide retention window that purges the content behind it. Set once, inherited by every member, enforced without a reminder.

    • Retention windows
    • Auto expiry

  • Identity through your IdP

    SSO and SAML with Okta, Azure AD, or Google, set up self-serve through an admin portal. No support ticket and no waiting on us.

    • SSO / SAML

  • Least privilege that is actually granular

    Custom roles gate domains, webhooks, API keys, tracking pixels, and AI scan config independently. Hand over one without handing over the rest.

    • Custom roles
    • Permissions

  • User content off your corporate domain

    Shared pages serve from an isolated domain with daily reputation monitoring, so your corporate domain never carries the risk of what somebody published.

    • Domain isolation
    • Abuse monitoring

What actually changes

Five findings you stop writing up.

“it went up on a paste site”
scanned before it ever served
“the API key was in a screenshot”
the publish was refused
“who shared that, and when?”
an audit row for every publish
“somebody needs to go delete it”
the retention window did it
“it is on a personal account”
SSO, roles, and an org that owns it
Also built for

Sanction the tool they will actually use.

Security your team can audit. Convenience the business will adopt.

New linkView pricing