Three services behind one policy workflow.
Artifacts enter from the systems you already run, pass through a policy processing workflow, and leave attested, credentialed and notarised. Enterprise-grade multi-tenant SaaS, deployed in the US and EU for data sovereignty.
Who may claim, what they may assert, and what the provenance carries.
A cryptographic seal is only the outside of the envelope. What matters is the manifest inside it: the assertions, their provenance, and whether the provenance is still retrievable once the artifact has been re-encoded and stripped. Each of these is a service you configure once rather than a problem every team solves separately.
Every organisation, team, system and agent that touches an artifact is provisioned with credentials, and with the certificates and hardware-held keys behind them.
What each identity is allowed to claim — roles, memberships, certifications — issued, renewed and revoked in one place rather than per team.
The provenance itself, written to open specifications and still retrievable after a file has been re-encoded and stripped on its way through the internet.
A gateway, an agent, or a check before you act.
All three call the same policy processing workflow, so a decision made once is the decision enforced everywhere — whether the artifact is a container in a build or a frame that must never leave the facility.
Centralized and API-driven, for artifacts that can cross the network. The default path for CMS, CI/CD and cloud pipelines.
A local agent for work that cannot leave your infrastructure. It hashes on your network and sends only the hash, so pixels, geometry and source never cross the boundary.
The interface agents use. Model Context Protocol tools let an assistant or an autonomous workload check an artifact before acting on it, read the full provenance, and create or resolve identities — the same platform, reached the way agents reach anything else.
Verification as a service. Evaluate credentials and trust paths at runtime, before your systems act on an artifact rather than after.
Run your trust ecosystem under your own brand.
Associations, registries and platforms already decide who belongs and what that membership means. What has been missing is a way to make that standing checkable outside your own website — on a member's published work, in a procurement review, or by a machine that has never heard of you. Hosted identity and credential services let you issue it yourself, as a benefit of membership, without running a certificate authority to do it.
You decide who is admitted, what they may claim, and which other issuers you recognise. Membership criteria you already enforce on paper become policy the platform applies, rather than a page on your website that nobody downstream can read.
Credentials are issued under a did:web on a domain you control, and members work in a console at your domain carrying your branding. Verifiers resolve your identity and see your name — we are not in the trust path, and not on the artifact.
Standing in your association stops being a logo on a footer and becomes proof that travels: attached to published work, checkable in a procurement process, and useful against disclosure obligations your members now face whether they belong to you or not.
Load the member list from relationships organisations already publish about themselves rather than maintaining a directory by hand — and withdraw standing when a membership lapses, with revocation reflected the moment anyone checks.
Each ecosystem runs as its own deployment: separate database, separate authentication, separate domain, separate issuer DID. Isolation is architectural, not a filter on a shared table.
Credentials are issued under your DID in open formats and verifiable by anyone holding the artifact. They keep working on your terms — including if you stop working with us.
We host and operate the services. The issuer, the domain, the console, the branding and the policy are yours — which is also the test of whether white labelling is real: what your members are left holding if the arrangement ends.
This runs above the certificate infrastructure you already buy rather than in place of it: the authorities issue and the hardware holds the keys, while the platform governs who may attest, under which policy, and whose attestations your systems accept — across media, software builds and agent workloads alike.
Decide whose attestations count.
A valid credential tells you a key was used. It does not tell you whether the contributor held the authority to make that claim, or whether you should accept it. Trust is relational and contextual: a newsroom may trust a wire service for photographs and not for software packages; an agency may trust a publisher for one class of artifact and not another. The Trust Ecosystem is where those relationships are expressed as policy rather than assumed.
What the graph actually encodes
Which authority granted this contributor its standing, and whether that authority could delegate it in the first place.
What the contributor is recognised for. Authority over news photographs is not authority over build artifacts.
Which organisations recognise that authority, and under which published policy — so the relying party's position is explicit rather than inherited.
Evaluated at the point of use: does this contributor, with this delegated authority, for this artifact class, satisfy the policy this organisation set? That is a trust decision, and it cannot be read off the artifact.
Subscribe to trust policies from organisations and industry bodies whose standards match your own.
Add, remove and weight trust relationships as partners change, without standing up and operating a registry yourself.
Bootstrap an ecosystem for your sector and let members subscribe, so trust is declared rather than assumed.
Instrumented where the artifacts already live.
Attestation fires inside the repositories and pipelines your teams already use — asset managers, source control, artifact stores and content systems — so nobody learns a new workflow and delivery times do not move.
Asset management
Where media is stored and versioned
Artifact repositories
Packages, containers, binaries
Version control
Source and releases
Build pipelines
CI and release automation
Publishing systems
Where content goes out
Agent platforms
Workloads acting on artifacts
Media, software and agentic workloads.
Media is usually the first artifact type through the door. It is rarely the last. The same services, policy workflow and audit trail carry across all three.
Images, video and audio, from capture through distribution. Provenance chains, edit history and licensing terms travel with the file.
Containers, packages, binaries and build artifacts. Build provenance and supply chain verification, enforced in the pipelines you already run.
AI agents, data pipelines and services. Workload identity and capability credentials, authorised at runtime across trust boundaries.
Open specifications, API first.
Nothing here is proprietary. Every artifact is written to a published standard, so your provenance stays verifiable with or without us.
Issue credentials, attest artifacts inside CI/CD, validate provenance at runtime and enforce policy before anything ships.
C2PA
Content credentials
W3C DIDs
Decentralized identity
W3C VCs
Verifiable credentials
SLSA
Supply chain security
in-toto
Attestation framework
SPIFFE
Workload identity
Cedar
Policy language
X.509
Certificate standard
Tell us what your workflows look like and where the work travels, and we will show you what governing them looks like in practice.