A reasonable buyer evaluating a security platform expects to see how it works before committing time to it. We agree with that expectation, which is why Valty keeps a public overview that is meant to be genuinely useful rather than a marketing wall. What we do not publish is the layer of documentation that describes exactly how a workspace connects to your systems: the connector configuration steps, the API scopes Valty requests from each source, the way individual source adapters behave against a specific tool's data model, and the tenant-specific paths that evidence travels from a finding to a board-ready proof pack. That material lives behind authenticated access, and the reason is a security one, not a sales one.
Valuable and sensitive for the same reason
The distinction matters because implementation documentation is valuable for the same reason it is sensitive. A good integration guide tells a reader precisely which credentials are involved, what permissions they carry, how data is pulled and normalized, where it is stored, and how it is exported. That is exactly the information that shortens an attacker's reconnaissance. Publishing the full operational map of how a platform reads from your cloud accounts, code scanners, and identity providers would hand a hostile reader a blueprint of the integration surface without them having to earn it. Treating that map as protected rather than public is the same instinct that leads any serious team to keep architecture diagrams, scope grants, and data-flow descriptions inside the trust boundary.
What belongs on each side of the line
It helps to be concrete about what belongs on each side of the line. The public overview should explain orientation and boundaries: what Valty is, who it is for, the categories of sources it reads from, the shape of the outputs it produces, and, just as importantly, what Valty does not do. We are explicit in public that Valty reads from your existing tools and never replaces them, that its financial outputs are decision-support estimates rather than actuarial or legal advice, and that several assurances on our roadmap, including SOC 2, are not yet complete. None of that needs a login, and gating it would be the wrong kind of secrecy. A buyer should be able to understand our scope, our limits, and our honesty about stage without talking to anyone.
The gated side is the operational detail that only becomes relevant once you are actually standing up a workspace. That is where the connector specifics live: the exact OAuth scopes or read-only roles Valty asks for from each provider, the steps to register an application, the way a given source adapter handles pagination, rate limits, and field mapping, and the behavior to expect when a source returns partial or stale data. It is also where tenant-specific data lineage lives, because the path a piece of evidence takes through your workspace is shaped by your sources, your environment, and your configuration. That lineage is not a generic diagram; it is a description of your environment, and it should be readable only by people you have authorized.
Least-privilege applied to documentation
This maps directly onto least-privilege, which is the principle that access should be granted only to those who need it for a defined purpose. Documentation is a form of access. A guide that explains how to configure Valty's connection to your AWS organization or your identity provider is, in effect, an access grant to knowledge about how that connection is made. Applying least-privilege to documentation means the people who can read the deep integration material are the people operating a workspace, not the entire internet. The login boundary is simply the enforcement mechanism for that principle, the same way an IAM policy enforces it for systems.
Reducing the attack surface
The other half of the rationale is attack-surface reduction. Every published detail about how an integration works is a permanent, indexable, searchable artifact that anyone can study at leisure, including people probing for a way in. Keeping connector behavior, scope requests, and evidence paths behind authentication removes them from that public corpus. It does not make the system more secure in some absolute sense, but it does mean that an adversary has to do their own reconnaissance against a live, monitored, access-controlled environment rather than reading a finished manual. Raising the cost of reconnaissance is a legitimate and well-understood defensive move, and choosing not to pre-publish that manual is part of the posture, not an omission.
Is this a cover for vaporware?
It would be dishonest to pretend this is purely altruistic, so it is worth naming the obvious objection: gating documentation can be a cover for vaporware, a way to avoid showing that the product is thin. We take that seriously, and our answer is that the public side has to be generous enough to make the objection unreasonable. Orientation, scope, boundaries, the real shape of the outputs, and honest statements of what is and is not built should all be visible without a login. If a buyer cannot tell from the public material what Valty does, how it fits alongside their existing stack, and where its limits are, then the split has been drawn in the wrong place and the public side is too thin, not the gated side too thick.
Protecting the integrity of the estimates
There is a particular reason this matters for a platform like Valty, which exists to translate security and AI controls into dollar-denominated financial risk and to rank remediation by EBITDA impact. The inputs to that translation are findings and signals read from your real tools, and the credibility of the output depends on the integrity of those inputs. If the exact way Valty ingests and normalizes data from a given scanner were a public recipe, it would be easier for someone to reason about how to feed it misleading data or to probe the seams of a specific adapter. Protecting source-adapter behavior is therefore not only about protecting Valty; it is about protecting the trustworthiness of the financial estimates that operating partners and CISOs are meant to act on.
The same logic extends to the evidence layer that produces proof packs. A board-ready artifact is only as defensible as the chain that produced it, and that chain is tenant-specific by design. The path from a raw finding through scoring, ranking, and aggregation into a Monte Carlo distribution and finally into an exported report is a description of how your organization's risk picture is assembled. Publishing that path generically would invite questions about provenance that are better answered inside an authenticated context where the actual data, the actual sources, and the actual configuration can be inspected together. Gating evidence lineage keeps the conversation grounded in your environment rather than a public abstraction of it.
A test for where the line goes
A fair way to think about the boundary is to ask what a reader could do with a given page if they had no relationship with Valty and no authorization to your systems. If the answer is that they would understand us better and evaluate us more honestly, that page should be public, and we want it to be. If the answer is that they would learn how our integration reaches into a customer's environment, which scopes it holds, or how a specific tenant's evidence is wired together, that page belongs behind login. The public docs page exists precisely to make this navigable: it explains what implementation documentation covers and how to request access to it, so the boundary reads as a deliberate trust decision rather than a closed door.
The net effect we are aiming for is that buyer education stays public and operational detail stays protected, and that neither side is starved to feed the other. Keeping integration internals, API scopes, source-adapter behavior, and tenant-specific evidence paths behind authenticated access is itself a security posture, consistent with least-privilege and with reducing what an adversary can learn for free. Keeping the overview open, specific, and honest about our stage is the obligation that makes that posture credible. Drawn correctly, the line lets a serious buyer learn everything they need to make a decision while ensuring that the details which could be turned against a customer are read only by people that customer has chosen to trust.