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.
Managing and governing trust ecosystems through credential services.
Associations, registries and platforms already decide who belongs. Hosted issuance turns that decision into a credential members carry — checkable on published work, in procurement, or by a machine that has never heard of the organisation.
Membership criteria already enforced on paper become policy the platform applies.
Credentials are issued under a did:web on the association's own domain, and verifiers resolve that identity rather than ours.
Standing in the association becomes proof that travels into published work and procurement reviews.
The member list is loaded from relationships organisations already publish about themselves.
Each ecosystem runs as its own deployment, with its own database, authentication, domain and issuer DID.
Credentials are issued in open formats under an issuer DID, so they keep working after the arrangement ends.
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 the workflows look like and where the work travels, and we will show how they get instrumented and secured without changing how anyone works.