A signed ledger bundle is worth more if the party that wrote it is not the only one able to check it. The verifier source is MIT and runs offline. None of it is on a registry yet. This page lists each piece, its licence and where it lives.
Put admission in front of your MCP servers, repositories, SaaS tools and cloud accounts. Every agent gets a lease or a reason – and you keep the lever to stop any of them.
© 2026 Intramedial. All rights reserved. Intramedial is a product by Trustvice. Secured and supercharged by Avonao Labs.
Report abuseChecking a bundle is one operation: an Ed25519 signature over a Merkle-rooted set of records, checked against a public key. The verifier source has no dependency on our services. The bundle format is described in the module docs.
Independent check
ledger-bundles-keys.jsonRFC 8785 · RFC 8032Open verification does not make every record true. A valid signature shows who signed which bytes and that nothing changed afterwards; it does not show that the events were correct. What a bundle does not prove →
Each row says what exists today. Where something is not published, we say so and point to what works now. No date is promised for the unpublished items.
| Item | Licence | Where | Status |
|---|---|---|---|
Offline verifier, TypeScript source@intramedial/verifier | MIT | Repo |
Two libraries have complete source: an offline verifier for signed evidence, and a base package with a typed client for agent frameworks. Both are MIT and neither is on npm yet, so build them from a checkout of the repository today. Each has a readme.
intramedial-verifyJavaScript and TypeScriptChecks signed evidence with the same WebCrypto code the runtime uses. It has no dependency on Intramedial and makes no network call: you give it the document and a key set you fetched yourself. The package is @intramedial/verifier.
The bundle a snapshot returns is described in the ledger-bundles module docs: its fields, how it is signed and how the key is found. There is no standalone specification yet, and no date is promised for one. The module docs remain the reference for now, and the verifier source shows the rest.
ledger-bundlesmodule docsno licence statedPublic documentBundle id, workspace, jurisdiction, scope, range, record count and Merkle root.
The public Ed25519 key of each jurisdiction is meant to be served without a login. We have not confirmed that from this site, so read the paths as documented, not guaranteed. The private keys are held as Worker secrets in each region.
https://intramedial.com/.well-known/ledger-bundles-keys.jsonThe key set at the path the module docs name, on the site host itself.https://ledger-bundles.api.intramedial.com/.well-known/ledger-bundles-keys.jsonThe set on the worker's own host.No known-answer vector is published yet. The verifier's own tests carry fixtures in the repository. A public vector with a throwaway key is planned, and no date is promised for it.
{
"ok": true,
"kind":
}github.enforce asks Intralock whether an agent may act on a repository and posts the verdict to GitHub as a check run or a commit status. It is a hosted module, not a package you install.
github.enforcehosted modulePublic documentNo GitHub Action is published for Intramedial. A repository calls the module's API instead, with the request shown below. A workflow that references an Action name would fail until one exists.
Agents and coding assistants look for description files at predictable addresses. These are public, generated from the same action definitions as the MCP server, and need no account. The live server's answer is authoritative; where a file and the docs differ, the docs win.
/.well-known/mcp/server.jsonThe MCP server's name, the streamable HTTP endpoint and the sign-in modes it accepts.
/.well-known/mcp/tools.jsonThe tools with their input and output schemas, as tools/list returns them.
/.well-known/agent-card.jsonThe gateway agent's identity, transports and one capability per action, for A2A clients.
The repository holds more source than this page lists above. None of it is published or documented as a package yet, so there are no install steps. We list it so that nothing here is a surprise later.
mcp-server stdioNot published yetA stdio MCP server that forwards to the platform's HTTP MCP endpoint, so the tool logic stays in one place.
There is no public repository to open issues or pull requests against yet. Until one exists, these are the channels that exist today, and none of them is a ticket queue.
In the verifier, the key set or the bundle format. Email us privately and do not post details before we have had time to fix it.
A verifier that disagrees with its own tests, a doc example that fails, or a manifest that does not match the live server. Send the input and what you expected.
Open the Fleet Map to see agents, leases and approvals as they happen. The verifier runs from a checkout, offline.
Agent adapters@intramedial/adapter-framework | MIT | Repo | Not published yet |
Ledger bundle format, in the docsledger-bundles | Not stated | Module docs; no standalone spec | Public document |
Bundle public keysledger-bundles-keys.json | Public data | Documented path; not confirmed live | Not published yet |
Known-answer test vectorno public vector | Not stated | None public; tests in the repository | Not published yet |
GitHub write gate (module)github.enforce | Not stated | Module, no Action | Public document |
MCP and discovery manifestsserver.json · tools.json | Not stated | intramedial.com/.well-known | Public document |
If you install a package with one of these names and it did not come from a publisher you trust, do not use it.
cd verifier npm install && npm run build npx intramedial-verify bundle.json --keys keys.json
verifyNotarianBundleWithKeys()verifyTopsSealWithKeys()verifyAuditChainExport()verifyArtifactWithKeys()The verdict lists every problem it finds, not only the first, and a missing key reads as a failed check, never a pass.
adapter-frameworkTS/NodeA base class and run protocol for agent adapters, with a typed client over the agentic action API. Each framework gets its own small package on top. All are MIT and kept in one workspace.
adapters/packages/adapter-frameworkBuild it with npm run build
cd adapters npm install npm run build
okkindreasondetailsThe verifier canonicalises JSON as RFC 8785 describes before it hashes.
Ed25519 with the key named in signingKeyId, chosen for the request's jurisdiction.
The audit-log records sealed in the range, committed by the root.
An optional scope and range; with none, the whole history to date.
otsProof stays null until the daily anchor confirms a block in Bitcoin.
One public key per jurisdiction, served as a JWK set at a well-known path.
Pick the key by ID, check the root, then check the signature.
No versioning policy is published yet, so none is promised here until one exists.
The bundle carries a Merkle root over its records and an Ed25519 signature. The verifier recomputes the root from the records, then checks the signature. The example is from the docs.
{
"bundleId": "lb_20261101_wnam_01",
"workspaceId": "ws_acme",
"jurisdiction": "wnam",
"scope": "default",
"recordCount": 4820,
"merkleRoot": "8f1c2a9e...",
"signingKeyId": "lb-wnam-2026-10",
"ed25519Signature": "base64-signature",
"otsProof": null
}/api/v1/ledger-bundles/anchors/api/v1/ledger-bundles/snapshotCreates a bundle; needs a paid plan.{
"kty": "OKP",
"crv": "Ed25519",
"x": "…",
"kid": "…",
"alg": "EdDSA",
"use": "sig",
"jurisdiction": "wnam"
}curl -sSL https://ledger-bundles.api.intramedial.com/.well-known/ledger-bundles-keys.json -o keys.json jq -r '.keys[].kid' keys.json
For the strongest check, fetch a key once, store its kid and x in your own records, and verify against that copy. Every location above is served by us, so comparing them protects against one bad route, not a compromised Intramedial. Bundle keys in the docs →
| Input | Verdict |
|---|---|
| A bundle and its key set as sealed | ok: true |
| The same bundle with one record altered, say | ok: false |
| The same bundle with a different key ID | ok: false |
| Any JSON that is not a bundle | ok: false |
The verdicts show the shape only. They come from no signed vector, and no test key is published.
verifier/test · runtime/ledger-bundles/test{
"repo": "acme/payments",
"actorDid": "did:web:acme.example:agent:billing",
"sha": "9fceb02d0ae598e95dc970b74767f19372d61af8",
"action": "write"
}reposhaactionA write that needs confirmation is refused with confirmation_required until an approver issues a token. Mandates still apply.
/openapi.jsonThe REST surface as an OpenAPI document, for generating typed clients.
/llms.txtA plain-text map of the site and every docs page, written for language models.
/AGENTS.mdOne Markdown document describing every action with an example.
curl -s https://intramedial.com/.well-known/mcp/server.json | jq .endpoints curl -s https://intramedial.com/.well-known/mcp/tools.json | jq '.tools[].name'
No licence is stated for these files. They describe a hosted service, the MCP server at mcp.intramedial.com, which is not a package you install.
adapters/packages/mcp-server/contracts packageNot published yetThe shared contracts package: action and schema definitions the platform and its clients use. It is private, with no licence.
contracts/Per-framework adaptersNot published yetOne small package per agent framework, built on the adapter framework above. The frameworks belong to their own authors; only the adapters are ours, as MIT code.
adapters/packages/The module docs and the verifier source are enough to write one. Tell us about it and we can check it with you.
How to report, what is in scope, our safe-harbour commitment and what to expect from us.
The standard security contact file is published at /.well-known/security.txt.
Not published yetPull requests: planned. When public repositories exist, this page will link them and say how contributions are licensed.