Proposes one disclosed action.
Verifiable execution for software agents
Approve one action. Verify the result.
Connect AI agents and replaceable providers through one policy-bound execution layer. Polymodum consumes each exact permission once and returns evidence another machine can verify.
Apache-2.0 reference implementation
Offline-verifiable proofs
Fail closed on unknown
Protocol evidenceLocal trial available
Independent operators0 · not yet proven
VerificationOffline from signed files
Protocol topology · not a live network map
Agents make the network useful. Evidence keeps it honest.
Every connected agent can propose useful work and return portable evidence through replaceable providers. More participation adds useful routes and receipts; it does not by itself prove decentralization or operator independence.
Evidence route / bounded by design
Current network activity unavailable
Names the tool, target, input and limit.
Uses the bound permission once.
Records what the configured system observed.
Checks the disclosed bytes and trusted keys.
Durable records, when a profile requires them.
Policy-bound authorization
Signed evidence path
Role, not a live node count
Fail closed: no connection, witness quorum or provider result is inferred here. Inspect signed evidence in the Explorer before treating any route as active.
The problem
A log is not permission.
Most logs are written after an agent acts. They may show what a system recorded, but not that the exact action was allowed first. Polymodum checks before dispatch.
A status inside the provider that performed the action.
A record another verifier can check outside that provider.
How it works
One request. One permission. One receipt.
The verifier checks the disclosed action, decision, one-use state and result. It does not assume this website is telling the truth.
Describe the action
Fix the tool, recipient, input and limits before the agent starts.
Approve it once
The permission is stored and consumed when that action is dispatched.
Check the receipt
Another machine can verify the records with public keys you trust.
A signature proves what the configured system recorded. It does not by itself prove that every host, operator or real-world outcome is trustworthy.
Vendor-neutral integrations
Connect an agent without handing it ambient authority.
Models can propose work, but credentials remain inside narrow service adapters. Every write must name the provider, operation, target and input before a one-use permit is consumed.
Local agent→
Exact permit→
Restricted adapter→
Signed receipt
Local models
Hermes or Qwen can be exposed through a signed model manifest. The remote operator receives no Ollama credential or host access.
model.invoke / exact alias
GitHub
The public permit profile will bind repository, operation, ref and payload. Installation credentials remain outside the repository and model process.
github.issue.create / bound repo
X
The public permit profile will bind account, post body, media digest and reply target. OAuth credentials remain private deployment state.
x.post.create / bound account
Planned labels are not implementation claims. Public adapter code must never contain deployment credentials, account identifiers or private allowlists.
Experimental application card · Agent Mail
Change mail provider. Keep your identity.
Experimental · not a network claim
Your identity is a key you control, not an account at one company. Revoke provider B, move to C, and keep the same identity and verified history.
Open the Agent Mail protocol trial
Encrypt
Bind the recipient and encrypted message before it is sent.
Confirm
Keep signed custody and receiver acknowledgements.
Move
Revoke one provider and choose another without becoming a new user.
Signed local mail trial · verifier readout
Checking evidence
What the trial does
One encrypted message. One failover. One provider switch.
Alice approves a message to Bob. C stores the same encrypted envelope while B is offline. B acknowledges it once. Bob then moves from B to C with the same root identity.
Approve before sending
The signed action fixes the recipient, endpoint and ciphertext.
Fail over without a duplicate
C holds encrypted custody. B accepts the same envelope once.
Switch provider
Bob revokes B and signs a new mailbox endpoint at C.
Checks backed by signed files
Waiting for a fresh signed replay. No result is inferred until every required receipt passes local verification.
- Signed actionWaiting for verified evidence.Checking
- Deterministic authorizationWaiting for verified evidence.Checking
- One-use executionWaiting for verified evidence.Checking
- Receiver acknowledgementWaiting for verified evidence.Checking
- Relay failoverWaiting for verified evidence.Checking
- Identity migrationWaiting for verified evidence.Checking
Experimental local trial—not Internet mail, not a reliability or decentralization claim. No independent operator, external transport, provider honesty, host integrity or real funds are proven here.
Evidence, not theatre
Passed locally is not passed on the Internet.
This page keeps those claims separate. The Explorer shows the signed records, verifier output and limits behind each status.
Awaiting a fresh, locally verified signed replay.
Zero externally qualified independent operators in this trial.
No wallet, real payment, SMTP provider or Internet delivery is used by this evidence bundle.
One public identity
The same verified release, wherever it resolves.
The public site is prepared as a content-addressed static bundle. ENS and DNSLink can resolve one stable IPNS name; its signed record selects a specific immutable IPFS CID for each reviewed release.
- Stable name
- IPNS → signed pointer to one IPFS CID
- ENS
- Contenthash → the stable IPNS name
- Classical DNS
- DNSLink → the same IPNS name
- Application API
- Separate, explicitly live service
IPNS is mutable and can be repointed by its key holder. A CID is immutable, but neither identifier guarantees availability, gateway honesty or a current live result.
Developer & evidence
Build adapters. Keep authority narrow. Verify every result.
The reference implementation uses Apache-2.0. It makes its evidence and boundaries inspectable; it does not turn unavailable evidence into a passing result.
- Policy, target and input are named before dispatch.
- Receipts are verified from signed files, outside this site.
- Unknown outcomes remain unavailable, not retryable by default.
Receipt / verifier viewFail closed
- Authority
- Policy-bound permit
- Outcome
- Append-only evidence
- Verification
- Offline signed files
Protocol document
Documentation · publication pending
Security contact · publication pending
Service status
Publication record
Questions worth asking
What Polymodum is—and is not.
What is Polymodum?
Polymodum is a vendor-neutral policy and evidence layer between AI agents and replaceable providers. It gives agents bounded permission and produces portable evidence of the result.
Does it make an AI agent safe?
No. It can show that a configured policy allowed or denied a disclosed action. It does not prove the agent, host, operator or real-world outcome is safe or truthful.
What does “portable proof” mean?
The evidence can be checked by another verifier with the relevant public keys. You do not need to trust this website to inspect it.
Is agent mail ready for everyday email?
No. The current agent-mail trial is a local, experimental protocol test. It is not Internet email and does not yet prove independent operators or public-network reliability.
Is this a blockchain, token or payment product?
No. Polymodum does not issue a token, announce an airdrop or provide payment, wallet or funding authority. Optional ordering and settlement references remain separate, bounded profiles.
Can I use or contribute to it?
The implementation is Apache-2.0 licensed. Review the source and contribution guidance when the canonical public repository is published. Report security issues through the configured private contact, not a public issue.